Use the in-toto Framework to define and verify supply chain steps, then require each step to be signed by the expected actor before promotion. Keep layouts or policies strict, separate duties across build, test, and release stages, and fail closed when metadata is missing or altered. Review unexpected step changes as potential tampering or process drift.
How in-toto best practice starts with a strict layout or policy
The core discipline is to treat in-toto as a policy enforcement layer for the supply chain, not just a signing format. Define each expected step, the authorised function for that step, and the artefact transitions it is allowed to make. Keep the policy strict enough that an unexpected step or missing metadata blocks promotion rather than being waved through.
That strictness matters because in-toto is most valuable when it expresses the intended process, then verifies that the recorded execution matches it. If the layout is too permissive, a compromised or misconfigured stage can still produce signed metadata that looks legitimate but no longer reflects the trusted path.
Why signing, separation of duties, and provenance integrity go together
Best practice is to require each step to be signed by the expected actor and to separate duties across build, test, and release stages so that no single principal can silently authorise the whole chain. That gives you a clear trust boundary between creation, verification, and publication, and it makes tampering or skipped controls easier to detect.
Use the strongest provenance controls you can support, including hermetic or reproducible builds where practical, because in-toto is only as trustworthy as the evidence each step emits. The SLSA and Build Provenance Guide is a useful companion when you want the in-toto model tied to build provenance, attestations, and deploy-time checks. For organisations that also manage API credentials in the delivery chain, the API Key Management Guide is relevant when signed steps depend on keys, tokens, or other secrets that must be scoped and rotated.
What to review when metadata changes, disappears, or looks inconsistent
A healthy in-toto workflow treats altered, incomplete, or unexpected metadata as a security signal, not a nuisance. Review step order changes, unplanned tool substitutions, missing signatures, and abnormal provenance transitions as possible tampering, process drift, or an operational exception that needs documented approval.
That review should focus on whether the chain still proves the same actor, same step, and same artefact transition that the layout expected. If any of those elements cannot be demonstrated, the safe default is to stop promotion and investigate whether the deviation is benign or evidence of compromise.
Risk and Threat Considerations
In-toto reduces supply-chain trust to verifiable step-by-step evidence, but that also makes layout weakness, signer compromise, or metadata tampering directly security-relevant. A permissive policy, a stolen signing key, or an unmonitored step change can let altered artefacts move forward with a false appearance of provenance.
Failure mechanism: An attacker or accidental process change abuses a weak policy, missing signature check, or uncontrolled step transition to produce metadata that still passes basic validation while no longer representing the intended build path.
Impact: Malicious or altered artefacts can be promoted, traceability can break down, and incident response may lose the evidence needed to prove where integrity was lost or which stage introduced the problem.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while SLSA and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply-chain Levels for Software Artifacts | In-toto is central to software provenance and signed build evidence. |
| Recommendation — Use provenance attestations to verify each supply-chain step before release. | ||
| NIST SP 800-53 Rev 5 | SA-12 — Supply Chain Protection | The subject concerns supply-chain integrity, provenance, and controlled promotion of artefacts. |
| CM-3 — Configuration Change Control | Unexpected step changes and policy drift require controlled review and approval. | |
| SI-7 — Software, Firmware, and Information Integrity | Signed metadata and altered artefacts map to integrity verification and tamper detection. | |
| Recommendation — Apply supply-chain protection controls to validate artefact provenance and integrity. Enforce change control for pipeline layouts, steps, and release-policy updates. Verify integrity before promotion and block artefacts with missing or altered evidence. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Signed provenance depends on secrets and keys that must not be exposed or misused. |
| Recommendation — Protect signing secrets and rotate them immediately if provenance credentials leak. | ||
Practitioner Guidance
What to verify: Confirm that every critical step has an expected signer, a clear input-output boundary, and a blocking rule for missing or altered metadata. If a step can still pass when its attestation is incomplete, the control is too weak to trust.
Decision rule: If the change affects signer identity, artefact lineage, or step ordering, treat it as a security-relevant deviation and stop promotion until it is explained. If the change is operationally normal, codify it in the layout or policy so the next run is not forced into ad hoc approval.
Practitioner takeaway: In-toto works best when it is opinionated, promotion should be evidence-driven, and any gap in the expected chain should be treated as a failed control rather than a minor exception.