Topic starter
02/08/2026 11:34 am
TL;DR: Vulnerabilities now account for 31% of initial access vectors, while 82% of organisations carry security debt and 66% of the most critical long-lived flaws originate in third-party code, according to Veracode and the 2026 Verizon DBIR. That makes software supply chain security a governance problem, not a scanning problem.
Editorial analysis by NHI Mgmt Group, based on content published by Veracode: “5 Core Components of a Strong Software Supply Chain Security Framework”.
By the numbers:
- Exploitation of vulnerabilities now accounts for 31% of all initial access vectors, according to Veracode.
- 82% of organisations now carry security debt, according to Veracode.
- 66% of the most critical, long-lived vulnerabilities originate in third-party code, according to Veracode.
Key questions
Q: What breaks when supply chain security relies on patching alone?
A: Patch-only programs miss the paths attackers actually use.
Q: When should organisations prioritise governance over more vulnerability scans?
A: They should prioritise governance when dependencies are numerous, third-party code dominates risk, and remediation already lags behind discovery.
A: A common warning sign is that teams still depend on outdated practices, like static testing alone, while third-party components are entering production more quickly than security can review them.
Practitioner guidance
- Implement dependency intake governance Require approval and provenance checks for direct and transitive dependencies before they enter the build pipeline.
- Gate AI-generated code with security tests Run automated security validation on AI-assisted code before merge, especially for injection, authentication, and secret-handling failures.
- Generate SBOMs on every release Produce machine-readable software bills of materials for each build so teams can trace what shipped, what changed, and what remains exposed.
Bottom line: Software supply chain security has become a governance problem because third-party code, AI-assisted development, and build automation now shape production risk as much as traditional vulnerabilities do.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 12:48 pm
Governance is now the control plane for software supply chain security. The article is right to move the conversation away from reactive patching, because patching only addresses known flaws after they are already in circulation. The real problem is that software is assembled from dependencies, build automation, and AI-generated code, which means trust decisions happen before a vulnerability is even visible. Practitioners should treat provenance, approval, and auditability as first-class security controls.
A few things that frame the scale:
- Credential abuse across the entire attack chain, not just initial access, appears in 39% of all breaches, according to the 2026 Verizon Data Breach Investigations Report.
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: How should teams govern software build identities in a supply chain programme?
A: Treat build service accounts, tokens, and deployment credentials as production identities with lifecycle ownership, scope limits, and revocation rules. If those identities are overprivileged or poorly inventoried, they can become the path by which malicious code, compromised packages, or unsafe automation reaches production.
👉 Read our full editorial: Software supply chain security is shifting from patching to governance