From Provenance to Enforcement: SLSA, in-toto, and Kubernetes Admission Control
If provenance is not evaluated, it is merely metadata. Enforcement is what transforms integrity into control.
Michael Lieberman
Gaurav Saxena
April 27, 2026
.png)
Generating provenance is a start. Enforcing provenance is what changes risk posture. Security and platform leaders must ensure that deployment decisions are made by policy — not assumption.
In their three-part blog series, Michael Lieberman and Gaurav Saxena highlight their views in shaping the future of software and walk through modern cloud-native tooling including how Sigstore, in-toto, and Kubernetes admission control makes software trust keyless, auditable, machine-verifiable, and enforceable.
Gaurav, a friend of Kusari, is an engineering leader in the field of platform and cloud engineering with over 20 years of experience in the software industry. His technical expertise includes Stream-based architectures, Kubernetes, Service Mesh, Software Supply Chain Security, and Observability.
Signing proves identity. Provenance proves process. SLSA defines what trustworthy builds look like and how to verify them.
The technologies we’re highlighting in this blog series are not experimental research projects. Sigstore and in-toto are hosted under the OpenSSF and Cloud Native Computing Foundation (CNCF), respectively. And, in-toto has reached graduated project status — signaling production maturity and broad industry adoption.
Their growth reflects a larger trend within the cloud-native community: supply chain security is now treated as foundational infrastructure, not an add-on feature.
SLSA adoption also is growing, and independent analysis and community discussions have highlighted that generating provenance alone is not enough. Many organizations struggle with operationalizing verification and aligning teams around enforceable policy.
This is precisely why enforcement mechanisms — such as Kubernetes admission control combined with policy engines like Kyverno — are critical. Without verification gates, provenance risks becoming documentation rather than protection.
Targeting SLSA Level 3
At higher maturity, organizations aim for SLSA Level 3 for builds. This requires:
- Builds running on hosted, controlled platforms
- Strong isolation between build jobs
- Non-falsifiable provenance
- Cryptographic signing of build metadata
Each build emits a provenance attestation that includes:
- Source repository and commit SHA
- Builder identity
- Build parameters
- Output artifact digests
This provenance becomes a machine-checkable contract. It doesn’t just describe what happened. It defines what must be true for deployment to proceed.
For example:
- The source must be a specific repository.
- The branch must be main.
- The workflow file must match an approved template.
- The builder must belong to an approved pool.
If any of these conditions fail, the artifact is not trusted and should not be deployed.
The Operational Challenge
Community discussions and independent analysis have highlighted a recurring challenge: generating provenance is easier than operationalizing verification.
Many organizations can produce attestations. Fewer enforce them.
Without enforcement, provenance risks becoming documentation rather than protection.
For security leaders, this is the difference between maturity on paper and measurable risk reduction.
in-toto: Modeling the Entire Assembly Line
While SLSA focuses on build guarantees, in-toto models the entire software supply chain.
An in-toto layout defines:
- The required steps (build, test, scan, sign, release)
- Which identities are authorized to perform each step
- The expected inputs and outputs
- An expiration and owner signature
Each step generates signed link metadata capturing inputs, outputs and hashes.
Verification ensures:
- Every required step occurred
- Each step was performed by an authorized identity
- Inputs and outputs match expectations
This mirrors manufacturing route cards and trace records. In manufacturing terms, the layout is the route card. The link metadata is the trace record for each station in the assembly line.
in-toto can also carry attestations such as:
- SBOM generation
- Static analysis
- License compliance
- Security scan results
This transforms attestations into structured, verifiable record of the entire digital assembly line.
Enforcing at the Kubernetes Admission Gate
The final control point is deployment.
Using a Kubernetes admission controller integrated with a policy engine such as Kyverno, organizations can enforce:
- Cosign signatures
- Rekor inclusion proofs
- SLSA provenance attestations
- in-toto layout compliance
Policies can require elements such as:
- Signer identity matches expected OIDC claims
- Provenance indicates a trusted build platform
- Source repository and branch match approved patterns
- Workflow file hash matches the organization’s golden template
If provenance is missing (or claims an untrusted builder), the admission controller rejects the deployment. No exception review. No manual override by default.
Trust is established with enforced policy, not human review.
Software Batch Traceability
The result is software batch traceability.
For any running container image digest, teams can recover:
- Who built it
- From which commit
- Using which workflow
- With which SBOM
- With which security scan results
This is similar to how manufacturers retrieve batch records and inspection documents for a physical component.
Incident response becomes evidence retrieval — not historical reconstruction.
From Awareness to Enforcement
The open source community — through OpenSSF, SLSA, Sigstore, and in-toto — has defined shared expectations for verifiable software production.
The ecosystem direction is clear:
- Identity must be cryptographically bound to artifacts.
- Provenance must be machine-verifiable.
- Transparency must be immutable.
- Enforcement must happen at deployment.
For security and platform leaders, you’re making hard tradeoffs in the face of regulatory scrutiny; balancing delivery velocity against risk, developer experience against governance, innovation against audit findings. Fortunately, the path forward doesn’t require inventing something new.
In this series, we’ve looked at three shifts:
- First, recognizing that software is a supply chain and needs the same traceability and discipline as physical manufacturing.
- Second, establishing strong workload identity and transparent signing, so artifacts are bound to who built them.
- Third, moving from generating provenance to actually enforcing it at deployment with policies and admission control.
The common thread is that trust is moving ever closer to being measurable and verifiable; it can no longer be assumed because the code was scanned. The regulations like the EU Cyber Resilience Act are going to require all of us to prove how our software is built.
The encouraging part is the industry has converged around clear building blocks to build systems with trust in mind from the start:
- Treat software like a supply chain, not just a codebase.
- Cryptographically bind artifacts to verified workload identity.
- Generate provenance that describes exactly how builds were produced.
- Enforce that provenance at deployment through policy — automatically and consistently.
Organizations that embrace this shift will reduce risk, operate with more clarity and accountability, and reduce friction based on a shared understanding of what “trusted software” actually means.
Like what you read? Share it with others.
.webp)
.webp)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.jpg)
Previous
No older posts
Next
No newer posts
Want to learn more about Kusari?