Verifiable software provenance is becoming a board-level control

At a glance

What this is: Kusari argues that software supply chain integrity has become a board-level control because teams now need cryptographic proof of artifact origin and tamper resistance, not just scan results.

Why it matters: This matters to IAM and NHI practitioners because build systems, signing identities, and admission controls now sit inside the trust boundary for production software and its machine identities.

Context

Software provenance is the ability to answer who built an artifact, from what source, with which system, and whether it was altered before deployment. That question matters because modern software is assembled from CI/CD systems, upstream dependencies, and promoted artifacts, so the control problem is chain-of-custody, not just code quality.

The identity angle is real even when the article is not about human IAM: build systems, signing keys, and admission controls act as non-human identities that establish trust in software moving through the delivery pipeline. When provenance is weak, organisations inherit an unverifiable trust relationship across the software supply chain.

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 do non-human identities matter in software supply chain security?

A: Non-human identities control publishing, automation, and distribution in modern software pipelines. If those identities are weakly protected, attackers can use maintainer tokens or CI credentials to inject malicious code, pivot into downstream repositories, and persist inside build systems. Supply chain security therefore depends on identity lifecycle and secret governance, not just code scanning.

Q: What breaks when package provenance is not enforced?

A: Without enforced provenance, package consumers cannot reliably tell whether a dependency came from the expected source or from a compromised build path. That leaves maintainers, CI pipelines, and registry policy as trust assumptions instead of controls. The result is blind acceptance of package origin, especially in environments that auto-update dependencies or pull JavaScript from CDNs.

Q: Should organisations prioritise SLSA over SBOMs for software trust?

A: They solve different problems, so the answer is usually yes for provenance and no for visibility alone. SBOMs tell you what is in the software, while SLSA-style controls help prove how it was built. Mature programmes need both, but provenance is the stronger control when the question is trust in the artifact itself.

Technical breakdown

Why software provenance is now an integrity control

Provenance is the evidence chain that ties a deployed artifact back to its source commit, build process, and producing system. In practical terms, it converts software from an opaque output into something that can be attested, verified, and audited. That matters because scanning tells you what a package contains, but provenance tells you whether the package is the one you intended to release. In regulated or safety-critical environments, those are not the same control. The trust model only works when integrity is proven at the point of admission, not reconstructed after an incident.

Practical implication: Treat provenance as a release gate, not a post-incident artifact.

How keyless signing and attestations change build trust

Keyless signing reduces reliance on long-lived signing secrets by binding an issuance event to an identity assertion at build time. In-toto adds supply chain attestations that describe the steps taken to produce an artifact, while Sigstore-style verification makes those claims machine-checkable. Together, these controls move trust away from static certificates stored on a laptop or in a secret manager and toward time-bound, verifiable claims about the build itself. That is a better fit for ephemeral cloud-native pipelines where the important question is not who had a key yesterday, but what identity produced this artifact now.

Practical implication: Anchor build trust in short-lived identity assertions and verifiable attestations.

Why admission control is the enforcement point that matters

Admission control is where provenance becomes operational, because it can block unverified images from entering the cluster or runtime environment. Without that enforcement point, provenance remains documentation that may be useful for audits but irrelevant during deployment. Kubernetes admission policy, combined with signature verification, gives organisations a policy layer that can distinguish approved artifacts from merely available ones. That is the difference between producing evidence and enforcing trust. In a cloud-native stack, the cluster should not accept what the pipeline cannot prove.

Practical implication: Require cluster admission policies that reject unsigned or unprovenanced workloads.

NHI Mgmt Group analysis

Software provenance is now a governance problem, not a niche DevSecOps enhancement. Once software becomes part of regulated operations, the board cares less about whether scanning exists and more about whether production artefacts can be traced, verified, and defended after the fact. The governance failure is not missing documentation, but unprovable chain of custody. Practitioners should treat provenance as a control objective that belongs alongside change assurance and release governance.

Build identities are a security boundary in their own right. CI/CD systems, signing services, and admission controllers act as non-human identities that confer trust on software artifacts. If those identities are not authenticated, scoped, and verifiable, then the entire provenance story collapses into trust by convention. NHI governance increasingly extends beyond service accounts into the software factory itself, so teams need to inventory and govern the identities that create release trust.

Verifiable provenance makes software supply chain risk measurable in a way scanning never could. Static scanning finds known weaknesses, but it does not tell you whether the artifact in production is the artifact that was reviewed and approved. Provenance, signing, and policy enforcement create a measurable trust path from source to runtime. For practitioners, that shifts the programme question from detection alone to whether release integrity can be demonstrated under audit, incident response, and regulatory review.

SLSA gives the market a common language, but the operational value depends on enforcement. The article reflects a broader shift toward incremental assurance levels rather than all-or-nothing security claims. That matters because many organisations already have pieces of the stack, but they remain disconnected across build, sign, verify, and admit. The actionable conclusion is to align governance, tooling, and deployment policy so provenance is not merely generated but actually required.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Breaches involving third parties rose to 48% of all breaches, a 60% increase on the previous year, according to Verizon's 2026 Data Breach Investigations Report.
• Read next: AI Supply Chain Security and AI-BOM Guide

What this signals

Verifiable provenance is the missing trust layer in modern release pipelines. Security teams have spent years improving detection around software composition, but the more important question is whether the artifact entering production is provably the one that left the build. That shift makes provenance, signing, and admission policy part of core governance rather than a specialist add-on. The practical implication is that release controls now need to be auditable at runtime, not just documented in process.

Software provenance should be managed like non-human identity lifecycle. The build system, signing service, and cluster admission controller each act as identities that either create or validate trust. If those identities are not inventoried, scoped, and monitored, the organisation cannot prove who authorised software movement through the pipeline. That is why provenance and NHI governance increasingly converge in the same operating model.

92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs." The same third-party exposure problem that affects machine identities also shows up in build tooling, signing services, and dependency chains. When trust depends on upstream systems outside direct control, provenance becomes the only practical way to separate approved software from merely delivered software.

For practitioners

• Define provenance as a release requirement Make cryptographic provenance a required condition for production promotion, not an optional audit artifact. Tie the control to change management so every deployable artifact can be traced to source, builder, and build process.
• Verify build identity and artifact attestations Use short-lived build identities and signed attestations so the producing system, source commit, and build steps are machine-verifiable before deployment.
• Enforce cluster admission policy Block unsigned or unprovenanced containers at admission time so the runtime cannot accept artifacts that the pipeline cannot prove.
• Map provenance controls to supply chain standards Align your provenance programme with SLSA levels and related supply chain controls so assurance claims are testable rather than aspirational.

Key takeaways

• Software provenance is becoming a board-level control because production software now needs evidence of origin, not just evidence of testing.
• Scan results and compliance checklists do not prove that a deployed artifact is the one that was built and approved.
• The strongest programmes combine attestations, verified signing, and admission control so trust is enforced at release time.

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.
• Supply chain attestation: Supply chain attestation is cryptographic proof that a running artifact matches a known, trusted build. For MCP servers, it gives security and procurement teams evidence that the code they approved is the code operating inside their environment.
• 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.
• Keyless Signing: Keyless signing is a signing model that uses short-lived identity assertions instead of storing long-lived private keys in CI or build systems. It reduces persistent secret exposure and shifts trust to ephemeral certificates bound to the build actor at signing time.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners build the identity controls that underpin trusted software delivery and broader security programmes.