Notifications
Clear all
Topic starter
24/06/2026 11:12 pm
TL;DR: Software signing failures usually trace to weak governance around signing authority, key handling, access control, and workflow enforcement rather than cryptographic breakdowns, according to DigiCert. Without auditable controls, signing can extend trust too far and turn release pipelines into a source of persistent risk.
NHIMG editorial — based on content published by DigiCert: Why Software Signing Fails Without Governance
Questions worth separating out
Q: How should security teams govern software signing in CI/CD pipelines?
A: Security teams should treat software signing as a privileged identity function, not a developer convenience.
Q: Why do software signing controls fail even when policies exist?
A: They fail when policy is not backed by enforceable workflow controls.
Q: What breaks when signing keys are reused across projects?
A: Reusing signing keys expands blast radius because one credential can validate multiple products or release streams.
Practitioner guidance
- Scope signing authority to named roles and products Limit who can sign software to explicitly approved roles, and bind each signer to specific products, pipelines, or release channels.
- Treat signing keys as privileged credentials Store keys in protected systems, avoid shared locations, rotate them on a defined schedule, and revoke them immediately when their business purpose ends.
- Move signing controls into the release workflow Block signing when validation is incomplete, and make policy checks part of the pipeline rather than a manual checklist.
What's in the full article
DigiCert's full blog covers the operational detail this post intentionally leaves for the source:
- The vendor's discussion of how signing controls fit into real CI/CD release workflows and exception handling.
- The vendor's explanation of how its Software Trust Manager centralises signing keys, access, and policy enforcement.
- The article's practical examples of ownership, auditability, and workflow-integrated control design for software signing.
- The source's own framing of how governance failures accumulate across teams, tools, and pipelines.
👉 Read DigiCert's analysis of why software signing fails without governance →
Software signing governance: what IAM teams are missing?
Explore further
25/06/2026 7:57 am
Software signing fails when authority outgrows governance. The core issue is not cryptography but entitlement sprawl, where too many people and systems can sign too much software. That pattern mirrors familiar IAM drift: permissions accumulate faster than reviews can remove them. The practitioner conclusion is that signing has to be governed like any other privileged identity function.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, according to The State of Non-Human Identity Security.
A question worth separating out:
Q: Who is accountable when a signed release is later found to be untrusted?
A: Accountability sits with the team that owns signing authority, key lifecycle, and release enforcement, not only with the people who authored the code. If reviews were bypassed, keys were shared, or offboarding lagged, the failure is governance. Mature programmes assign clear ownership to the signing control plane itself.
👉 Read our full editorial: Software signing governance is the real control plane for trust
