Provenance enforcement is the missing control in software supply chains

At a glance

What this is: This is a supply chain security analysis showing that provenance only reduces risk when deployment policy enforces it, rather than treating attestations as documentation.

Why it matters: It matters because platform, IAM, and security teams need to bind workload identity, build evidence, and admission control into one enforceable trust model.

👉 Read Kusari's analysis of provenance enforcement in software supply chains

Context

Software supply chain security is the practice of proving where software came from, how it was built, and whether it should be allowed to deploy. The article's central argument is that provenance generation alone does not change risk posture unless policy enforcement makes that provenance mandatory at the point of release, which is the key control gap in many cloud-native programmes.

That matters for identity and access governance because the build system, the signer, the admission controller, and the policy engine all become part of the trust boundary. In practice, this is about workload identity, cryptographic signing, and deployment-time verification, not just code scanning or developer process. Teams that already operate on the NHI Lifecycle Management Guide will recognise the same problem: evidence is useful only when it is enforced.

Key questions

Q: How should security teams enforce software provenance in Kubernetes

A: Security teams should enforce software provenance at admission, not after deployment. The cluster should reject artifacts that lack approved signatures, trusted builder claims, or required provenance attestations. That turns provenance from evidence into a control and ensures unverified workloads never reach runtime.

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 attestations are treated as documentation

A: The trust model breaks at the point of release. Attestations may describe the build, but they do not prevent an untrusted image from being deployed unless policy checks them automatically. In practice, that leaves audit evidence without operational protection.

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.

Technical breakdown

Why provenance must become a deployment-time control

Provenance is a machine-readable record of how an artifact was produced. In SLSA terms, it can include the source repository, commit SHA, builder identity, workflow template, and output digest, which creates a verifiable contract for deployment decisions. The control fails if provenance is treated as a post-build audit artifact rather than a live trust input. Once that happens, attackers do not need to break cryptography; they only need a path around policy enforcement.

Practical implication: treat provenance as an admission requirement, not a reporting layer.

How in-toto turns the software pipeline into a verifiable chain

in-toto models the full assembly line of software production by defining required steps, authorised identities for each step, and expected inputs and outputs. Each step produces signed link metadata, which lets verifiers check whether the declared route was actually followed. This is different from a single signature on the final artifact, because it preserves the path of custody across build, test, scan, sign, and release. The result is traceability across the whole release chain, not just the final image.

Practical implication: map each release step to an accountable identity and verify the step sequence before promotion.

Why Kubernetes admission control is the enforcement point that matters

Admission control is where policy can block an image before it becomes a running workload. When integrated with a policy engine such as Kyverno, it can reject deployments that lack Cosign signatures, Rekor inclusion proofs, trusted builder claims, or approved provenance attributes. This makes enforcement deterministic rather than manual. In identity terms, the cluster is no longer trusting the artifact because it exists; it is trusting the artifact only if it satisfies an explicit set of claims at the moment of admission.

Practical implication: enforce provenance at the cluster boundary so unverified workloads never reach runtime.

NHI Mgmt Group analysis

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.

Software supply chain trust is now a workload identity problem as much as a DevSecOps problem. The article ties trust to builder identity, signing identity, and admission-time claims, which is exactly where identity governance enters the pipeline. That aligns with NHI thinking because build systems, signers, and controllers are non-human actors whose permissions must be bound to explicit policy. The practitioner conclusion is that identity evidence must follow the artifact from build to deploy.

Deployment policy is becoming the new trust boundary for cloud-native software. SLSA Level 3, in-toto layouts, and admission controllers all point to the same operating model: verify at the point where risk becomes real. This mirrors the broader shift in identity security from static trust to continuous verification. The practitioner conclusion is that platform teams should treat release gates as the control plane for software trust.

Trusted software now depends on measurable, machine-verifiable claims rather than assumptions about the build process. The article's named concept is deployment-time provenance enforcement: the point where identity, signing, and policy intersect to decide whether code may run. That concept matters because auditability alone does not prevent drift, whereas enforceable claims do. The practitioner conclusion is to define trust as a policy outcome, not a build artifact.

From our research:

• 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.
• For adjacent lifecycle guidance, review the NHI Lifecycle Management Guide for the control points that make verification enforceable.

What this signals

Provenance enforcement is becoming the practical boundary between audit readiness and real risk reduction. Teams that can produce attestations but cannot block nonconforming artifacts will continue to report maturity without materially changing exposure. That is why deployment policy, not provenance generation, is now the operational control that matters.

The governance model also extends beyond the build itself. Once workload identity, signing identity, and admission policy are linked, security teams can define a measurable trust chain from source to runtime, which is the kind of structure regulators and auditors increasingly expect.

As supply chain control matures, the deciding question is no longer whether software was scanned. The question is whether the system can prove, automatically and consistently, that only approved artifacts were allowed to run.

For practitioners

• Make provenance mandatory at admission Require Kubernetes admission control to reject workloads that lack approved provenance attestations, valid signatures, or trusted builder claims. Keep the default outcome as deny unless policy assertions are satisfied.
• 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.
• Separate provenance generation from provenance enforcement Track attestation creation in CI, but only count risk reduction when admission policy enforces those claims at the cluster boundary.

Key takeaways

• Provenance only reduces risk when deployment policy enforces it, because evidence without blocking power does not change the release path.
• Cloud-native supply chain security now depends on workload identity, signed attestations, and admission control working as one trust chain.
• Practitioners should move from generating trustworthy build records to denying any artifact that cannot satisfy those records at release time.

Key terms

• Provenance Attestation: A provenance attestation is evidence that software was produced through a known pipeline or workflow. It helps verify origin, but it does not guarantee that the workflow was free of compromise, poisoned caches, or attacker-controlled inputs.
• 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.

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

👉 Kusari's full post covers the build-to-deploy trust chain, admission policy, and the controls behind machine-verifiable software.

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.