SLSA Provenance: Verify the Software Supply Chain

Knowing that an artifact is signed answers only part of the supply-chain question. Defenders also need to know which source produced it, which build system ran, and whether those facts match policy. SLSA provenance provides verifiable metadata for that decision.

Provenance is useful only when a consumer verifies it. Collecting attestations without enforcement creates documentation, not a security boundary.

What SLSA Provenance Describes

The SLSA 1.2 specification defines tracks and increasing security guarantees. Its provenance model connects an artifact to the process that produced it.

A build attestation can describe:

• artifact digest;
• source repository and revision;
• builder identity;
• build parameters and environment details;
• timestamps and invocation metadata;
• declared dependencies or materials.

The exact content depends on the format and platform. Treat provenance as a statement from an issuer whose identity and security you must evaluate.

Threats Provenance Helps Address

Verification can detect an artifact that:

• does not match the attested digest;
• came from an unexpected repository or revision;
• was built by an unapproved system;
• used parameters outside policy;
• lacks the required SLSA level or attestation;
• was substituted after the build.

It does not prove the source code is benign, the dependencies are safe or the build platform has no malicious insider. The trust boundary becomes explicit rather than magical.

Define Expectations Before Verification

For each production artifact, document:

• allowed source repository and protected branch;
• approved builder identity;
• required review and test controls;
• permitted workflow or reusable pipeline;
• artifact name and registry;
• minimum provenance and signature policy;
• exception owner and expiry.

Verification compares the attestation with these expectations. “Signature valid” is insufficient when any repository or builder can satisfy the cryptography.

Integrate Provenance Into CI/CD

Generate provenance inside a trusted build service, not as an afterthought on a developer laptop. Bind the attestation to the immutable artifact digest and distribute it with the artifact.

Verify at several points:

1. when publishing to a registry;
2. when promoting between environments;
3. at deployment admission;
4. during periodic inventory review;
5. during incident response.

Fail closed for mature, high-value paths. During rollout, start in report-only mode to learn legitimate variants, then reduce exceptions.

Connect Provenance With Other Evidence

An SBOM lists components; provenance explains how the artifact was built; signatures bind identity and content; vulnerability intelligence evaluates known risk. None replaces the others.

When a component is suspicious, use the SBOM analysis workflow to find affected artifacts. Use file hash reputation and network intelligence when runtime evidence suggests compromise.

The SLSA verification guidance emphasizes checking artifact digest, predicate type, builder and expectations. Make those checks visible in logs so an analyst can explain a rejection.

Incident Response

If provenance verification fails, quarantine the artifact and preserve the binary, attestation, signature, registry logs and build records. Determine whether the cause is policy drift, a broken pipeline, key or identity compromise, or artifact substitution.

Search for deployments of the same digest and other artifacts from the suspect builder. Rebuild from a known-good source and trusted builder only after the failure path is understood.

Metrics

Track production artifacts with verified provenance, verification failures by cause, unowned exceptions, approved builders, time to trace an artifact to source and deployments blocked before execution. Measure verification, not attestation generation alone.

Conclusion

SLSA provenance converts “we think this came from our pipeline” into a verifiable claim. Define expectations, generate metadata in a trusted builder and enforce it where artifacts move. Pair provenance with SBOM and vulnerability response to cover both origin and known risk.