Verifiable software provenance is becoming a board-level control

At a glance

What this is: This is Kusari’s analysis of why software supply chain integrity now depends on cryptographically verifiable provenance, signed builds, and enforceable admission controls.

Why it matters: It matters because IAM, PAM, and broader security teams increasingly need to govern machine identity, build trust, and release integrity, not just application scanning and compliance checklists.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Kusari's analysis of verifiable software provenance and SLSA

Context

Software supply chain integrity is a governance problem as much as a technical one. If teams cannot prove where an artifact came from, which build produced it, and whether it was altered, they are relying on trust by convention rather than trust by control. In regulated and safety-critical environments, that is not enough for production release decisions.

The article also intersects with identity because software provenance depends on the identity of build systems, signing workflows, and the controls that authorize software to move into production. That makes this an IAM-adjacent discipline in practice, especially where platform teams, release engineering, and security operations share responsibility for enforcement.

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 are SBOMs not enough to secure the software supply chain?

A: SBOMs improve visibility into what is inside a package, but they do not prove who built it or whether the build was tampered with. That is why provenance, signing, and policy enforcement matter. Without those controls, teams can document composition while still shipping untrusted software into production.

Q: What breaks when software release trust is not enforced?

A: When trust is not enforced, teams can no longer distinguish legitimate builds from altered or replayed artifacts at deployment time. That creates a gap between what the pipeline says happened and what can be proven. The result is slower incident response, weaker auditability, and a much larger recovery burden after compromise.

Q: How do admission controls help with supply chain risk accountability?

A: Admission controls create a hard decision point before software runs, so policy can deny artifacts that fail signature or provenance checks. That makes accountability clearer because release authority is tied to explicit controls rather than informal pipeline trust. It also gives security teams a measurable enforcement layer for regulated environments.

Technical breakdown

What verifiable software provenance actually changes

Verifiable provenance turns software delivery into an evidence-based process. Instead of assuming a container image or binary is trustworthy because it came from a familiar pipeline, teams require cryptographic proof of who built it, from what source, and under which conditions. Sigstore and in-toto provide the signing and attestation primitives, while admission control enforces policy at deployment time. The result is not just better records. It is a way to make artifact integrity machine-checkable before production use.

Practical implication: require signed provenance and policy enforcement before workloads reach production clusters.

Why scanning and SBOMs are not enough on their own

Scanning finds known weaknesses in code or dependencies, and SBOMs improve visibility into composition, but neither proves how an artifact was produced or whether the build chain was tampered with. That is the key distinction. A software bill of materials can tell you what is inside a package, but not whether the package was created by a trusted process. SLSA pushes the conversation toward build integrity, reproducibility, and verified provenance, which are stronger controls than post hoc inspection.

Practical implication: treat scanning and SBOMs as supporting controls, not substitutes for provenance verification.

How Kubernetes admission control becomes the enforcement layer

Kubernetes admission control sits at the point where policy can block an untrusted artifact before deployment. That makes it a practical control for supply chain integrity because it can verify attestations, require signatures, and reject images that do not meet policy. In effect, it moves trust decisions from developer intention to runtime enforcement. This is especially important in cloud-native environments where dozens of tools can touch the build and release path, each creating a chance for drift or compromise.

Practical implication: bind admission policy to signature and attestation checks rather than allowing unsigned release artifacts.

Threat narrative

Attacker objective: The attacker’s objective is to get malicious or altered software accepted as trusted production output so it can persist inside critical systems.

1. Entry occurs through compromise or tampering in the software build and dependency chain, where an attacker targets the path that produces release artifacts rather than the application runtime itself.
2. Escalation happens when unverified artifacts are promoted across environments without cryptographic proof of origin or build integrity, allowing manipulated software to inherit trust.
3. Impact follows when compromised or untraceable software reaches production systems, making root cause analysis, containment, and recall-style remediation slow and uncertain.

NHI Mgmt Group analysis

