Notifications
Clear all
Topic starter
24/06/2026 7:15 pm
TL;DR: Partial automation is leaving release integrity uneven, with DigiCert’s State of Software Supply Chain Security 2026 report finding only 13% fully automate code signing and only 13% fully automate security checks across all projects. When policy is manual at release velocity, attackers only need the easiest pipeline, not every pipeline.
NHIMG editorial — based on content published by DigiCert: How to close the CI/CD enforcement gap before it ships
By the numbers:
- Only 13% fully automate code signing.
- 71% of organizations say security checks are only partially automated or ad hoc.
- 89% lack formal enforced code-signing policies.
Questions worth separating out
Q: How should teams enforce code signing across CI/CD pipelines?
A: Teams should make signing a mandatory release control, not an optional developer step.
Q: Why do partially automated security checks create release risk?
A: Partially automated checks create inconsistent enforcement, which means different pipelines operate under different trust standards.
Q: What do security teams get wrong about automation in software supply chains?
A: Teams often treat partial automation as progress when it is really uneven control.
Practitioner guidance
- Make code signing a mandatory release gate Require every pipeline to sign release artefacts before promotion, and block deployment when signatures or policy evidence are missing.
- Standardise security checks across all pipelines Apply the same SAST, DAST, SCA, and artifact validation requirements to every project and every environment so coverage does not depend on team maturity.
- Protect signing keys as high-value identity material Store signing keys in HSMs or managed KMS and restrict access to the smallest possible set of release actors.
What's in the full article
DigiCert's full blog covers the operational detail this post intentionally leaves for the source:
- A practical order of operations for automating code signing without disrupting release cadence
- The report-backed breakdown of why teams struggle with implementation, including budget, expertise, and integration constraints
- How to secure signing keys, certificates, and release evidence across CI/CD workflows
- The article's view of leaders versus laggards and what each operating model looks like in practice
👉 Read DigiCert's analysis of the CI/CD enforcement gap before release integrity breaks →
CI/CD enforcement gaps: are your release controls keeping up?
Explore further
25/06/2026 4:28 am
Partial automation is not a maturity milestone, it is an integrity exception strategy. When release controls vary by team, product line, or pipeline, the organisation no longer has one enforcement model. It has a patchwork of local rules that attackers can route around and auditors cannot easily verify. The practical conclusion is that control consistency matters more than control presence.
A few things that frame the scale:
- Only 13% fully automate code signing, according to The State of Secrets Sprawl 2026.
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, showing that detection without enforcement leaves a long-lived trust problem.
A question worth separating out:
Q: Who is accountable when unsigned software reaches production?
A: Accountability sits with the owners of the release process, the platform controls, and the governance team that allowed the exception path to exist. In software supply chains, release integrity is an operating model issue, not just a development issue. NIST Cybersecurity Framework 2.0 helps structure that accountability across govern, protect, and respond.
👉 Read our full editorial: Closing the CI/CD enforcement gap before release integrity breaks
