Software supply chain blind spots outpace perceived maturity

At a glance

What this is: This is a software supply chain security report showing that maturity claims are materially ahead of measurable control enforcement.

Why it matters: It matters to IAM and NHI practitioners because software integrity, signing, and auditability increasingly govern how machine identities, build pipelines, and release artefacts are trusted.

By the numbers:

• 84% of surveyed organizations say they’ve established or are developing a comprehensive program for software supply chain security.
• Only 13% fully automate code signing.
• Only 11% actively provide software bills of materials (SBOMs) today.

👉 Read DigiCert’s analysis of software supply chain blind spots and maturity gaps

Context

Software supply chain security is the discipline of proving that build inputs, code signing, artefacts, and release processes are controlled rather than assumed. The problem in this report is not a lack of awareness, but a gap between self-assessed maturity and the actual state of enforcement across modern development pipelines.

That gap matters because the security model for software delivery now depends on identity, integrity, and lifecycle control as much as it does on vulnerability management. For NHI and IAM teams, the question is whether build systems, signing keys, SBOMs, and CI/CD controls are being governed with the same rigour as human and workload access.

DigiCert’s findings are best read as an execution warning: many organisations believe they are further along than their controls prove. That is a familiar pattern in software trust programmes, and it is still the typical starting position.

Key questions

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. Enforce policy in the pipeline so unsigned artefacts cannot move forward, and require the signing identity, key storage, and approval path to be auditable. If teams can bypass signing manually, the control is advisory rather than enforceable.

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. A generated inventory without integrity protection can still be incomplete or altered. Practitioners should use signed SBOMs to support audit, supplier assurance, and incident response, not as standalone documentation.

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. That weakens trust in the whole release process. The practical consequence is asymmetric risk, where attackers only need to find one unprotected route to get a compromised artefact into production.

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.

Technical breakdown

Code signing automation and release integrity

Code signing is the cryptographic process that proves a software artefact came from a known source and has not been altered after signing. In mature environments, signing is tied to policy, identity, and release workflow rather than left to an optional manual step. The report shows many teams still rely on partial automation, which means the trust decision is inconsistent across pipelines. That creates a measurable difference between what is built, what is approved, and what is actually released.

Practical implication: enforce signing as a mandatory release control across all build paths, not as a developer convenience.

SBOMs, artefact provenance, and tamper evidence

An SBOM is a machine-readable inventory of software components and dependencies. On its own, it is only an assertion of contents. When the SBOM is signed and linked to provenance data, it becomes evidence that can support audit, incident response, and supplier assurance. The report’s SBOM findings show that many organisations are generating or planning for inventories, but not consistently turning them into trusted artefacts. Without signing and enforcement, provenance claims remain easy to dispute.

Practical implication: treat SBOM generation, signing, and retention as linked controls in the software release process.

PQC readiness and cryptographic agility

Post-quantum cryptography readiness is about inventorying where current algorithms, keys, and certificate chains are used so they can be replaced before they become operational liabilities. The important governance issue is not only the algorithms themselves, but the lack of a cryptographic transition plan. If organisations wait until mandates or migrations are unavoidable, the work compresses into a short window and exposes systems, suppliers, and signing workflows to avoidable disruption. The report correctly places PQC preparedness alongside signing and automation because they are part of the same trust fabric.

Practical implication: map cryptographic dependencies now so signing and certificate changes can be managed as planned lifecycle work.

NHI Mgmt Group analysis

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.

Integrity controls are now the real control plane for software trust. Code signing, SBOM integrity, and cryptographic verification together decide whether a build artefact can be trusted downstream. When any one of those is optional, the entire trust chain becomes conditional. The field should stop treating these controls as separate hygiene items and recognise them as one release assurance system. The implication is that software trust is only as strong as its weakest enforcement point.

Cryptographic agility is no longer a future-planning exercise. PQC preparation now sits in the same governance category as certificate lifecycle and signing-key management. The organisations that delay cryptographic inventory and transition planning will inherit compressed timelines, supplier dependencies, and audit exposure at the same time. That makes PQC readiness an operational discipline, not a research topic. Practitioners need to govern it as a lifecycle issue today.

Signed artefacts, not stated confidence, are what auditors and defenders can rely on. The report shows a familiar pattern in security programmes: confidence rises faster than measurable execution. That gap creates false comfort for leadership and hidden exposure for engineering teams. The practical conclusion is simple: if a control cannot be verified in the pipeline, it is not yet a control at all.

From our research:

• 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.
• For lifecycle control detail, Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs is the natural next step for teams formalising rotation, offboarding, and governance.

What this signals

Signed artefact governance will become a baseline control rather than a specialised trust program. As software delivery velocity increases, teams will need release evidence that can survive audit, supplier review, and incident response without manual reconstruction. The organisations that align build integrity with identity governance now will spend less time defending assumptions later.

The next maturity gap will show up in cryptographic transition planning, not just in signing coverage. Once teams begin inventorying keys, algorithms, and certificate dependencies, they will see how much of the programme still depends on undocumented exceptions and legacy paths. That is where policy turns into operational risk.

With 28.65 million new hardcoded secrets detected in public GitHub commits in 2025 alone, exposure is still scaling faster than many teams can absorb. The State of Secrets Sprawl 2026 shows why the governance conversation has shifted from discovery to durable enforcement.

For practitioners

• Make signing mandatory in the release path Require every binary, container image, and SBOM to be signed before promotion from build to release. Remove manual exception paths and tie enforcement to pipeline gates so unsigned artefacts cannot advance.
• 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. Use evidence from the build system, not slide decks, to assess maturity.
• 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.
• Build a cryptographic inventory for PQC transition Catalogue algorithms, certificates, dependent systems, and supplier touchpoints so quantum-safe migration work can be scheduled rather than rushed under mandate pressure.
• Verify SBOM integrity as part of supplier assurance Require signed SBOMs for critical software and align procurement checks to confirm that inventory, provenance, and release evidence are all available for review.

Key takeaways

• Software supply chain maturity claims are only meaningful when signing, SBOMs, and pipeline checks are consistently enforced.
• The report shows a wide gap between perceived progress and measurable control coverage, which is exactly where integrity risk accumulates.
• Practitioners should treat release signing, cryptographic inventory, and SBOM integrity as core governance controls, not optional engineering preferences.

Key terms

• Code Signing: Code signing is a cryptographic method for proving that software came from a trusted source and has not changed after approval. In practice, it binds release identity to an artefact so downstream systems can verify provenance before execution or deployment.
• Software Bill of Materials: A software bill of materials is a structured inventory of the components, libraries, and dependencies inside a software package. It becomes materially useful when it is accurate, signed, and linked to the specific release artefact it describes.
• Cryptographic Agility: Cryptographic agility is the ability to replace algorithms, keys, and certificate dependencies without redesigning the whole system. It matters because software supply chains, signing workflows, and trust anchors must be able to change before current cryptography becomes obsolete or risky.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or governance in your organisation, it is worth exploring.

This post draws on content published by DigiCert: Software Supply Chain Blind Spots. Read the original.