Release-time verification is the decisive control because it is the moment an artifact becomes trusted for deployment. Source-step checks are still useful for visibility, but they do not stop a modified jar from moving forward unless promotion is tied to attestation policy. The safest model is to verify at both points, with release as the enforcement boundary.
Where build provenance checks should happen
Teams should treat release-time verification as the control that decides whether a build can be trusted for deployment. Source-step checks still matter, but they are best understood as an earlier visibility and quality signal, not the final trust decision. If an artifact is going to be promoted, the promotion gate should require a valid attestation or equivalent provenance proof.
The practical distinction is between detection and enforcement. A source-step check can tell you that the build process produced something plausible, but it does not stop a later tampering event, a substituted jar, or a compromised pipeline stage from reaching production unless the release boundary also re-checks provenance and policy.
That is why the strongest model is dual verification: verify early to catch drift quickly, then verify again when the artifact is about to cross into the trusted release path. In a pipeline context, provenance is only operationally meaningful when the deployment decision consumes it.
Why release-time verification is the trust boundary
Release time is where the risk becomes concrete because the artifact is no longer just a build output, it is a candidate for runtime trust. The control question is not whether the source looked clean at some point earlier, but whether the exact artifact being deployed still matches the expected provenance, signing state, and policy conditions at the moment of promotion.
This matters most when builds are stored, copied, re-tagged, or passed through multiple hands and systems. Any gap between the source check and the release event creates room for substitution, unauthorized rebuilds, or provenance bypass unless the release system validates the artifact directly against the attestation record.
Source-step verification is still useful because it improves traceability and shortens investigation time when something looks wrong. It gives teams evidence about how the artifact was created, but the deployment decision still needs a fresh check against the artifact that is actually entering release.
What teams should verify in practice
What matters most is that the release gate verifies the artifact, not just the repository state or the build job outcome. Teams should ensure the deployment system can compare the candidate binary or package with its provenance evidence and reject promotion when the attestation is missing, malformed, unsigned, or inconsistent with policy.
- Confirm the release workflow checks the exact artifact that will be deployed.
- Require provenance or attestation validation as a promotion criterion.
- Keep source-step checks as an earlier signal for visibility and triage.
- Fail closed when provenance cannot be validated at release time.
The key operational judgment is to align trust with the control point that actually changes blast radius. If the artifact can reach production without a release-time check, the organization is relying on a historical signal instead of a current trust decision.
Risk and Threat Considerations
Release-time gaps create a clear attack window because an adversary only needs one uncontrolled handoff, cache, registry path, or promotion step to substitute a different artifact after the source check has already passed. That is why source-only verification is vulnerable to tampering that occurs later in the pipeline.
Failure mechanism: A valid early attestation is treated as permanent proof, while the deployed artifact is allowed to move through later stages without being revalidated. This lets modified or repackaged software inherit trust it no longer deserves.
Impact: A compromised build can be promoted into production, which turns provenance failure into supply-chain compromise, deployment of unauthorized code, and harder incident response because the trust boundary was crossed without a final check.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
SLSA, NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP SAMM set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply-chain Levels for Software Artifacts | Build provenance and release verification are the core subject here. |
| Recommendation — Validate release-time provenance before promoting artifacts into deployment. | ||
| NIST SP 800-53 Rev 5 | SI-7 — Software, Firmware, and Information Integrity | The question centers on verifying artifact integrity before deployment. |
| CM-3 — Configuration Change Control | Release-time provenance checks enforce controlled promotion of changed artifacts. | |
| Recommendation — Require integrity verification at the deployment boundary and reject untrusted artifacts. Gate promotion so only approved, traceable builds can reach release. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Software delivery integrity and validation are central to safe release decisions. |
| Recommendation — Embed release gates that verify signed, trusted software before deployment. | ||
| OWASP SAMM | Software Assurance Maturity Model | The question concerns security assurance in the software delivery lifecycle. |
| Recommendation — Assess delivery practices so provenance checks are enforced at the release stage. | ||
Practitioner Guidance
Decision rule: If the artifact is eligible for deployment, treat release-time provenance verification as mandatory and source-step verification as supplementary. If your pipeline cannot enforce that rule, the control is advisory rather than protective.
What to verify: Make sure the release system validates the same artifact hash, signature, or attestation that was produced upstream, not a renamed or rebuilt substitute. The evidence should be tied to the deployment candidate, not just to the build job.
Common mistake: Teams often equate a successful build attestation with deployability. That shortcut misses the time gap between creation and release, which is exactly where provenance can be lost or manipulated.
Practitioner takeaway: The safest pattern is to verify provenance twice, but to enforce it at release, because trust becomes operationally real only when the artifact is about to be deployed.
Related resources from NHI Mgmt Group
- How should security teams verify software provenance before production release?
- How should teams reduce the risk of orphaned service accounts and stale tokens?
- Why do source-code leaks from build pipelines matter to IAM and NHI teams?
- How should security teams evaluate build provenance for kernel-level identity products?