Build attestations describe what happened during production of an artifact, while deployment policy decides whether that artifact may run. Both matter, but they serve different purposes. Attestations provide verifiable evidence, and policy uses that evidence to allow or deny release. Without policy, attestations are informative but not protective.
How build attestations and deployment policy differ
Build attestations and deployment policy sit at different points in the software delivery chain. An attestation is evidence, a policy is a decision rule. The attestation answers what was built, by whom or by what process, and under what conditions; the policy answers whether that artifact is allowed into a target environment. Treating them as the same control creates a false sense of security.
The practical difference is that attestations are descriptive and policy is enforceable. A signed statement about provenance, tests, or build inputs can improve trust, but it does not stop anything by itself. A deployment policy converts those statements into a release gate, so the artifact must satisfy defined conditions before it can run. That is why the attestation is necessary but not sufficient.
For practitioners, the useful distinction is that attestations usually belong to the build and supply-chain integrity layer, while deployment policy belongs to runtime admission and change control. The first asks whether the artifact is trustworthy enough to assess; the second asks whether that trust is high enough to permit execution in a given context.
What attestations tell you that policy cannot
Attestations preserve verifiable claims about the artifact lifecycle, such as source provenance, build environment, and signing state. They are valuable because they make later verification possible, especially when a release has to be investigated, compared, or reproduced. In other words, they create evidence that can be consumed by humans or machines, but they do not on their own grant access.
This matters because a deployment policy is only as good as the evidence it checks. If the policy simply asks for a signature, it may confirm integrity but not build quality. If it checks for a provenance statement, it may confirm origin but not whether the artifact met the organisation’s own release criteria. The attestation supplies the facts, while the policy decides which facts count.
A good way to think about the separation is that attestations are inputs to trust decisions, not the trust decision itself. That is why SLSA is often discussed alongside provenance and build integrity, while release gating still needs an explicit rule set that can consume those signals.
How deployment policy changes the outcome
Deployment policy is where evidence becomes protection. A policy can require a minimum provenance level, a valid signature, a passing vulnerability threshold, or a specific approver before an artifact is admitted. Without that enforcement layer, even strong attestations remain informational, because nothing stops a weak or untrusted artifact from being deployed anyway.
Policy also gives organisations a consistent decision point across environments. The same artifact may be acceptable in a test cluster but blocked in production, or allowed only after extra controls are met. That flexibility is important because trust is contextual. A build attestation alone cannot express those environment-specific thresholds, but a policy can.
For software delivery teams, this is the difference between knowing an artifact is well described and knowing it has met the organisation’s release standard. Frameworks such as OWASP SAMM help structure secure delivery maturity, while SLSA gives provenance a more concrete footing for policy decisions.
Risk and Threat Considerations
The main risk is trusting evidence without enforcing it. If attestations are collected but never checked at deployment time, an attacker, compromised build pipeline, or misconfigured release process can still push untrusted code into production. The weakness is not the absence of evidence, it is the absence of a gate that uses the evidence.
Failure mechanism: The pipeline records provenance or build metadata, but the admission path does not validate it, or validates it only in a low-risk environment. That leaves a gap between “known” and “blocked”, which is exactly where unsafe artifacts slip through.
Impact: Malicious, tampered, or noncompliant artifacts can run despite having a paper trail. The result is reduced supply-chain assurance, weaker incident attribution, and a larger blast radius if the build or release process has been compromised.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
SLSA, OWASP SAMM, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply-chain Levels for Software Artifacts | Build attestations and provenance are central to software artifact integrity. |
| Recommendation — Require provenance evidence before admitting artifacts into release gates. | ||
| OWASP SAMM | Software Assurance Maturity Model | Secure delivery maturity covers how build evidence and release controls fit together. |
| Recommendation — Use SAMM to align build assurance evidence with release governance. | ||
| NIST SP 800-53 Rev 5 | CM-3 — Configuration Change Control | Deployment policy is a change-control decision about what may enter production. |
| SI-7 — Software, Firmware, and Information Integrity | Attestations support integrity checks for software artifacts before deployment. | |
| Recommendation — Apply CM-3 to enforce approval and control before production release. Use SI-7 to validate artifact integrity evidence before execution. | ||
| NIST CSF 2.0 | PR.DS-08 — Integrity is protected through verification of software, data, and records | Attestation and policy together protect software integrity through verification. |
| Recommendation — Verify software integrity evidence before allowing production execution. | ||
Practitioner Guidance
What to verify: Confirm that the deployment system checks the specific attestation fields you actually rely on, not just that an attestation exists. If provenance, signer identity, and build constraints matter, each of those should be enforceable at admission, not only reviewable after the fact.
Decision rule: If the artifact can execute in production without the policy reading the attestation, you have evidence collection, not release control. Treat that as a control gap even if the build pipeline is otherwise well instrumented.
What good looks like: The build emits attestations that are retained and queryable, and the deployment path rejects artifacts that fail policy conditions by default. In mature setups, operators can explain both why an artifact is trusted and why it was allowed to run.
Practitioner takeaway: Attestation answers “can we trust this artifact?”, while deployment policy answers “should we let it run?” Security only improves when the second question is enforced with the first as evidence.
Related resources from NHI Mgmt Group
- What is the difference between build-time scanning and deployment-time policy checks?
- What is the difference between privilege reduction and secret rotation?
- What is the difference between a rules-based secret scanner and a hybrid scanner?
- What is the difference between code scanning and runtime identity monitoring?