Notifications
Clear all
Topic starter
02/08/2026 11:32 am
TL;DR: Software supply chain risk has shifted from occasional dependency hygiene to a persistent exposure problem, with 82% of organisations carrying security debt and 66% of the most critical long-lived vulnerabilities coming from third-party code, according to Veracode and the 2026 Verizon DBIR. The control model now has to combine continuous inventory, reachability-based triage, and pipeline enforcement because point-in-time scanning no longer matches how code enters production.
NHIMG editorial — based on content published by Veracode: 6 Best Practices for Managing Software Supply Chain Risks
By the numbers:
- 82% of organizations are now carrying security debt.
- 66% of the most critical, long-lived vulnerabilities originate from third-party code.
- Only 26% of critical vulnerabilities listed in CISA’s Known Exploited Vulnerabilities catalog were fully remediated.
Questions worth separating out
Q: How should security teams reduce the impact of CI/CD supply chain compromise?
A: Treat build systems as privileged identity infrastructure, not just delivery tooling.
Q: Why do third-party dependencies create more supply chain risk than first-party code?
A: Third-party dependencies expand trust beyond the team’s direct control.
Q: What breaks when organisations treat AI-generated code as automatically trusted?
A: Automated trust breaks because AI-generated code can introduce known security flaws that look legitimate at review time.
Practitioner guidance
- Implement continuous dependency inventory Maintain a complete software bill of materials for every application and service, including direct and transitive dependencies, and update it whenever builds or packages change.
- Prioritise by reachability and business impact Score findings by whether the vulnerable function is actually reachable in your runtime and whether the affected application is business-critical.
- Enforce pipeline gates for untrusted code Block builds or require reviewer approval when packages violate policy, when critical vulnerabilities are introduced, or when AI-generated code has not been scanned and labelled.
What's in the full article
Veracode's full guide covers the operational detail this post intentionally leaves for the source:
- Step-by-step SCA, SAST, and secret-scanning integration patterns for developer workflows and CI/CD gates
- Practical examples of reachability analysis and risk-based triage for vulnerability prioritisation
- Implementation guidance for package firewall policies and remediation automation across development pipelines
- Framework alignment detail for SSDF, SLSA, and related supply chain maturity assessments
👉 Read Veracode's 6 best practices for managing software supply chain risks →
Software supply chain risks in 2026: are your controls keeping up?
Explore further
02/08/2026 12:46 pm
Software supply chain security is now an identity governance problem as much as a code security problem. Build systems, package registries, CI/CD runners, and AI coding assistants all introduce non-human trust relationships that must be governed, not merely scanned. When those systems can create or move secrets, tokens, and deployment credentials, identity and supply chain risk converge. Practitioners should treat provenance and privilege as one control plane, not separate disciplines.
A question worth separating out:
Q: Which frameworks should guide software supply chain security programmes?
A: NIST SSDF and SLSA are the most useful starting points because they connect secure development practices to build integrity and provenance. Teams should map dependency governance, release attestation, and remediation SLAs to those frameworks, then use continuous monitoring to prove the controls are working in production.
👉 Read our full editorial: Software supply chain risk in 2026 is shifting toward exploited code
