Why do code signing controls matter in software supply chains?

Why Code Signing Matters in Supply Chain Security

Code signing turns a release into something that can be verified, not merely trusted. In software supply chain, that matters because compromise often happens before deployment, when artifacts are built, mirrored, cached, or repackaged. A signature does not make code safe by itself, but it gives security teams a way to detect tampering, bind a build to a known publisher, and make unauthorized modification harder to hide. That is especially important when secrets and release credentials are already a frequent target, as highlighted in The State of Secrets in AppSec.

Without signing, downstream systems tend to inherit trust from the pipeline instead of proving the artifact’s origin. Current guidance from OWASP Non-Human Identity Top 10 aligns with this: machine credentials and build identities need explicit controls because they are often reused, over-scoped, or exposed in automation. In practice, many teams discover code integrity gaps only after a package, container image, or release artifact has already been consumed in production.

How Code Signing Works in Practice

Effective code signing ties three things together: the artifact, the signer identity, and the validation policy. A build system signs an output using a private key held in a protected signing service, hardware-backed module, or short-lived signing workflow. Consumers then verify the signature, the certificate chain, and the policy that says which identities are allowed to sign which artifact types. This is why code signing is more than a checkbox for release engineering; it is a control over provenance.

For modern pipelines, best practice is evolving toward ephemeral build identities and tightly scoped signing authority. That means limiting who or what can request a signature, shortening key lifetime, and revoking trust quickly when a build runner, repository token, or release account is suspected of compromise. Research from Reviewdog GitHub Action supply chain attack shows how quickly automation can become an attack path when pipeline trust is implicit. The operational goal is to ensure that a signed artifact is both authentic and attributable.

• Sign at the final trusted build stage, not earlier where artifacts can still be altered.
• Protect signing keys with hardware-backed or service-backed controls and strict access policy.
• Verify signatures in CI/CD, package registries, and deployment gates before promotion.
• Revoke or rotate signing trust when build infrastructure, secrets, or release automation are exposed.

Where this guidance breaks down is in loosely governed multi-tenant build environments that let untrusted workflows reach the same signing authority as production release jobs.

Common Variations and Edge Cases

Tighter signing controls often increase build and release overhead, requiring organisations to balance integrity against delivery speed. That tradeoff is real, especially when legacy systems cannot easily support modern provenance checks. In those environments, there is no universal standard for how far validation must extend, but current guidance suggests starting with the highest-risk artifacts: externally distributed packages, container images, and binaries that execute with elevated privileges.

Another edge case is “signed but unsafe” software. A valid signature proves origin, not trustworthiness. If the signer identity, CI runner, or release automation is compromised, the attacker can produce perfectly valid malicious artifacts. That is why signing must be paired with provenance, least privilege, and secret hygiene. The escalation path seen in Shai Hulud npm malware campaign reflects a broader reality: once automation credentials are abused, attackers can sign, publish, and persist inside the supply chain.

In mature programmes, security teams also treat code signing as a governance control for non-human identities. That makes the linkage to Ultimate Guide to NHIs — Standards especially relevant, because signing authority is ultimately an NHI trust decision. The hardest failures usually appear when signing is automated but the surrounding identity, secret rotation, and validation policy remain manual.

Related resources from NHI Mgmt Group

• How should security teams govern machine identities in software supply chains?
• Why do software supply chains create such a high NHI governance burden?
• When should organisations prioritise privileged access management over network controls in supply chains?
• Why do software supply chain failures matter so much for IAM and NHI teams?