Code signing

Expanded Definition

Code signing is more than adding a certificate to an executable. In NHI and CI/CD governance, it is a cryptographic control that binds a software artifact to a trusted signer, so downstream systems can verify origin, integrity, and release authenticity before execution or deployment. That matters because the signer is often a non-human identity such as a build service, release pipeline, or automation account, and the trust model is only as strong as the protection around that identity and its private key. The control aligns closely with supply chain integrity guidance in the NIST Cybersecurity Framework 2.0, especially where organisations need evidence that trusted software has not been altered after build.

Definitions vary across vendors on whether code signing includes only binaries or also scripts, containers, mobile apps, and package artifacts. In practice, NHI security treats it as a release trust control that must be enforced automatically, logged, and protected by strong key custody. The most common misapplication is treating code signing as a one-time compliance checkbox, which occurs when teams sign artifacts manually but leave keys, approval paths, or pipeline permissions exposed.

Examples and Use Cases

Implementing code signing rigorously often introduces release friction, requiring organisations to weigh faster delivery against stronger controls on signing authority, key access, and verification gates.

• A build pipeline signs release binaries with a dedicated service account, and deployment tooling refuses unsigned artifacts.
• A mobile app release process requires a protected signing key stored in an HSM, reducing the risk of key theft during CI/CD operations.
• A software vendor publishes signed packages so customers can verify that dependencies were produced by the expected publisher and not replaced in transit.
• A security team maps signing obligations to the governance and visibility concerns described in the Ultimate Guide to NHIs, because the signer itself is an NHI that must be inventoried and controlled.
• An engineering group signs container images and enforces signature verification before promotion into production, using policy checks similar to the trust model described by NIST Cybersecurity Framework 2.0.

Code signing is especially useful when release pipelines need to prove that artifacts came from a specific automated build path rather than from a developer workstation or ad hoc manual upload.

Why It Matters in NHI Security

Code signing becomes an NHI security issue because the signer is usually a privileged machine identity with access to release systems, private keys, and artifact repositories. If that identity is over-privileged, poorly rotated, or insufficiently monitored, attackers can sign malicious payloads that appear legitimate to downstream consumers. NHI Mgmt Group notes that Ultimate Guide to NHIs reports that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, and 97% of NHIs carry excessive privileges, which helps explain why signing pipelines are attractive targets.

That risk extends beyond malware. A compromised signing key can invalidate software provenance, complicate incident response, and force emergency key rotation across multiple release channels. Good governance therefore includes signer inventory, privilege restriction, approval workflow hardening, signing-key custody, and signature verification at every trust boundary. Organisations typically encounter the operational impact only after a tampered release, stolen key, or pipeline compromise, at which point code signing becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• What is the difference between code signing and code provenance?
• When does code signing become essential rather than optional?
• What is the difference between code signing and secure code provenance?
• What is the difference between commit signing and SBOMs for code security?