They should halt release promotion until provenance, validation, and approval records are restored for the affected artefacts. Missing evidence means the organisation cannot prove what it is shipping, which turns a governance gap into an operational risk. The right response is containment first, then evidence reconstruction.
Why missing supply chain evidence is a release blocker
When provenance, validation, or approval evidence is missing, the organisation no longer has a trustworthy basis for promoting the artefact. That is not just a paperwork gap. It means the release may contain unknown code, unknown build inputs, or an unverified approval path, so the safest response is to stop promotion until the evidence trail is restored.
This is especially important when the artefact is moving toward production or a regulated environment, because the missing records remove the organisation’s ability to demonstrate chain of custody. The issue is less about proving maliciousness and more about proving integrity before the software is allowed to advance.
Supply chain controls depend on the ability to answer basic questions: who built it, what was built, what was signed, what was tested, and who approved it. If one of those answers is absent, release confidence drops to the level of the weakest missing control, not the strongest present one.
What “restore the evidence” actually means
Restoring evidence means reconstructing the minimum trustworthy record needed to make a release decision. That usually includes build provenance, validation results, approval records, and a clear artefact-to-pipeline linkage so teams can confirm the item under review is the same one that was built and tested.
In practice, this often requires checking the source commit, pipeline run, signing or attestation records, dependency manifests, and any policy gates that were supposed to enforce release conditions. If those records cannot be recovered, the artefact should be treated as unverified rather than assumed safe.
The distinction matters because evidence is not only for audit after the fact. It is part of the security function of release engineering. Without it, teams cannot reliably distinguish a valid release from a repackaged, substituted, or partially processed artefact.
Containment first, then decide whether the release can recover
Once evidence is missing, the immediate job is containment, not speculation. Pause promotion, prevent automatic deployment paths from consuming the artefact, and preserve whatever pipeline, signing, or repository records still exist before they age out or are overwritten.
Then determine whether the gap is recoverable. If the missing records can be rebuilt from authoritative systems, the release may return to the queue after review. If they cannot, the safer assumption is that the artefact’s integrity is unresolved and the promotion should remain blocked.
This is where supply chain governance becomes operational. A team that allows exceptions without reconstructed proof is effectively replacing control evidence with trust in process memory, which is exactly where release failures and contamination spread.
Risk and Threat Considerations
Missing evidence creates a direct exposure window because it weakens the organisation’s ability to detect tampering, substitution, or unauthorised publishing. In a software supply chain, that uncertainty can hide compromised dependencies, poisoned build artefacts, or releases that bypassed intended approval gates.
Failure mechanism: A broken evidence chain prevents the organisation from verifying lineage, so an attacker or failed process can move an artefact forward without a credible integrity check. If promotion continues anyway, the release pipeline becomes a distribution channel for untrusted software.
Impact: The result can be downstream compromise, emergency rollback, broader trust loss in the release process, and audit failure when the organisation cannot demonstrate what was shipped or why it was approved.
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, OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply-chain Levels for Software Artifacts | Build provenance and integrity are central when release evidence is missing. |
| Recommendation — Require provenance and attestations before promoting the artefact. | ||
| NIST SP 800-53 Rev 5 | CM-8 — System Component Inventory | Evidence gaps often reflect missing artefact and pipeline traceability. |
| AU-10 — Non-repudiation | Approval and validation records support trustworthy release decisions. | |
| Recommendation — Maintain an authoritative inventory and trace each artefact to its build record. Retain tamper-resistant approval and validation evidence for every release. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Supply chain integrity depends on verifiable build and release architecture. |
| Recommendation — Design release paths so artefact integrity can be verified before deployment. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Software integrity and controlled release are core CIS software security concerns. |
| Recommendation — Block promotion when the software cannot be proven authentic and approved. | ||
Practitioner Guidance
What to prioritise: Stop promotion first, then identify whether the missing record is provenance, validation, or approval evidence. The order matters because different evidence gaps imply different recovery work, but none should be treated as a minor exception if the artefact is still headed for production.
What to verify: Confirm that the artefact hash, build output, signing or attestation record, and approval trail all point to the same release candidate. If any one of those cannot be tied together, do not rely on partial evidence or verbal confirmation.
Decision rule: If the organisation can reconstruct the evidence from authoritative systems, re-evaluate the release after containment and review. If it cannot, keep the artefact blocked and treat the incident as a supply chain integrity failure, not a routine process delay.
Practitioner takeaway: Missing evidence should be handled as a release-integrity problem, because the correct control objective is not to move faster with less proof, but to restore enough proof to ship with confidence.
Related resources from NHI Mgmt Group
- Should organisations treat licence compliance as part of software supply-chain risk?
- What breaks when code-to-cloud visibility is missing in software supply chain security?
- How should organisations use SBOMs to improve software supply chain governance?
- How do organisations prove their software supply chain controls are actually working?