Generating and verifying SLSA build provenance for artifacts

For UK SMEs shipping software, the question is no longer just whether a build passed tests. It is whether you can prove what was built, from which source, by which system, and with which inputs. That is the purpose of SLSA build provenance. In practical terms, provenance is machine-readable evidence that links an artefact back to a specific build process. It helps you answer a simple but important question: can we trust this release enough to promote it, consume it, or hand it to a customer?

SLSA, which stands for Supply-chain Levels for Software Artifacts, is a framework for improving software supply chain integrity. It does not make software safe by itself, and it does not guarantee that a build is free from defects. What it does provide is a structured way to describe and verify how an artefact was produced. For teams already investing in software supply chain assurance controls, provenance is one of the most useful evidence types because it is directly tied to the build, not just the source repository.

What SLSA provenance is and why it matters

SLSA provenance is a statement about an artefact’s origin. It typically records the source repository, commit or tag, build workflow, builder identity, and sometimes the parameters or materials used during the build. If you are producing binaries, container images, or packaged release artefacts, provenance gives downstream consumers a way to check that the item they received really came from the expected pipeline.

This matters because software supply chain attacks often target the path between source code and release. A dependency may be swapped, a build runner may be compromised, or a release process may be bypassed. Provenance does not stop those events on its own, but it makes them easier to detect and harder to hide. It also gives you a stronger basis for release gating, incident investigation, and supplier assurance.

How provenance differs from an SBOM

An SBOM, or software bill of materials, describes what is inside an artefact, usually in terms of packages, versions, and dependencies. Provenance describes how the artefact was produced. The two are complementary, not interchangeable. An SBOM might tell you that a container image contains OpenSSL 3.0.13. Provenance might tell you that the image was built by a specific GitHub Actions workflow from commit abc123 using a pinned base image and a signed build process.

If you already generate SBOMs, provenance adds a different layer of assurance. The SBOM helps with vulnerability management and dependency visibility. Provenance helps with origin, integrity, and build traceability. For a fuller view of the relationship between these controls, it is worth reading Generating SBOMs using Syft and Grype alongside this article.

Where provenance fits in software supply chain assurance

In a mature control set, provenance sits alongside source control protections, dependency pinning, code review, signing, and pipeline hardening. It is most valuable when you treat it as evidence that supports trust decisions. For example, a release manager can require a valid provenance attestation before promoting an artefact from staging to production. A procurement team can ask a supplier to provide provenance for delivered software. A security team can use provenance to narrow the scope of investigation when a release behaves unexpectedly.

What searchers mean by build provenance verification

When people ask how to verify SLSA build provenance, they usually mean one of two things. First, they want to know how to generate provenance in the CI pipeline so that every release is accompanied by an attestation. Second, they want to know how a consumer or release gate can check that attestation before trusting the artefact.

Verification is not a single yes or no question. It is a set of checks against expected claims. Those checks may include the source repository, the commit SHA, the builder identity, the workflow name, the digest of the artefact, and the signature on the attestation. The exact fields depend on the tooling and the SLSA provenance format you use.

Common questions about generating provenance in CI

In practice, teams ask whether provenance can be produced automatically, whether it works across different CI systems, and whether it can be attached to binaries as well as container images. The answer is yes, but the implementation details vary. Some platforms have first-class support, while others require you to add signing and attestation steps into the pipeline yourself.

The key design point is that provenance should be generated by the trusted build system, not by a developer laptop or a loosely controlled script. If the build environment is not trustworthy, the provenance record may be accurate about the build process but still not give you the assurance you want.

What a verifier checks and what it does not prove

A verifier checks whether the attestation matches the expected build identity and source claims. It can confirm that the artefact digest matches the provenance, that the attestation was signed by a trusted key or identity, and that the source repository and commit are what you expect. It does not prove that the code is secure, that the build output is bug free, or that the source itself was free from malicious changes.

That distinction matters. Provenance is about traceability and integrity, not functional correctness. It is a control that reduces uncertainty, especially when you consume artefacts from multiple teams, suppliers, or automated release systems.

