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.
At a glance
What this is: This is an analysis of why software provenance matters only when deployment gates can verify and enforce it, not when teams merely generate build attestations.
Why it matters: It matters because platform, IAM, and supply-chain security teams need verifiable release controls that bind artifacts to approved identities and policy decisions before software ships.
Context
Software provenance is the record of how an artifact was produced, including source, builder identity, build steps, and outputs. The security gap appears when that record exists but does not control deployment, because visibility alone does not stop an untrusted artifact from reaching production.
For identity governance, the important question is whether the build and release path is machine-verifiable end to end. In cloud-native delivery, provenance becomes a control only when signing, attestations, and admission policy are tied together so that the platform can reject software that fails policy.
That distinction is why provenance enforcement belongs in the same conversation as workload identity and release governance, not just software supply-chain documentation. The article treats enforcement as the point where trust becomes operational rather than assumed.
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. Provenance is only useful when the release pipeline can reject artifacts that do not meet policy. Scanning and SBOMs help, but they do not prove integrity on their own.
Q: Why is provenance generation alone not enough to reduce software supply chain risk
A: Because provenance only changes risk when it is enforced. If teams can generate attestations but still deploy artifacts without checking them, the system remains vulnerable to untrusted builds, policy drift, and weak accountability. The security outcome comes from blocking nonconforming releases, not from storing build metadata.
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. Teams may still know how an artifact was built, but they cannot prevent deployment of software that came from an unapproved builder, branch, or workflow. That leaves release governance dependent on manual review and exceptions instead of deterministic policy.
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.
Technical breakdown
Why provenance is a control, not just metadata
Provenance captures what happened during the build and release process, such as source repository, commit SHA, builder identity, and output digests. On its own, that record is descriptive. It becomes a control only when downstream systems use it to decide whether an artifact may proceed. In supply-chain terms, the attestation is the evidence, while the policy engine is the enforcement point. That distinction matters because many teams can produce signed metadata but still leave deployment decisions to human judgment or ad hoc review. When that happens, provenance documents trust instead of proving it.
Practical implication: Treat provenance as an admission condition, not a post-build report.
How in-toto and SLSA turn the build path into a verifiable contract
SLSA defines trust expectations for software builds, including controlled build environments, isolation, non-falsifiable provenance, and cryptographic signing of build metadata. in-toto extends that model across the full assembly line by describing required steps, authorised identities, and expected inputs and outputs. Together, they create a machine-checkable contract that says not only what was built, but whether each required step was performed by the right actor under the right conditions. That is why these models are useful to platform teams: they convert supply-chain trust into something policies can evaluate automatically.
Practical implication: Map build and release steps to attestations that can be verified before deployment.
What Kubernetes admission control changes at the deployment gate
Kubernetes admission control is the final enforcement point where policy can block an artifact if signatures, provenance attestations, or approved workflow claims do not match expectations. With a policy engine such as Kyverno, teams can require trusted signer identity, approved source branches, known workflow templates, and inclusion proofs before an image is admitted. This is a shift from relying on build-time controls alone to using deployment-time policy as the actual trust boundary. If the gate is not enforced, a signed artifact can still move through the pipeline without meaningful proof that it came from an approved process.
Practical implication: Use admission policy to reject images that cannot prove approved build identity and provenance.
Breaches seen in the wild
- Massive Docker Hub Secrets Leak: 10,000+ Docker Hub container images expose hardcoded secrets and authentication keys.
- Secrets in Docker Hub images (RWTH Aachen study): A 2023 RWTH Aachen study found secrets in 8.5% of container images, and 275,269 internet hosts still using the leaked private keys.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
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.
Software supply chain security now behaves like release governance. The article shows that identity, signing, and approval logic must converge at deployment if organisations want measurable control over what ships. That moves the problem out of the build pipeline alone and into policy enforcement, where traceability becomes actionable rather than retrospective. Practitioners should treat release gates as governance infrastructure.
Keyless trust still needs enforced authority. Even when signing is transparent and attestations are machine-verifiable, the system still needs a policy decision that says which identities, repositories, branches, and workflows are acceptable. The named concept here is provenance enforcement: the point where evidence is converted into an allow or deny decision. That is what makes trusted software operationally real.
The strongest software provenance programmes tie artifact identity to workload identity. If the build system cannot prove who built the artifact and under what policy, downstream controls inherit ambiguity. That is why workload identity, cryptographic signing, and admission policy belong in the same architecture conversation. Teams that separate them will keep producing evidence without achieving enforceable trust.
Auditability without blocking power is insufficient. A posture built only on traceability can help after an incident, but it does not prevent release of untrusted software. The article’s deeper point is that the industry is moving from proof of history to proof of permission. Practitioners should design for deploy-time denial, not post-deploy reconstruction.
From our research library:
- Kubernetes production adoption has surged from 66% in CNCF's 2023 survey to 82% in 2025.
What this signals
Provenance enforcement closes the gap between evidence and control. Security programmes often stop at signing and attestation generation, but the operational risk does not change until the release system can deny software that fails policy. That shift matters for teams building cloud-native delivery because the trust decision must move as close as possible to deployment.
Software supply-chain governance now depends on machine-verifiable release boundaries. Manual exception handling cannot scale once software is treated as a governed supply chain. The more consistently the platform can verify identity, workflow claims, and artifact lineage, the less often teams need to reconstruct trust after the fact.
For practitioners
- 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.
- Use policy to prove trusted build conditions Define allow rules for specific repositories, branches, and workflow templates, then require every deployable image to match those conditions exactly.
- Treat traceability as incident evidence Preserve the build metadata needed to reconstruct who built the artifact, from which commit, and with which security checks, so response teams can validate exposure quickly.
Key takeaways
- Provenance only changes security posture when the deployment layer can enforce it as a hard control.
- The main risk is not the absence of build metadata but the absence of machine-verifiable approval at release time.
- Teams should align signing, attestations, and admission policy so that untrusted software fails closed before production.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while SLSA, NIST CSF 2.0, NIST SP 800-53 Rev 5 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | L3 — Builds Generate Verifiable Provenance | The article centres on trustworthy builds and verifiable provenance at SLSA Level 3. |
| Recommendation — Adopt SLSA Level 3 expectations for isolated builds, signed metadata, and non-falsifiable provenance. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Deployment policy is enforcing who and what may be authorised to release software. |
| Recommendation — Apply PR.AA-05 to ensure only approved identities and artifacts can pass release controls. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Release and build identities should hold only the access needed to produce trusted artifacts. |
| Recommendation — Restrict build and release identities to the minimum privileges needed for each approved workflow. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | The article ties trusted software release to workload identity and enforced authorization. |
| Recommendation — Use IAM controls to bind artifact trust decisions to verified builder identities and policy. | ||
| MITRE ATT&CK | TA0003;TA0006 — Persistence; Credential Access | Supply-chain compromise often depends on stealing build or signing credentials and keeping access persistent. |
| Recommendation — Map supply-chain abuse paths to persistence and credential access to prioritise detection coverage. | ||
Key terms
- Provenance-Aware Enforcement: Provenance-aware enforcement means applying security policy using knowledge of a data item’s origin and journey, not just its current location or label. It is useful when content is copied, renamed, or repackaged across collaboration tools, endpoints, and AI workflows.
- Production Batch Traceability: Production batch traceability is the ability to tie a field failure back to a specific manufacturing window, supplier lot, or plant. It gives operators the evidence needed to narrow impact, target fixes, and avoid broad interventions when only a subset of items is affected.
- Admission Controller: An admission controller is a Kubernetes control that validates or changes workload requests before the cluster admits them. It acts as a deployment-time policy layer, which makes it useful for blocking unsafe images, rejecting risky configuration, and enforcing runtime standards that build-time scans may miss.
- in-toto Layout: An in-toto layout defines the required steps in a software supply chain and the identities allowed to perform them. It turns build, test, sign, and release into a verifiable sequence, which helps teams prove that the declared assembly process actually happened.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on August 18, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org