Artifact identity is the missing control in software build integrity

At a glance

What this is: This is an analysis of how keyless signing, transparency logs, and policy enforcement turn software artifacts into verifiable identities.

Why it matters: It matters because IAM, platform, and security teams need consistent identity guarantees for machine-built software, not just human-authored code reviews.

By the numbers:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.

👉 Read Kusari’s analysis of keyless signing and artifact identity for build integrity

Context

Artifact identity is the question of who signed software, under what authority, and whether that claim can be independently verified. In cloud-native pipelines, that problem sits inside NHI governance because build systems, signing workflows, certificates, and attestations all behave as non-human identities.

Kusari’s article argues that software trust has moved beyond long-lived signing keys stored in CI systems. The practical shift is from static credential possession to short-lived, machine-verifiable trust, where identity, provenance, and auditability have to align before a build can be treated as trustworthy.

That matters for any programme trying to connect supply chain security with identity governance. Once signing becomes keyless and enforceable, teams must treat artifact identity as part of the broader NHI control plane, not as a separate DevOps concern.

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 do long-lived signing keys create supply chain risk?

A: Long-lived signing keys behave like standing privilege. They are reusable, hard to rotate consistently, and attractive targets in CI systems because compromising them can make malicious artifacts look legitimate. Short-lived workload identity reduces that exposure by removing persistent secrets from the signing path and limiting the value of any single compromise.

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: 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.

Technical breakdown

How keyless signing binds artifact identity to workload identity

Sigstore’s model replaces long-lived signing keys with OIDC-backed authentication and short-lived certificates. A CI system authenticates with an identity provider, Fulcio issues an ephemeral X.509 certificate, and that certificate binds the signing event to a specific repository, workflow, and subject. The important change is not just convenience. It removes persistent signing secrets from the pipeline and makes identity assertions machine-verifiable at the moment of signing. Practical implication: teams should treat build signing as an identity event with expiry, not as a reusable credential workflow.

Practical implication: move signing trust away from static keys and into short-lived workload identity.

Why transparency logs matter more than signatures alone

Rekor adds an append-only transparency ledger to signing, which means every signature can be independently observed and proven later. That distinction matters because a signature without durable logging only proves that a key existed at some point. A transparency log proves inclusion, timestamp, and historical traceability even if certificates or images are later deleted. In governance terms, Rekor converts signing from a point-in-time trust assertion into an auditable record. Practical implication: require immutable evidence of signing events, not just successful signing operations.

Practical implication: use transparency evidence as part of build audit and incident response.

How admission control turns provenance into enforceable policy

Kubernetes admission control is the enforcement layer that decides whether a workload can run after verifying provenance, attestations, or policy results. This is where software trust becomes operational instead of advisory. Cosign can attach signatures to images, SBOMs, and attestations, but admission control is what prevents unsigned or non-compliant artifacts from entering production. That makes policy the bridge between identity proof and runtime security. Practical implication: integrate provenance checks into admission paths so trust assertions become blocking controls, not documentation.

Practical implication: enforce provenance checks at deployment time, not only during build review.

Threat narrative

Attacker objective: The attacker’s objective is to distribute malicious software that inherits the organisation’s own trust signals and bypasses downstream verification.

1. Entry occurs when attackers compromise long-lived CI signing keys or misuse overly persistent artifact credentials in the build pipeline.
2. Escalation follows when the attacker uses those credentials to sign malicious artifacts that appear legitimate to downstream systems.
3. Impact lands when signed malicious packages, images, or attestations are trusted and deployed as if they were approved software.

Breaches seen in the wild

• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Long-lived signing keys are a standing privilege problem in disguise. Persistent CI signing secrets create the same governance weakness seen in other NHI estates: durable credentials, broad reuse, and weak rotation discipline. Keyless signing reduces the persistence problem by moving trust to short-lived workload identity, which aligns more closely with NHI lifecycle principles than with traditional secret storage. Practitioners should recognize this as a credentials-lifetime issue, not just a tooling choice.

Transparency without enforcement is only evidence, not control. Rekor-style logs improve auditability, but auditability alone does not stop untrusted artifacts from reaching production. The governance gap is the assumption that traceability equals protection. The practitioner conclusion is that provenance records must connect directly to policy enforcement in the deploy path.

Build integrity and identity governance are converging in the pipeline. Sigstore, in-toto, and Kubernetes admission control show that software trust now spans authentication, attestation, verification, and runtime policy. That convergence means platform security teams and IAM teams need a shared model for non-human trust, not separate control silos. The practitioner conclusion is to manage build identity as part of the broader NHI programme.

Provenance is the named concept that should anchor this category. Provenance is the proof that a software artifact came from a specific source, through a specific process, under a specific identity. In practice, provenance only matters when it can be verified at deployment time and tied to the actor that built the artifact. The practitioner conclusion is that provenance must be treated as an enforceable identity claim, not a document artifact.

From our research:

• 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.
• Use NHI Lifecycle Management Guide to connect signing identities, rotation, and offboarding into one lifecycle view.

What this signals

Provenance debt: many organisations can attest to software, but fewer can prove who had authority to produce it, which is why build identity needs to sit inside the same governance model as NHI lifecycle and secrets management. When a signing workflow still depends on persistent secrets, the programme has not eliminated trust debt, it has simply moved it into the pipeline.

The operational signal to watch is whether identity, attestation, and enforcement are converging in the same control path. If signing happens in one system, logging in another, and deployment approval in a third, the organisation will continue to accumulate gaps between trust assertion and trust enforcement. Teams should align this work with the Ultimate Guide to NHIs , Key Challenges and Risks and the NIST SP 800-53 Rev 5 Security and Privacy Controls model for access and integrity.

For platform and security leaders, the next step is to treat software supply chain identity as a lifecycle problem, not a one-time tooling decision. That means ownership, expiry, revocation, and verification need to be defined for build actors just as they are for service accounts and other non-human identities.

For practitioners

• 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.
• Treat transparency logs as audit evidence Store and review signing events in an immutable log so certificate expiry or artifact deletion does not erase the trust record.
• Map pipeline credentials into your NHI inventory Inventory CI tokens, signing certificates, and workload identities alongside other non-human identities so rotation, ownership, and offboarding are governed consistently.

Key takeaways

• Artifact signing only creates trust when the signer, the provenance, and the enforcement point are all linked.
• Long-lived CI signing keys create the same standing-privilege problem seen throughout non-human identity estates.
• The practical control shift is from reusable secrets to short-lived identity plus admission-time policy enforcement.

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.
• 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.
• 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.

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.

👉 Kusari’s full article covers Sigstore, Rekor, and Kubernetes enforcement in the software trust chain.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.