Notifications
Clear all
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.
NHIMG editorial — based on content published by Kusari: Generating provenance is a start. Enforcing provenance is what changes risk posture
Questions worth separating out
Q: How should security teams enforce software provenance in Kubernetes
A: Security teams should enforce software provenance at admission, not after deployment.
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 attestations are treated as documentation
A: The trust model breaks at the point of release.
Practitioner guidance
- Make provenance mandatory at admission Require Kubernetes admission control to reject workloads that lack approved provenance attestations, valid signatures, or trusted builder claims.
- Bind build identity to release policy Map each approved build workflow, signer, and builder pool to explicit policy claims so the cluster can verify source repository, branch, workflow template, and artifact digest before deployment.
- Treat verification gaps as release blockers Escalate missing Rekor inclusion proofs, absent Cosign signatures, or mismatched OIDC claims as deployment failures rather than exceptions for manual review.
What's in the full article
Kusari's full blog post 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 pipeline
- The specific provenance claims that SLSA Level 3 expects from a controlled build environment
- How Kyverno policy can reject unsigned or untrusted workloads before they reach production
- The article's full supply chain trust model and the examples used to show how enforcement works in practice
👉 Read Kusari's analysis of provenance enforcement in software supply chains →
Software provenance enforcement: is your deployment gate doing enough?
Explore further
18/08/2026 3:11 pm
Provenance without enforcement is a governance record, not a security control. Kusari's core point is that generating attestations does not meaningfully reduce risk if the deployment path still accepts unsigned, unverified, or untrusted artifacts. Security programmes often confuse evidence creation with evidence enforcement. The practitioner conclusion is straightforward: if policy does not stop the release, provenance is informational only.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to the State of Non-Human Identity Security.
- That visibility gap matters because enforcement cannot succeed when the identities feeding the pipeline are only partially governed or not visible at all.
A question worth separating out:
Q: Who is accountable when unsigned software reaches production?
A: Accountability sits with the owners of the release process, the platform controls, and the governance team that allowed the exception path to exist. In software supply chains, release integrity is an operating model issue, not just a development issue. NIST Cybersecurity Framework 2.0 helps structure that accountability across govern, protect, and respond.
👉 Read our full editorial: Provenance enforcement is the missing control in software supply chains
