Manual attestation creation is risky because it depends on people remembering to instrument every artifact and keep that logic updated as build systems change. In complex pipelines, that creates gaps, inconsistent evidence, and weak audit trails. It also makes root cause analysis harder when incidents occur because the provenance chain may be incomplete or unreliable.
Why manual SLSA attestations break down in real build pipelines
Manual attestation creation sounds simple until the pipeline changes. Build steps move, images get split, jobs are parameterised, and teams forget to update the attestation logic everywhere it is needed. At that point the provenance record becomes only partly true, which defeats the point of having a trustworthy build record in the first place.
The practical problem is not just that a person can make a mistake once. It is that manual attestation depends on repeated human awareness across a system that is designed to change frequently. In modern delivery chains, even small gaps can leave one artifact covered and another unrecorded, or produce evidence that looks complete but does not actually describe the real build path.
That is why provenance systems are meant to be generated by the pipeline itself rather than assembled after the fact. SLSA exists to make build provenance SLSA verifiable, and the more manual the process becomes, the easier it is for the evidence chain to drift away from the actual release process. The same failure pattern shows up in supply-chain incidents where build-time assumptions, secrets handling, or artifact promotion were not reflected consistently in the recorded evidence, such as the CI/CD pipeline exploitation case study and the Reviewdog GitHub Action supply chain attack.
Where the provenance chain becomes unreliable
Manual attestations tend to fail in the same places that modern pipelines are most dynamic. Artifact fan-out, reusable workflows, transient runners, container rebuilds, and multiple promotion stages all increase the number of spots where someone must remember to emit or update evidence. If attestation generation is tied to a script or checklist, it can lag behind the actual build graph even when the software output is still correct.
That creates two separate problems. First, the attestation may be incomplete, so downstream consumers cannot prove which inputs, steps, and environments produced the artifact. Second, the attestation may be inconsistent, with different teams or jobs describing the same release in slightly different ways. Both conditions weaken auditability because provenance is only valuable when it is machine-readable, repeatable, and tied to the execution path rather than to post-build recollection.
This is why practitioners should treat provenance generation as part of the build control plane, not as a documentation task. Guidance from the OWASP SAMM model supports embedding security into the delivery lifecycle, while the SLSA model gives the integrity target for that evidence. When the build system changes, the attestation mechanism has to change with it or the record becomes stale by design.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS — Data Security | Build provenance protects the integrity of software artifacts and release evidence. |
| GV.RM — Risk Management Strategy | Manual provenance creates operational and supply-chain risk that needs governance. | |
| DE.CM — Continuous Monitoring | Pipeline drift and missing attestation coverage require ongoing monitoring. | |
| Recommendation — Bind provenance generation to the artifact pipeline and protect integrity of build outputs. Define automated provenance as a required control in the release-risk strategy. Monitor build paths for missing or inconsistent provenance generation. | ||
| CIS Controls v8 | 6 — Access Control Management | Trusted build evidence depends on tightly controlled pipeline and artifact privileges. |
| 8 — Audit Log Management | Attestations function as audit evidence and need reliable, consistent logging. | |
| Recommendation — Restrict who and what can alter build and attestation steps. Centralise immutable build and provenance logs for later verification. | ||
| MITRE ATT&CK | T1195 — Supply Chain Compromise | Weak provenance and manual evidence handling increase supply-chain compromise exposure. |
| Recommendation — Hunt for tampered build inputs and untrusted pipeline changes. | ||
Practitioner Guidance
What to prioritise: Ensure attestation is emitted automatically from the same trusted pipeline stage that produces the artifact. If the attestation can be created separately from the build, assume drift will eventually appear.
What to verify: Confirm that every build path, branch, runner type, and artifact variant is covered by the same provenance logic. A single uncovered path is enough to create a false sense of supply-chain assurance.
Common mistake: Treating attestation as a one-time compliance feature instead of a living control. In fast-moving pipelines, the control must be maintained alongside build changes, dependency changes, and release topology changes.
Practitioner takeaway: The real control objective is not “having an attestation”, it is ensuring the attestation is automatically bound to the exact artifact-producing execution path, otherwise the evidence may be present while the trust signal is not.
