Why do long-lived signing keys create supply chain risk?

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.

Why This Matters for Security Teams

Long-lived signing keys turn software release systems into high-value targets because one compromise can vouch for many downstream artifacts, not just a single build. That makes the key itself part of the supply chain, and it creates a trust problem that extends into package registries, CI runners, and release automation. NHI Management Group has repeatedly tracked how attacker access to trusted identities is what converts a breach into a software distribution event, as seen in cases like the Reviewdog GitHub Action supply chain attack.

The operational issue is not only theft. It is persistence. A static signing key remains valid until someone finds it, rotates it, and verifies every dependent system still works. That delay is exactly what makes supply chain exposure durable. This also aligns with the OWASP Non-Human Identity Top 10, which treats unmanaged machine credentials as a core attack surface rather than a minor implementation detail. In practice, many security teams discover signing key abuse only after a trusted artifact has already been distributed.

How It Works in Practice

The safer model is to remove the permanent secret from the signing path and replace it with short-lived workload identity plus just-in-time authorization. Instead of storing a reusable key in a repo, runner, or HSM-backed automation account, the build job proves what it is at runtime, gets scoped permission for a single signing action, and then loses that access when the task ends. That reduces the blast radius from “any artifact signed by this key” to “this build at this moment.”

This approach usually combines several controls:

• Workload identity for the CI job or signer, rather than a shared static credential.
• Ephemeral tokens with short TTLs so stolen credentials expire quickly.
• Policy checks at request time so only approved branches, environments, or build states can sign.
• Revocation and audit events tied to each signing action, not just to the repository.

That model is consistent with current guidance from the NIST Cybersecurity Framework 2.0, which emphasizes governance, access control, and continuous monitoring, and with NHIMG’s analysis of how supply chain compromise cascades through trusted identities in the 52 NHI Breaches Analysis. In environments with high release frequency, the case for short-lived signing credentials is stronger because rotation discipline alone cannot keep pace with automated deployment velocity.

NHIMG research also shows why this matters: in the State of Secrets Sprawl 2026, 64% of valid secrets leaked in 2022 were still valid and exploitable today, which demonstrates that detection without automated revocation is not enough. These controls tend to break down when signing is embedded in legacy release tooling that cannot issue per-job identity or enforce runtime policy.

Common Variations and Edge Cases

Tighter signing control often increases pipeline complexity, so organisations have to balance assurance against release friction. That tradeoff is most visible in hybrid environments where some build systems support ephemeral identity and others still depend on shared certificates, manual approvals, or air-gapped signing hosts.

There is no universal standard for this yet, but current guidance suggests a layered approach: isolate the root signing capability, use short-lived delegation for routine builds, and reserve longer-lived trust only for tightly controlled recovery paths. For some teams, that means hardware-backed keys with strict operational separation; for others, it means moving to remote signing services that accept workload identity and issue per-request authorization. The key point is that the signer should not be a reusable secret sitting inside the same environment that produces the artifact.

Edge cases include offline signing, regulated software distribution, and cross-organisational open source releases. In those settings, a permanently stored key may still exist, but the surrounding controls must be much stronger: explicit approval gates, constrained signing hosts, tamper-evident logging, and immediate revocation procedures. The NIST SP 800-53 Rev. 5 Security and Privacy Controls remains relevant for documenting those compensating safeguards, while the Shai Hulud npm malware campaign shows how quickly abused build trust can propagate once secrets are reachable in developer tooling.

Related resources from NHI Mgmt Group

• Why do service accounts and API keys create so much supply chain risk?
• Why do short-lived OIDC tokens still create meaningful supply chain risk?
• Why do long-lived API keys create more risk for AI agents?
• Why do long-lived service account keys create more risk than they solve?