Notifications
Clear all
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.
NHIMG editorial — based on content published by Kusari: artifact identity, keyless signing, and software build trust
By the numbers:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
Questions worth separating out
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 do long-lived signing keys create supply chain risk?
A: Long-lived signing keys behave like standing privilege.
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.
Practitioner guidance
- Replace persistent signing keys with short-lived workload identity Use OIDC-backed signing flows so CI systems authenticate at build time and receive ephemeral certificates instead of storing reusable private keys.
- Bind artifact trust to verifiable provenance Require signatures, attestations, and SBOMs to be linked to the same repository, workflow, and build subject before an artifact is considered trusted.
- Enforce policy at Kubernetes admission Block deployment of unsigned or non-compliant images by making provenance checks part of the admission decision, not a post-build review.
What's in the full article
Kusari's full analysis covers the operational detail this post intentionally leaves for the source:
- Step-by-step Sigstore flow details for OIDC, Fulcio, Rekor, and Cosign integration in CI/CD.
- Practical guidance on provenance attestations, SBOM signing, and verification policies for release gates.
- Kubernetes policy examples that show how admission control can block unsigned or non-compliant artifacts.
- Implementation context for platform teams that need to move from artifact trust theory to enforced controls.
👉 Read Kusari’s analysis of keyless signing and artifact identity for build integrity →
Software artifact identity and build trust: what teams need to enforce?
Explore further
18/08/2026 3:13 pm
Artifact identity is now a governance primitive, not a build convenience. Software supply chain security fails when organisations treat signing as a packaging step instead of an identity control. The article’s model shows that signed artifacts, attestations, and provenance claims all need binding authority, traceability, and revocation logic. The practitioner conclusion is simple: if you cannot govern the artifact identity, you cannot govern the software trust chain.
A few things that frame the scale:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, which shows how slowly non-human credentials are actually retired.
A question worth separating out:
Q: How do Kubernetes admission controls help software supply chain security?
A: Admission controls turn artifact trust into a runtime decision. They can verify signatures, attestations, and policy results before a workload starts, which stops unsigned or unapproved artifacts from running. That makes the deployment boundary part of the security model rather than a passive handoff from build to runtime.
👉 Read our full editorial: Artifact identity is the missing control in software build integrity
