What breaks when code signing keys are shared across build systems?

Why This Matters for Security Teams

Shared code signing keys turn build systems into a single trust boundary, which is exactly where release integrity is most fragile. When the same key is available across pipelines, test jobs, and release jobs, any compromise in the broader build environment can produce a signed artefact that downstream tools treat as legitimate. That breaks provenance, weakens revocation, and makes incident response harder because the signature no longer proves which system authorised the release.

This is a classic non-human identity problem, not just a software supply chain problem. NHIMG research shows that 96% of organisations store secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools, and 30.9% store long-term credentials directly in code in some form of workflow. That context matters because signing keys often sit in the same brittle operational layer as other build secrets, where lateral movement is common and controls are inconsistent. The Ultimate Guide to NHIs captures how quickly that exposure becomes systemic.

From a governance perspective, the issue also undermines traceability. If every system can sign, then no system is uniquely accountable, which makes attestation and revocation less meaningful. In practice, many security teams encounter the real impact only after a compromised pipeline has already signed and distributed a trusted-looking release.

How It Works in Practice

The safer pattern is to treat signing as a tightly scoped release capability, not a shared build utility. A build system should prove its workload identity, request signing at runtime, and receive only the minimum access needed for that specific release task. That is the direction current guidance suggests, even though implementation details still vary across platforms. The important shift is from static key possession to runtime authorisation.

In practice, this usually means combining workload identity, short-lived credentials, and policy checks at the moment of signing. For example, a release job can authenticate with a cryptographic workload identity, be evaluated against policy, and then be issued an ephemeral signing grant only if the artefact, branch, approver state, and environment all match. This is much closer to Zero Trust than to traditional shared-secret handling, and it aligns with the broader expectations in the NIST Cybersecurity Framework 2.0.

• Use separate signing identities for each build domain, environment, or release line.
• Prefer short-lived tokens or signing certificates over long-lived static keys.
• Bind signing approval to policy-as-code checks, not manual trust in the pipeline runner.
• Log which workload requested the signature, not just which secret store issued it.
• Revoke signing authority when a build system is rebuilt, repurposed, or lost trust.

That model is reinforced by NHIMG guidance on NHI lifecycle controls in the Ultimate Guide to NHIs, especially where secrets exposure and rotation failures are already common. These controls tend to break down when legacy CI/CD systems must keep a shared signing path for multiple products because the tooling cannot yet express per-release identity and policy constraints.

Common Variations and Edge Cases

Tighter signing controls often increase operational overhead, requiring organisations to balance release velocity against assurance. That tradeoff is real, especially where teams have many repositories, frequent deployments, or brittle build automation. Current guidance suggests that exceptions should be temporary and explicit, not treated as a permanent shared-key model.

One common edge case is local developer signing versus production release signing. Those should not use the same trust root, even if the same artefact format is involved. Another is cross-region or cross-cloud build infrastructure, where there may be pressure to centralise signing for convenience. Best practice is evolving here, but the emerging consensus is to keep the signing authority separate while distributing trust through attestation and policy, not through a shared private key.

It is also important to distinguish between signing keys and the broader secrets problem. If signing material lives in the same system as ordinary build credentials, a compromise can spread from routine job execution into release authority. That is why NHI governance, release governance, and supply chain controls need to be aligned rather than managed as separate disciplines. When identity teams and platform teams do not agree on who owns the signing boundary, shared keys tend to persist long after everyone agrees they should be removed.

Related resources from NHI Mgmt Group

• What breaks when container signing is optional across teams?
• How should security teams govern developer agents that can act across code, build, and deployment systems?
• What breaks when privileged credentials are shared across multiple systems?
• What breaks when SSH keys are managed manually across many systems?