Core SLSA concepts to understand before implementation

Before you wire provenance into a pipeline, it helps to understand the main building blocks. SLSA provenance is usually expressed as an attestation, which is a signed statement about an artefact. The attestation contains a predicate, which is the structured payload describing the build. The predicate is what the verifier reads to decide whether the artefact came from the expected process.

Builder identity, source, and build inputs

The most important claims are the builder identity, the source location, and the build inputs. Builder identity tells you which system or workflow produced the artefact. Source tells you which repository and revision were used. Build inputs may include dependencies, parameters, environment details, or materials used during the build. The more controlled and reproducible the build, the more useful those claims become.

For technical teams, this is where source control discipline and pipeline discipline meet. If your build pulls from floating branches, unpinned dependencies, or mutable external resources, provenance becomes less reliable as an assurance mechanism. That is why provenance works best when combined with dependency pinning and controlled release branches, as discussed in Managing dependency risk and transitive dependencies.

Attestations, predicates, and signed metadata

An attestation is only useful if it can be trusted. That usually means signing it with a key or identity that the verifier recognises. In modern CI systems, this may be an ephemeral identity rather than a long-lived private key. The important thing is that the signature can be tied back to a trusted builder and that the attestation cannot be altered without detection.

In operational terms, treat provenance as signed metadata that travels with the artefact. Store it where release tooling can find it, and make sure the digest of the artefact is part of the verification process. If the digest does not match, the artefact should be rejected.

Choosing a practical implementation approach

The right approach depends on your CI platform, your release model, and how much control you have over the build environment. For many SMEs, the simplest route is to start with a platform-supported generator and a verifier that can be run in the release pipeline or in a downstream consumer workflow.

GitHub Actions and the SLSA GitHub generator

If you use GitHub Actions, the SLSA GitHub generator is a practical starting point. It can produce provenance for workflow runs and attach the resulting attestation to the artefact. This is attractive because it reduces the amount of custom logic you need to maintain. It also aligns well with ephemeral runners and OIDC-based identity, which are easier to reason about than self-managed signing keys in many small teams.

Even so, you still need to harden the workflow. Restrict who can modify workflow files, pin action versions, avoid over-privileged tokens, and separate build and release jobs. Provenance is only as strong as the pipeline that produces it.

GitLab and other CI systems

GitLab and other CI systems can also produce provenance, but the implementation may be less turnkey. In those environments, teams often combine build metadata capture, signing tools, and attestation publication into a custom job. The design goal is the same: generate a signed statement that binds the artefact to a specific source revision and builder.

If you are using self-hosted runners, the trust model becomes more important. The runner should be isolated, patched, and tightly controlled. If the runner can be tampered with by untrusted jobs or users, provenance may still be generated, but the confidence you place in it should be lower.

When to use hosted tooling versus custom pipeline logic

Hosted tooling is usually the better choice when you want faster adoption and less maintenance. Custom pipeline logic makes sense when you need to integrate with legacy release processes, unusual artefact formats, or strict internal controls. A common pattern is to use hosted provenance generation for the main build and then wrap it with internal policy checks that decide whether the artefact can be promoted.

For teams already thinking about pipeline security, this sits naturally alongside controls such as secret handling, branch protection, and build isolation. If you have not yet reviewed your CI attack surface, it is worth pairing this work with embedding security into CI/CD pipelines without slowing teams.

Generating provenance in a CI pipeline

At a practical level, provenance generation should happen as part of the release build, after the artefact has been created and before it is published. The pipeline should capture enough context to make the attestation meaningful, but not so much that it becomes brittle or hard to verify.

Capturing source revision and build parameters

At minimum, capture the repository URL, commit SHA, workflow or pipeline identifier, build timestamp, and artefact digest. If your build accepts parameters, record the ones that affect output, such as target platform, feature flags, or version numbers. For container images, include the image digest rather than just the tag, because tags are mutable and not suitable for verification.

