Notifications
Clear all
Topic starter
18/08/2026 2:24 pm
TL;DR: Software supply chain security is shifting from scanning to verifiable production integrity, with Kusari arguing that provenance, signing, and admission control are now necessary to prove where software came from and whether it was altered. The practical threshold is no longer documentation but enforced, cryptographic trust that can withstand audits, incidents, and regulatory scrutiny.
NHIMG editorial — based on content published by Kusari: verifiable software provenance and SLSA in modern cloud-native delivery
Questions worth separating out
Q: How should security teams verify software provenance before production release?
A: Security teams should require cryptographic attestations that bind an artifact to its source commit, build environment, and signer, then enforce those checks at deployment time.
Q: Why are SBOMs not enough to secure the software supply chain?
A: SBOMs improve visibility into what is inside a package, but they do not prove who built it or whether the build was tampered with.
Q: What breaks when software release trust is not enforced?
A: When trust is not enforced, teams can no longer distinguish legitimate builds from altered or replayed artifacts at deployment time.
Practitioner guidance
- Inventory build identities and signing authorities Map every system that can produce, sign, or promote artifacts, then assign ownership, scope, and review cadence so release authority is explicit rather than implicit.
- Require cryptographic provenance for production releases Block promotion of images and packages unless they carry verifiable provenance that ties the artifact to source, build environment, and signing authority.
- Enforce admission control at deployment time Use cluster admission policy to reject unsigned or untrusted artifacts before they can run, rather than relying on downstream detection after deployment.
What's in the full article
Kusari's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step explanation of how Sigstore, in-toto, and Kubernetes admission control fit together in a cloud-native release path
- Specific guidance on moving from artifact scanning to cryptographically verifiable production integrity
- The practical trust model for keyless signing and provenance verification in modern build pipelines
- How the SLSA framework maps to production release assurance and auditability
👉 Read Kusari's analysis of verifiable software provenance and SLSA →
Software provenance and SLSA: what practitioners need to verify?
Explore further
18/08/2026 3:15 pm
Software provenance is becoming an identity problem, not just a build problem. Once release artifacts can be cryptographically tied to a known source, build system, and policy decision, supply chain trust becomes a matter of identity governance for machines. That changes the control question from âDid the pipeline run?â to âCan this artifact prove who created it and under what authority?â Practitioners should treat signing and attestation as governed identities in the delivery path.
A question worth separating out:
Q: How do admission controls help with supply chain risk accountability?
A: Admission controls create a hard decision point before software runs, so policy can deny artifacts that fail signature or provenance checks. That makes accountability clearer because release authority is tied to explicit controls rather than informal pipeline trust. It also gives security teams a measurable enforcement layer for regulated environments.
👉 Read our full editorial: Verifiable software provenance is becoming a board-level control
