How should teams enforce code signing across CI/CD pipelines?

Why This Matters for Security Teams

Code signing turns a build artifact into a verifiable supply chain statement: this exact output came from an approved pipeline, with approved keys, at a known point in time. Without enforced signing, release integrity becomes a human discipline problem, and humans miss steps under pressure. NIST frames this as a core governance and protection issue in the NIST Cybersecurity Framework 2.0, while NHIMG’s CI/CD pipeline exploitation case study shows how pipeline trust assumptions are often the first thing attackers abuse.

The practical risk is not just unsigned software reaching production. It is the loss of provenance, the inability to prove which build was deployed, and the inability to distinguish a legitimate artifact from one altered by a compromised runner, stolen token, or malicious dependency. Teams that leave signing optional tend to discover the gap only after a release incident, not during normal governance.

How It Works in Practice

Strong enforcement starts by making signature verification a gate, not a recommendation. Every build artifact, container image, package, or release bundle should be signed automatically by the pipeline, and promotion should fail if the signature is absent, invalid, expired, or bound to the wrong identity. The signing key should never be handled by developers directly. It belongs in an HSM or managed KMS, with tightly scoped pipeline access and auditable use.

In mature setups, teams separate three concerns:

• Build identity: prove which CI system or workload produced the artifact.
• Signing authority: protect the private key and restrict who or what can invoke it.
• Verification policy: reject anything that does not match the expected signer, digest, and provenance.

This is why artifact verification should happen at multiple points. The pipeline should verify before publishing, the registry or package repo should verify before accepting, and the deployment stage should verify again before promotion. Guidance from supply chain standards is converging on this layered model, and the Guide to the Secret Sprawl Challenge is a useful reminder that signing controls also reduce the temptation to move credentials and tokens through ad hoc channels.

For implementation, teams usually pair signing with provenance metadata such as build attestation, commit hash, runner identity, and immutable artifact digest. That makes it possible to answer a simple question later: not just “was it signed?” but “what exactly was signed, by what, and under which conditions?” These controls tend to break down when ad hoc scripts bypass the release pipeline because the unsigned path becomes the fastest path to production.

Common Variations and Edge Cases

Tighter signing enforcement often increases pipeline friction, requiring organisations to balance release speed against stronger integrity guarantees. That tradeoff is real, especially where multiple teams, languages, or deployment targets share one delivery system.

One common edge case is legacy tooling that cannot verify signatures natively. In those environments, current guidance suggests adding a verification shim at the promotion layer rather than weakening the policy. Another is ephemeral preview environments, where teams sometimes allow unsigned builds for short-lived testing. That may be acceptable if the environment is isolated and never allowed to promote, but there is no universal standard for this yet.

Secrets and signing keys deserve different treatment. A long-lived developer token in a pipeline is a risk factor, while a short-lived workload identity plus a controlled signing service is usually safer. The operational pattern that holds up best is to bind signing to the CI workload identity, not to a person, and to revoke or rotate on compromise immediately. The Reviewdog GitHub Action supply chain attack is a good example of why inherited trust in third-party automation is not enough.

Teams should also be careful with multi-arch builds, hotfix releases, and re-signing after packaging. A release process that signs only the “main” artifact but not rebuilt variants leaves gaps attackers can exploit. Best practice is evolving, but the safest default is simple: every releasable artifact gets signed, every signature is verified, and every bypass is logged and treated as an exception, not a workflow.

Related resources from NHI Mgmt Group

• How should security teams implement SBOM signing in CI/CD pipelines?
• How should teams enforce open-source licence compliance in CI/CD pipelines?
• How should security teams enforce MIT license compliance in CI/CD pipelines?
• How should security teams make NHI best practices usable across the business?