Software provenance is becoming an identity problem, not just a build problem. Once release artifacts can be cryptographically tied to a known source, build system, and policy decision, supply chain trust becomes a matter of identity governance for machines. That changes the control question from “Did the pipeline run?” to “Can this artifact prove who created it and under what authority?” Practitioners should treat signing and attestation as governed identities in the delivery path.

SBOM visibility without enforceable provenance creates a documentation gap. Teams can know what components are present and still be unable to prove the artifact was produced correctly. That gap matters because regulators, customers, and incident responders need evidence, not inventory alone. SLSA is useful precisely because it moves software trust from descriptive records to verifiable controls, which is the right direction for regulated production environments.

Keyless trust is only useful if the enforcement point is real. A signed artifact that can bypass release policy is still an operational risk. Admission control, policy engines, and cluster-side verification are what make trust enforceable rather than ceremonial. In practice, this means security teams should focus on the control point where trust is accepted or denied, not just on generating more attestations.

Software supply chain governance now depends on machine identity discipline. Build systems, signing services, and release workflows function like non-human identities with authority to promote code into production. If those identities are not scoped, attested, and monitored, the organisation cannot reliably distinguish legitimate software from tampered output. Practitioners should align supply chain trust with NHI governance principles.

What this signals

Provenance enforcement is converging with identity governance. As software delivery becomes more automated, the authority to build, sign, and promote artifacts behaves like a non-human identity problem. Teams that already manage service accounts, tokens, and workload permissions should extend those governance patterns to release systems and signing workflows, with the OWASP Non-Human Identity Top 10 as a useful reference point.

Trust claims will increasingly need machine-verifiable evidence. In regulated environments, documentation alone will not satisfy audit or incident-response needs once supply chain tampering is in scope. Practitioners should expect stronger alignment with the NIST Cybersecurity Framework 2.0 and provenance-oriented controls that make software acceptance decisions defensible.

The operational signal to watch is whether release policy can actually stop an untrusted artifact before it reaches production. If unsigned builds still pass through because enforcement sits outside the deployment path, the organisation has visibility but not control.

For practitioners

• Inventory build identities and signing authorities Map every system that can produce, sign, or promote artifacts, then assign ownership, scope, and review cadence so release authority is explicit rather than implicit.
• Require cryptographic provenance for production releases Block promotion of images and packages unless they carry verifiable provenance that ties the artifact to source, build environment, and signing authority.
• Enforce admission control at deployment time Use cluster admission policy to reject unsigned or untrusted artifacts before they can run, rather than relying on downstream detection after deployment.
• Treat SBOMs as supporting evidence, not final proof Use SBOMs to improve component visibility, but pair them with attestation and verification so teams can prove how software was produced.

Key takeaways

• Software supply chain integrity now depends on proof, not assumptions, because visibility without enforcement does not prevent tampered artifacts from reaching production.
• Provenance, signing, and admission control create the evidence chain that scanning and SBOMs cannot provide on their own.
• Machine identity governance is becoming part of release governance, which means build systems and signing workflows need explicit scope and enforcement.

Key terms

• Software provenance: Software provenance is the evidence that shows where an artifact came from, who created it, and whether it was altered before use. For security teams, it means signed releases, controlled build paths, and verification steps that reduce the chance of trusted software carrying hidden malicious changes.
• SLSA: SLSA is a framework for measuring the integrity of software supply chains. It defines progressively stronger controls for build provenance, isolation, and verification so organisations can raise assurance in a structured way rather than treating trust as a binary claim.
• 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: In-toto is a framework for describing and verifying the steps in a software supply chain. It records which parties handled the artifact and what actions they performed, creating a cryptographically verifiable chain of custody for releases.

What's in the full article

Kusari's full article 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 path
• Specific guidance on moving from artifact scanning to cryptographically verifiable production integrity
• The practical trust model for keyless signing and provenance verification in modern build pipelines
• How the SLSA framework maps to production release assurance and auditability

👉 The full Kusari post expands on cloud-native signing, admission control, and provenance verification in practice.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management for practitioners building stronger control over machine identities. It helps security and platform teams connect identity governance to the operational systems that authorise production change.