Notifications
Clear all
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.
NHIMG editorial — based on content published by Veracode: 5 Core Components of a Strong Software Supply Chain Security Framework
By the numbers:
- Vulnerabilities now account for 31% of all initial access vectors, surpassing credential abuse at 13%.
- 82% of organisations now carry security debt, up 11% year-over-year.
- 66% of the most critical, long-lived vulnerabilities originate from third-party code.
Questions worth separating out
Q: How should teams implement software supply chain security across build pipelines?
A: Start by inventorying dependencies, then add provenance checks, secret governance, and continuous remediation evidence at the pipeline level.
Q: Why do third-party dependencies create such persistent security debt?
A: Third-party dependencies create persistent security debt because organisations often discover flaws faster than they can replace, patch, or retest them.
Q: What do security teams get wrong about supplier SBOMs?
A: They often assume receipt equals assurance.
Practitioner guidance
- Map every build identity and secret Inventory the service accounts, API keys, tokens, and signing credentials used across CI/CD, package publishing, and release automation.
- Require provenance checks before dependency admission Block packages that lack source verification, contributor traceability, or trusted repository lineage.
- Embed security gates into AI-assisted development Scan AI-generated code for insecure patterns before merge, and require review for any generated output that introduces authentication, authorization, or secret-handling logic.
What's in the full article
Veracode's full post covers the operational detail this post intentionally leaves for the source:
- Step-by-step Software Composition Analysis implementation across direct and transitive dependencies
- Specific remediation workflow guidance for vulnerability triage, prioritisation, and release gating
- Operational examples for SBOM generation, audit evidence, and executive reporting
- Detailed treatment of AI code security controls and secure development workflow integration
👉 Read Veracode's framework for software supply chain security controls →
Software supply chain security framework gaps teams are missing?
Explore further
02/08/2026 12:48 pm
Software supply chain security is now an identity problem as much as a code problem. Build systems, package registries, CI/CD pipelines, and AI coding assistants all rely on service accounts, tokens, and secrets to move software forward. When those non-human identities are weakly governed, the software supply chain inherits the same trust failures that IAM and PAM were built to control. The practitioner conclusion is straightforward: supply chain security cannot mature without machine identity governance.
A question worth separating out:
Q: Which controls matter most when AI generates production code?
A: The most important controls are automated security scanning, mandatory review for authentication and secret-handling logic, and policy checks that block insecure patterns before merge. AI output should be treated as untrusted code until it passes the same validation expected of human-authored changes.
👉 Read our full editorial: Software supply chain security is shifting from patching to governance
