Topic starter
18/08/2026 2:19 pm
TL;DR: Generating provenance is now common, but risk only changes when provenance is enforced at deployment through signed attestations, admission control, and policy engines, according to Kusari. The operational gap is not build visibility but machine-verifiable approval, because documentation without enforcement does not prevent untrusted software from shipping.
Editorial analysis by NHI Mgmt Group, based on content published by Kusari: “From Provenance to Enforcement: SLSA, in-toto, and Kubernetes Admission Control”.
Key questions
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 is provenance generation alone not enough to reduce software supply chain risk
A: Because provenance only changes risk when it is enforced.
Q: What breaks when software provenance is not enforced at the release gate?
A: The release gate becomes a documentation checkpoint rather than a security control.
Practitioner guidance
- Enforce provenance at deployment Require the admission layer to reject artifacts that cannot present valid signed provenance, approved builder identity, and matching source claims before the workload is created.
- Bind release policy to workload identity Make the build and release path depend on verifiable workload identity, so the platform can check who produced the artifact and whether that identity was authorised.
- Make provenance checks mandatory in Kubernetes Configure admission control so missing attestations, untrusted signers, or unapproved workflow hashes fail closed instead of falling back to manual review.
Bottom line: Provenance only changes security posture when the deployment layer can enforce it as a hard control.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
18/08/2026 3:11 pm
Provenance enforcement is the control boundary, not provenance generation. Generating attestations improves visibility, but it does not change risk unless the deployment system can refuse software that fails policy. That is the distinction between documentation and control. For security and platform teams, the operational question is whether trust is asserted by humans or proven by the platform.
A few things that frame the scale:
- Kubernetes production adoption has surged from 66% in CNCF's 2023 survey to 82% in 2025.
A question worth separating out:
Q: What is the difference between build attestations and deployment policy?
A: 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.
👉 Read our full editorial: Provenance enforcement is the missing control in software supply chains