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.
Editorial analysis by NHI Mgmt Group, based on content published by Veracode: “6 Best Practices for Managing Software Supply Chain Risks”.
By the numbers:
- 82% of organisations are now carrying security debt, up 11% year-over-year.
- 66% of the most critical, long-lived vulnerabilities originate from third-party code.
Key questions
Q: How should security teams prioritise software supply chain vulnerabilities?
A: Prioritise by exploitability, reachability, and runtime exposure rather than total CVE volume.
Q: Why do third-party code and AI tools increase product security risk so quickly?
A: They extend trust across dependencies that security teams do not fully own.
Q: What are the signs that software supply chain controls are failing in practice?
A: Common warning signs include overreliance on vulnerability lists, weak visibility into third party dependencies, limited scrutiny of developer tooling, and no practical way to audit the full software estate.
Practitioner guidance
- Map the full dependency estate Build and maintain an SBOM for every application and service, including direct and transitive dependencies, so teams can identify what is actually in production.
- Enforce ingestion controls on third-party code Set approval rules for new packages and block non-compliant or malicious dependencies before they enter the codebase or pipeline.
- Prioritise by reachability and exploitability Use reachability analysis, exploit intelligence, and business criticality to decide which vulnerabilities get fixed first.
Bottom line: Software supply chain risk in 2026 is being driven less by isolated dependency hygiene issues and more by exploited code that enters production through third-party and AI-assisted pathways.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 12:46 pm
Exploited code has become a governance problem, not just a secure development problem. When third-party code and AI-generated snippets become the dominant source of risk, the issue is no longer only whether developers wrote secure code. It is whether the organisation can prove that every imported artefact was authorised, monitored, and kept within policy. Practitioners should treat code provenance as part of identity and access governance for software delivery.
A few things that frame the scale:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: How should teams govern code context in AI coding assistants?
A: Treat code context as a governed input, not a convenience layer. Limit retrieval to approved repositories, document which internal libraries are eligible for reuse, and require review of enriched prompts when assistants pull in project-specific logic. The goal is to ensure the assistant inherits enterprise constraints instead of amplifying undocumented code patterns.
👉 Read our full editorial: Software supply chain risk in 2026 is shifting toward exploited code