What breaks when SLSA provenance is treated as the whole supply chain programme?

When provenance becomes the programme, what gets missed?

SLSA provenance is a useful integrity signal, but it is only about the artifact and how it was built. It does not, by itself, answer whether the source repository, dependencies, builders, or publishing path were trustworthy at the moment of compilation. The failure mode is narrower than the programme it is often asked to represent, which is why teams can end up over-trusting a valid attestation.

A supply chain programme has to cover more than build outputs. If you treat provenance as the whole control surface, you lose the source-layer questions that determine whether the build should have been trusted at all, including who could change the code, what dependencies were pulled in, and whether the build environment was isolated enough to resist tampering.

That is why provenance should be read as evidence about one stage in a longer trust path, not as proof that the upstream inputs were safe. The artifact may be genuine and still carry unsafe logic, poisoned dependencies, or malicious changes that entered before the attestation was created. SLSA is strongest when it is paired with source, build, and release controls rather than treated as a standalone assurance badge.

Where the trust boundary actually sits

The practical boundary is the point where source changes become build inputs. Provenance can show what builder produced an artifact and, in stronger implementations, what materials and parameters were involved. It cannot on its own prove code review quality, dependency hygiene, maintainer trust, or the absence of upstream compromise. Those are separate control questions, and collapsing them into one attestation creates a false sense of completeness.

In mature programmes, provenance is one layer in a chain that also includes source governance, protected branches, dependency verification, controlled build identities, and release approval. The source layer is especially important because it is where compromised maintainer accounts, poisoned commits, dependency confusion, and injected build steps first take effect. CI/CD Pipeline Identity Security Guide is a useful companion because it keeps the trust discussion anchored in the identities and secrets that can alter the build path.

If the source layer is weak, provenance may simply prove that an unsafe artifact was produced in a controlled way. That is still valuable, but it is not the same thing as supply chain trust. The control objective is to reduce the number of places where an attacker can insert themselves before the build evidence is created, not to let the attestation stand in for upstream assurance.

What a healthy programme uses provenance for

Used correctly, provenance helps with traceability, incident response, and policy enforcement. It lets teams answer where an artifact came from, which build system handled it, and whether the artifact matches the recorded build path. That supports verification at deploy time and makes tampering easier to detect.

What it should not do is carry the entire trust decision on its own. A strong programme treats provenance as one proof among several, then asks whether the source, build inputs, and release controls were independently sound. NIST SSDF (SP 800-218) is a good reference point here because it frames secure development as a set of practices spanning design, build, verification, and response, not just artifact signing.

That same logic applies to open source consumption. A provenance record is useful only if the organisation can also explain how it evaluates dependency risk, build integrity, and source trust before promotion. OpenSSF is relevant because it reflects the broader open source security posture that provenance alone does not replace.

Risk and Threat Considerations

When provenance is treated as the whole programme, the main risk is control blindness. Teams may deploy artifacts they can verify cryptographically while remaining unable to see that the source, builder, or dependency path was already compromised. That creates a narrow but dangerous assurance gap.

Failure mechanism: a valid attestation confirms artifact lineage, then gets mistaken for proof of source trust, dependency integrity, and build-system safety. Attackers benefit when they can influence code or build inputs before provenance is generated, because the resulting artifact can still look legitimate downstream.

Impact: the organisation gets false confidence, weaker release gating, and slower detection of poisoned source or compromised pipeline activity. In practice, this can let malicious changes ship with clean-looking build evidence and delay the investigation until after deployment.

Practitioner Guidance

What to prioritise: separate your trust controls into source, build, and release layers. Provenance belongs in the build and release layers, but source trust still needs its own review, branch protection, dependency policy, and maintainer access controls.

What to verify: confirm that the provenance record can be tied back to controlled inputs, not just to a signed artifact. If you cannot show who approved the source, what dependencies were allowed, and how the builder was isolated, the attestation is incomplete as a trust decision.

Common mistake: treating “has provenance” as equivalent to “safe to deploy.” That shortcut is acceptable only when other source and build controls are already enforced and independently monitored.

Practitioner takeaway: provenance is evidence of how an artifact was produced, not proof that every upstream trust decision was sound, so programme design should keep source assurance and build assurance separate.

Related resources from NHI Mgmt Group

• What breaks when supply chain risk is treated like vulnerability management?
• What breaks when defence supply chain governance focuses only on provenance?
• What breaks when SBOMs are treated as the main supply chain control?
• What is the difference between SLSA provenance level 2 and level 3 in enterprise supply chain security?