Notifications
Clear all
Topic starter
24/06/2026 7:32 pm
TL;DR: 84% of organisations say they have a comprehensive program, yet only 13% fully automate code signing, 11% actively provide SBOMs, and 12% always sign container images, according to DigiCert’s State of Software Supply Chain Security 2026. Perception is outpacing enforceable control, leaving integrity gaps that attackers and auditors will both exploit.
NHIMG editorial — based on content published by DigiCert: Software Supply Chain Blind Spots
By the numbers:
- Only 13% fully automate code signing.
- Only 11% actively provide software bills of materials (SBOMs) today.
Questions worth separating out
Q: How should security teams enforce code signing across software delivery pipelines?
A: Security teams should make signing a release gate, not an optional build step.
Q: When do SBOMs become useful for governance rather than just inventory?
A: SBOMs become governance evidence when they are accurate, signed, and tied to the specific artefact that was released.
Q: What breaks when software supply chain controls are only partially automated?
A: Partial automation creates inconsistent enforcement, which means some builds are protected while others slip through manual exceptions or forgotten paths.
Practitioner guidance
- Make signing mandatory in the release path Require every binary, container image, and SBOM to be signed before promotion from build to release.
- Separate policy from proof in supply chain reviews Ask teams to show where code signing, SBOM generation, and verification occur in the pipeline rather than accepting program status labels.
- Protect signing keys as high-value identity assets Store private keys in HSMs or managed KMS platforms and restrict signing access to tightly scoped service identities with clear ownership and rotation rules.
What's in the full article
DigiCert's full article covers the operational detail this post intentionally leaves for the source:
- Metric-by-metric breakdown of code signing, SBOM, and CI/CD automation maturity across surveyed organisations
- The report's full commentary on how organisations are approaching PQC preparedness and cryptographic transition planning
- Specific release-governance observations on why manual controls still dominate many software pipelines
- The underlying survey framing that supports the maturity and execution findings discussed above
👉 Read DigiCert’s analysis of software supply chain blind spots and maturity gaps →
Software supply chain blind spots: what IAM teams need to act on?
Explore further
25/06/2026 4:53 am
Software supply chain maturity is being misread because policy presence is being confused with control enforcement. A program can look established on paper while still leaving signing, SBOMs, and CI/CD checks only partially automated. That mismatch is not cosmetic. It means assurance depends on humans following the intended path, which is exactly where software delivery environments are least reliable. Practitioners should treat maturity claims as unproven until the release path is consistently enforced.
A few things that frame the scale:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
- In the same research, 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase that shows exposure is still accelerating.
A question worth separating out:
Q: Who should own PQC readiness in an enterprise security programme?
A: PQC readiness should be owned jointly by security architecture, platform engineering, and identity governance because it depends on cryptographic inventory, certificate lifecycle, and supplier dependencies. The right model treats quantum-safe migration as planned lifecycle work, not a last-minute compliance task. Ownership must be explicit before transition timelines compress.
👉 Read our full editorial: Software supply chain blind spots outpace perceived maturity
