Notifications
Clear all
Topic starter
25/06/2026 2:52 pm
TL;DR: Software supply chains are exposed to tampering when code signing keys, certificates, and build permissions are fragmented or overbroad, according to Keyfactor. The identity problem is not the signature itself, but whether machine identities and signing workflows are governed tightly enough to preserve trust at release time.
NHIMG editorial — based on content published by Keyfactor: Code Signing 101: Locking Down Your Software Supply Chain
Questions worth separating out
Q: What breaks when code signing keys are shared across build systems?
A: Shared signing keys collapse the separation between trusted release actions and ordinary build activity.
Q: Why do code signing controls matter in software supply chains?
A: Code signing matters because it turns software integrity into a verifiable identity assertion.
Q: What do security teams get wrong about code signing lifecycle management?
A: The common mistake is treating certificates as one-time setup items instead of governed assets with issuance, renewal, rotation, and revocation requirements.
Practitioner guidance
- Centralise certificate issuance and inventory Maintain one authoritative inventory of active, expired, and revoked code signing certificates so teams can see where trust exists and where it has lapsed.
- Restrict signing authority to approved systems Separate signing keys from ordinary build credentials and require role-based approvals for any system that can request or use signing operations.
- Store private keys in hardware-backed controls Keep signing keys in HSMs or secure cloud vaults so private material is not exposed on shared file systems or general-purpose build servers.
What's in the full article
Keyfactor's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step guidance for centralising code signing certificate issuance and inventory across development teams.
- Implementation detail on using HSMs and cloud vaults to protect signing private keys.
- Workflow examples for enforcing approval gates and audit logging inside CI/CD pipelines.
- Operational notes on short-lived certificates for ephemeral workloads and automated renewal patterns.
👉 Read Keyfactor's code signing guidance for securing software supply chains →
Code signing certificates and software supply chains: where controls fail?
Explore further
25/06/2026 4:03 pm
Code signing is a machine identity control, not a build-system feature. The security value comes from binding software to a governed identity that can be issued, constrained, and revoked. When organisations treat signing as a developer convenience, they miss the real risk surface: who can sign, under what authority, and with which lifecycle controls. Practitioners should manage signing as part of NHI governance, not release engineering.
A few things that frame the scale:
- Companies are dedicating an average of 32.4% of their security budgets to secrets management and code security, with US organisations leading at 40.8%, according to The State of Secrets in AppSec.
- 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, which shows the control problem is already expanding beyond traditional secrets leakage.
A question worth separating out:
Q: Who is accountable when a signed release contains malicious code?
A: Accountability sits with the organisation that issued and governed the signing authority, not just the developer who pushed the code. If keys, approvals, or audit trails were weak, the release process itself failed. That is why PKI, IAM, and DevSecOps ownership must be coordinated before incidents occur.
👉 Read our full editorial: Code signing security is a machine identity problem
