What breaks when software attestations are treated as documentation

Why This Matters for Security Teams

When software attestations are treated as documentation, they stop being a control and become an artefact. That is a dangerous shift because an attestation can prove what was built, signed, or scanned, but it does not itself stop deployment. Security teams often assume the mere existence of provenance evidence closes the trust gap, when the real question is whether runtime policy checks can block an untrusted release at the gate.

This matters because release pipelines are now part of the identity plane. If a build system, CI runner, or deployment controller accepts attestations without verifying them automatically, then an attacker who reaches the pipeline can still ship malicious software with a clean paper trail. Guidance from the NIST Cybersecurity Framework 2.0 is clear on the need to operationalise security outcomes, not just record them, and NHIMG’s Ultimate Guide to NHIs shows how often identity controls fail when they exist only on paper.

The practical risk is especially high where service accounts, CI/CD tokens, and deployment agents are overprivileged or poorly governed. In practice, many security teams encounter malicious releases only after an incident has already moved from build systems into production, rather than through intentional release approval.

How It Works in Practice

Effective attestation handling requires policy enforcement at the moment of release, not just storage for audit. The attestation should be evaluated by the deployment system, admission controller, or release gate, and the decision should be tied to workload identity, signature validity, build source, and policy context. That is the operational difference between evidence and control.

For software supply chain, this usually means combining signed provenance with automated verification. The attestation must be checked against an allowed builder, a trusted source repository, and a known policy set before the artifact can progress. In Zero Trust terms, trust is never assumed because an image was previously scanned; it is re-evaluated when the system is about to use it. The Ultimate Guide to NHIs is useful here because the same principle applies to non-human identities: proof is only meaningful when enforced at the point of access.

Practitioners typically implement this with:

• Admission controls that reject artifacts lacking required attestations or trusted signatures
• Policy-as-code rules that validate provenance, issuer, and build context at request time
• Short-lived deployment credentials so release tooling cannot bypass controls later
• Separate duties between attestation creation, storage, and enforcement

Current guidance suggests the strongest model is one where attestations are machine-consumed, not human-reviewed, because human review happens too late and scales poorly. The NIST Cybersecurity Framework 2.0 reinforces this outcomes-based approach, while identity governance research from NHIMG shows why static trust assumptions fail when credentials and permissions are reused across systems. These controls tend to break down when deployment pipelines are loosely coupled, because the system that records the attestation is not the same system that authorises release.

Common Variations and Edge Cases

Tighter attestation enforcement often increases pipeline friction, requiring organisations to balance release speed against assurance. That tradeoff is real, especially in polyglot builds, multi-cloud delivery, and legacy CD systems that were never designed to consume machine-readable policy.

There is no universal standard for this yet, so best practice is evolving. Some organisations treat attestations as a hard gate for production only, while allowing softer checks in lower environments to preserve developer velocity. Others apply different trust thresholds by workload sensitivity, which is often more practical than a single all-or-nothing policy. The key point is that documentation alone does not create security unless a controller acts on it.

Edge cases also matter. Air-gapped environments may verify attestations manually, but manual review is weaker and harder to scale. Multi-tenant platforms may need stronger issuer separation so one team cannot reuse another team’s provenance chain. And where build systems use long-lived secrets, the entire attestation model can be undermined because a compromised builder can still produce technically valid but malicious output. NHIMG’s identity guidance highlights this broader issue: when non-human identities are overprivileged or poorly rotated, assurance artifacts lose meaning fast. In practice, the failure shows up when a signed artifact is deployed successfully even though the policy service that should have rejected it was bypassed, unavailable, or never integrated.

Related resources from NHI Mgmt Group

• What breaks when ISO 27001 is treated as a documentation exercise only?
• What breaks when API documentation and contract design are treated separately?
• What breaks when remote support tools are treated as normal user software?
• What breaks when software attestations are based on incomplete pipeline visibility?