A common implementation pattern is to export build metadata into environment variables or a structured file, then feed that into the attestation step. For example, a pipeline might record GIT_SHA, BUILD_ID, IMAGE_DIGEST, and RELEASE_VERSION, then use those values to create the provenance statement. The important part is consistency. If the verifier expects a specific source revision and digest, the pipeline must emit them reliably.

Producing provenance for binaries, containers, and release artefacts

For binaries, provenance should bind the compiled output to the source revision and build job. For containers, it should bind the pushed image digest to the build workflow and base image inputs. For packaged artefacts such as ZIP files or installers, the same principle applies. The artefact digest is the anchor, and the provenance statement is the evidence that explains how that digest was produced.

In some cases, you may also want to sign the artefact itself in addition to producing provenance. That gives downstream systems two checks: one for integrity of the file and one for origin of the build. This is often a sensible pattern when artefacts are distributed outside your immediate control.

Verifying provenance before release or consumption

Verification should be treated as a policy decision, not a manual curiosity. If an artefact cannot be verified against the expected source and builder claims, it should not be promoted. That is true whether the artefact is destined for production, a customer environment, or an internal deployment.

Using slsa-verifier to check expected source and builder claims

The slsa-verifier tool is commonly used to validate provenance against expected values. The general pattern is to provide the artefact, the provenance file or URL, and the expected repository, commit, and builder identity. The verifier then checks that the attestation matches those expectations and that the artefact digest is covered by the provenance.

A typical verification flow looks like this in principle:

slsa-verifier verify-artifact \
  --provenance-path provenance.intoto.jsonl \
  --source-uri github.com/example/repo \
  --source-tag v1.2.3 \
  --builder-id https://github.com/example/repo/.github/workflows/release.yml@refs/heads/main \
  ./release-artifact.tar.gz

The exact flags vary by release and provenance format, so you should align the command with the version you are using. The important thing is the policy behind the command: verify the source, verify the builder, and verify the digest before trusting the artefact.

Validating signatures and trusted build identities

Signature validation is the second half of the problem. A provenance statement that looks correct but is not signed by a trusted identity should be rejected. Depending on your platform, that trust may come from a public key, a certificate chain, or an identity token tied to the CI system. The verifier should only accept identities that you have explicitly approved.

For UK SMEs, a sensible operational model is to maintain a small allow list of trusted builders and workflows. That list should be reviewed when pipelines change, when repositories are renamed, or when release responsibilities move between teams. If you are already using signed container images, provenance verification can sit alongside that control rather than replacing it.

How to make provenance useful in real operations

Provenance becomes valuable when it changes how releases are handled. If it is just archived and never checked, it adds little operational value. The strongest use cases are release gating, promotion between environments, and incident response.

Release gating and artifact promotion

One effective pattern is to require provenance verification before an artefact can move from build to staging, or from staging to production. That can be implemented in a deployment pipeline, a release approval step, or an artefact repository policy. The gate should check that the provenance is present, valid, and tied to the expected source revision and builder.

This is especially useful where multiple teams consume the same artefact. A single verification step upstream reduces the chance that an untrusted or tampered build reaches several environments. It also creates a clear control point for change management.

Storage, retention, and traceability for investigations

Keep provenance records for as long as you need to support investigations and release traceability. Store them with the artefact metadata or in a repository that can be queried later. If a customer reports an issue, provenance helps you identify the exact build, source revision, and pipeline path involved. That can save time during triage and reduce uncertainty about whether the artefact was built from the intended code.

Retention should be aligned with your broader evidence handling and logging approach. If you already have a process for retaining investigation evidence, provenance should be part of that same discipline.

Common implementation pitfalls

The most common mistake is to treat provenance as a box-ticking exercise. The second is to assume that any attestation is trustworthy just because it exists. Both lead to weak assurance.

Untrusted runners and weak builder isolation

If your build runners are shared, poorly patched, or exposed to untrusted jobs, the provenance may still be syntactically valid but operationally weak. An attacker who can influence the build environment may be able to produce a legitimate-looking attestation for a malicious artefact. That is why runner isolation, least privilege, and workflow protection are part of the same control set.

