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.
At a glance
What this is: This analysis says artifact identity is the missing control in software build integrity, because signing only helps when provenance and enforcement make the claim verifiable.
Why it matters: IAM, supply chain, and platform teams need to treat software artifacts as identities with authority, or they will keep trusting signatures that do not prove how something was built.
Context
Artifact identity is the governance gap between a signed package and a trusted build. A signature can tell you who claimed authority, but it does not by itself establish how the artifact was produced, whether the claim is independently verifiable, or whether downstream policy actually enforced the result.
The article frames that gap through cloud-native supply chain tooling such as Sigstore, in-toto, Rekor, and Kubernetes admission control. For platform and security teams, the question is not just whether an artifact was signed, but whether identity, provenance, and enforcement are bound tightly enough to make build trust auditable.
That makes this a software supply chain and workload identity problem as much as a DevSecOps problem. The control objective is to stop treating artifact signing as the end state and instead govern the full trust chain from build identity to admission enforcement.
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. Signing alone is not enough because it only shows that an identity produced the artifact. Build integrity becomes real when provenance is checked at admission time and tied to the same workflow that created the artifact.
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. Without provenance and enforcement, a compromised or misused signing path can still produce malicious software that looks legitimate.
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. If an attacker or insider gets that key, they can sign malicious artifacts with valid credentials, which collapses the trust boundary between build system and release pipeline.
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.
Technical breakdown
Why artifact identity is more than a signature
Artifact identity answers who had authority to produce a build claim, not merely whether a cryptographic signature exists. In modern CI/CD, the identity of the workflow, repository, or workload matters because long-lived signing keys create durable trust in a secret rather than in a verified build event. Keyless signing shifts that trust to ephemeral credentials tied to workload identity, which is a stronger basis for auditability. The important distinction is that identity is only useful if it can be traced, verified, and enforced after signing. Without those links, a signature is evidence of possession, not of controlled production.
Practical implication: bind build authority to workload identity and do not treat raw signatures as proof of a trusted release.
How transparency logs make build claims auditable
A transparency log adds tamper-evident history to the signing process. Rekor-style logs do not prove the build was good, but they do make the signing event durable, searchable, and independently checkable. That matters because software trust chains fail when a signed artifact can later disappear, be replaced, or be disputed without evidence. An append-only record gives auditors and policy engines a way to verify inclusion and timing, which is what turns signing into a governance control rather than a developer convenience. In supply chain terms, the log is the ledger that lets an organisation prove that a claimed identity actually signed a specific artifact.
Practical implication: require transparency-log inclusion for release artifacts so signing events remain provable after deployment.
Why enforcement must happen at admission time
Signing and attestation only become security controls when the platform checks them before the artifact is allowed to run. Kubernetes admission control is the enforcement point that can reject images lacking the right provenance, signatures, or policy results. That shifts trust from post-build inspection to pre-execution control, which is where build integrity becomes operationally meaningful. In practice, this is the gap between knowing an artifact exists and deciding whether it is permitted into a cluster. Provenance frameworks such as in-toto strengthen the evidence, but admission policy is what converts evidence into gatekeeping.
Practical implication: enforce provenance and signature requirements at deployment admission, not after the workload is already running.
Threat narrative
Attacker objective: The attacker wants to produce and distribute malicious software that passes integrity checks because it appears to come from a legitimate build identity.
- Entry occurs when attackers or compromised pipelines obtain the ability to sign artifacts with a long-lived CI-stored key or otherwise inherit build authority.
- Credential access or abuse follows when that signing credential is reused outside a controlled build identity, allowing malicious output to look legitimate.
- Impact occurs when a signed but malicious artifact is trusted, admitted, and distributed through the software supply chain as if it were authentic.
Breaches seen in the wild
- Secrets in Docker Hub images (RWTH Aachen study): A 2023 RWTH Aachen study found secrets in 8.5% of container images, and 275,269 internet hosts still using the leaked private keys.
- Massive Docker Hub Secrets Leak: 10,000+ Docker Hub container images expose hardcoded secrets and authentication keys.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
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.
Long-lived signing keys create trust debt in software pipelines. The article highlights a familiar failure mode: keys stored in CI systems become hard to rotate, easy to mishandle, and attractive targets for abuse. That is not just a secret-management problem, it is a governance problem because the organisation has allowed signing authority to persist beyond the runtime moment that created it. The practitioner conclusion is to eliminate persistent signing authority where possible and treat ephemeral workload identity as the default.
Transparency-log provenance: signing must be paired with durable evidence of who signed what, and when. Rekor-style logs change the trust model from a private assertion to a verifiable record that can survive deletion, dispute, or later tampering. That matters because software supply chain controls need evidence, not memory. The practitioner conclusion is to require inclusion proof and traceability for release artifacts, not just a valid signature.
Admission control is where software trust becomes policy. Provenance data has limited value if the platform never checks it before allowing the workload to run. Kubernetes admission control turns signing and attestations into an enforcement point, which is where build integrity stops being a documentation exercise and becomes an operational gate. The practitioner conclusion is to move trust decisions into deployment policy rather than relying on after-the-fact review.
SLSA and in-toto matter because they connect identity, provenance, and enforcement into one control chain. The article points toward a mature software supply chain model in which identity proves origin, attestations prove build context, and policy proves admission. That combination is what makes build integrity auditable at scale. The practitioner conclusion is to evaluate supply chain controls as a chain, not as isolated tools.
From our research library:
- Kubernetes production adoption has surged from 66% in CNCF's 2023 survey to 82% in 2025.
- Read next: Ultimate Guide to NHIs — Standards
What this signals
Artifact identity creates a new governance boundary for software delivery. The build pipeline now needs to prove origin, not just produce output. That shifts security review from “is it signed?” to “can the organisation verify who signed it, under what authority, and with what traceable evidence?”, which is a stronger control posture for release integrity.
Keyless signing reduces secret exposure but does not eliminate trust decisions. Ephemeral credentials move risk away from stored signing keys, yet the trust problem persists unless provenance and platform enforcement are both present. Teams should expect build trust to become an admission-time control, not a post-build audit activity.
For practitioners
- 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.
- Enforce provenance at cluster admission Use admission policy to block images, attestations, or policy results that do not meet your build integrity rules before runtime.
- Treat attestations as part of the trust decision Validate provenance attestations, SBOMs, and signature metadata together instead of allowing a signature to stand in for build assurance.
Key takeaways
- Software build integrity fails when organisations treat signatures as proof of trust instead of proof of claimed authority.
- The control model changes when artifact identity, transparency logs, and admission policy are enforced together.
- Teams that still rely on long-lived CI signing keys are carrying avoidable trust debt across their software supply chain.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while SLSA and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | L3 — Provenance | The article centres on build provenance as the missing trust layer after signing. |
| Recommendation — Adopt SLSA provenance requirements so every release artifact can be traced to a verified build. | ||
| OWASP Non-Human Identity Top 10 | NHI-07 — Long-Lived Secrets | The article highlights long-lived signing keys stored in CI systems as a core weakness. |
| Recommendation — Eliminate persistent signing secrets and move artifact authority to short-lived credentials. | ||
| NIST CSF 2.0 | PR.DS-01 — Data-at-rest is protected | Signed artifacts, attestations, and logs are protection-sensitive records that must remain trustworthy. |
| Recommendation — Protect signing records and provenance artifacts so integrity evidence cannot be altered or removed. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Stolen build credentials can be reused to sign and distribute malicious artifacts through trusted paths. |
| Recommendation — Map compromised build credentials to credential access and restrict their reuse across release paths. | ||
Key terms
- Artifact Identity: Artifact identity is the verifiable claim about which workflow, repository, or build actor produced a software artifact. In practice, it connects signatures and provenance to a specific non-human identity so teams can decide whether the artifact should be trusted, deployed, or blocked.
- Transparency Log: An append-only log that records certificate issuance so third parties can verify what was created and when. In this model, transparency is not an extra layer after issuance. It is part of the trust system that makes certificate state observable and auditable.
- Provenance Attestation: A provenance attestation is evidence that software was produced through a known pipeline or workflow. It helps verify origin, but it does not guarantee that the workflow was free of compromise, poisoned caches, or attacker-controlled inputs.
- 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.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on August 18, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org