Topic starter
18/08/2026 2:21 pm
TL;DR: Software build integrity breaks when signatures are treated as proof of trust instead of proof of claimed authority, according to Kusari. Artifact identity only becomes verifiable when provenance and admission policy are enforced together.
Editorial analysis by NHI Mgmt Group, based on content published by Kusari: “Identity, Signing, and Transparency: The Foundation of Verifiable Builds”.
Key questions
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.
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.
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.
Glossary terms: Artifact Identity, Transparency Log, Provenance Attestation, Admission Controller
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 days ago by NHI Mgmt Group
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