For self-hosted runners, keep the host hardened, limit network access, and separate privileged release jobs from ordinary build jobs. If you cannot isolate the runner properly, you should be cautious about how much trust you place in the resulting provenance.

Mismatch between provenance claims and actual build behaviour

Another pitfall is claiming more than the pipeline actually enforces. For example, a provenance statement may say the artefact was built from a tagged release, but the pipeline may still allow mutable dependencies, unpinned actions, or ad hoc scripts. In that case, the attestation is technically correct but not especially reassuring.

The remedy is to make the build behaviour match the claims you want to rely on. Pin dependencies, lock workflow versions, avoid hidden network fetches, and keep the build definition under change control. If you want provenance to support trust, the pipeline itself must be predictable.

How SLSA provenance complements other supply chain controls

Provenance is strongest when used with other controls rather than on its own. Signing, SBOMs, dependency management, and pipeline hardening each address a different part of the risk picture. Together they create a more defensible release process.

Relationship to SBOMs, dependency pinning, and signing

SBOMs tell you what is in the artefact. Dependency pinning reduces the chance that the build changes unexpectedly. Signing protects the integrity of the artefact or metadata. Provenance ties the artefact to the build process that produced it. If you are already using controls such as verifying supplier compliance with secure software requirements, provenance gives you a concrete artefact-level artefact trail to ask for and validate.

That combination is particularly useful when you buy software from suppliers or consume open source artefacts in production. It gives you more than a promise. It gives you evidence.

Using provenance alongside policy checks in CI/CD

Provenance verification should be one policy check among several. You may also require SAST results, dependency scan thresholds, container image policy checks, and approval workflows. The point is not to overload the pipeline, but to make release decisions based on evidence rather than assumption.

For teams that already use policy-as-code, provenance verification can be expressed as another gate. That keeps the control repeatable and auditable without turning it into a manual process.

A pragmatic adoption path for UK SMEs

You do not need to roll this out everywhere at once. A sensible approach is to start with one critical pipeline and one artefact type, then expand once the process is stable. That keeps the work manageable and gives you a chance to refine the trust model before broadening it.

Start with one critical pipeline and one artifact type

Choose a release that matters, such as a customer-facing service or a production container image. Add provenance generation to that pipeline, then add verification at the point where the artefact is promoted or deployed. Make sure the team understands what the verifier checks and what it does not.

Once that is working, document the expected source, builder, and digest values. That documentation becomes part of your operational runbook and makes future troubleshooting much easier.

Expand coverage as build maturity improves

After the first pipeline is stable, extend the pattern to other services and artefact types. At the same time, improve the surrounding controls. Tighten runner isolation, reduce reliance on mutable build inputs, and standardise release metadata. The more consistent your build estate becomes, the more useful provenance will be across the organisation.

For SMEs that want a broader view of how this fits into governance and control design, it can help to relate the work back to your wider secure development approach, such as the principles covered in Secure Software Development – Why It Matters.

Used well, SLSA provenance gives you a practical way to prove where an artefact came from and whether it was produced by the build process you expected. It is not a silver bullet, but it is a strong and increasingly important part of software supply chain assurance. If you want help shaping a rollout that fits your CI platform, release process, and risk appetite, Speak to a consultant.

Frequently asked questions

What is the difference between SLSA build provenance and an SBOM?

An SBOM describes what is inside an artefact, usually its components and dependencies. SLSA build provenance describes how the artefact was produced, including the source, builder, and build context. They answer different questions and work best together.

How do you verify SLSA build provenance for an artefact?

Use a verifier such as slsa-verifier to check that the attestation matches the expected source repository, commit or tag, builder identity, and artefact digest. If the signature or claims do not match the policy you expect, the artefact should not be trusted.

Do we need SLSA level 3 to benefit from provenance?

No. You can gain value from provenance before reaching higher SLSA levels. Even basic provenance improves traceability and release confidence, provided the build environment and verification process are controlled.

Can provenance be verified for third-party artefacts?

Yes, if the supplier publishes provenance in a format you can verify and you know which source and builder claims to expect. The practical challenge is trust: you need a clear policy for which builders, identities, and artefact types you will accept.