Topic starter
18/08/2026 2:21 pm
TL;DR: Before organisations can enforce build integrity, they need artifact identity that can be signed, traced, and independently verified, according to Kusari’s analysis of Sigstore, in-toto, Rekor, and Kubernetes admission control. The governance break is assuming a signature alone proves trust, when provenance and enforcement are what make software supply chains auditable.
Editorial analysis by NHI Mgmt Group, based on content published by Kusari: “Identity, Signing, and Transparency: The Foundation of Verifiable Builds”.
Key questions
Q: How should security teams enforce build integrity for software artifacts?
A: Security teams should require three things: a verifiable signer identity, durable provenance evidence, and a deployment control that can reject untrusted artifacts.
Q: Why is a signed artifact not enough to prove software trust?
A: A signature proves that some identity asserted authority, but it does not prove the artifact was built correctly or by the intended workflow.
Q: What breaks when build signing uses long-lived CI keys?
A: Long-lived keys create durable signing authority that is hard to rotate and easy to mishandle.
Practitioner guidance
- Define artifact identity as a release control Require every signed build artifact to be traceable to a specific workflow, repository, and issuing authority before it can be trusted.
- Replace long-lived signing keys with ephemeral workload identity Move signing authority out of persistent CI secrets and into short-lived, verifiable workload credentials tied to build execution.
- Require transparency-log inclusion for released artifacts Reject release artifacts that do not have durable inclusion evidence in an append-only transparency log and retain proof for audit.
Bottom line: Software build integrity fails when organisations treat signatures as proof of trust instead of proof of claimed authority.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
18/08/2026 3:13 pm
Artifact identity is the missing control because signatures do not equal trust. A signed artifact only proves that some key or identity asserted authority at a point in time. Build integrity depends on whether that authority is bound to a real workload, whether the claim can be independently verified, and whether policy enforces the result before execution. The practitioner conclusion is that artifact identity has to be governed as a first-class control, not treated as a convenience layer on top of CI.
A few things that frame the scale:
- Kubernetes production adoption has surged from 66% in CNCF's 2023 survey to 82% in 2025.
A question worth separating out:
Q: What is the difference between provenance and legitimacy in software supply chains?
A: Provenance answers where an artifact came from and which workflow produced it. Legitimacy answers whether that workflow, branch, and release decision were trustworthy at the time. A package can have strong provenance and still be malicious if the publishing identity was compromised or misused.
👉 Read our full editorial: Artifact identity is the missing control in software build integrity