Notifications
Clear all
Topic starter
02/08/2026 11:42 am
TL;DR: Software supply chain security tools are now being judged on whether they can discover transitive dependencies, block malicious packages, and prove compliance as security debt rises: 82% of organisations carry security debt and 66% of critical debt comes from third-party code, according to Veracode’s cited report. The practical shift is from detection-only tooling to layered control, developer workflow integration, and auditable remediation evidence.
NHIMG editorial — based on content published by Veracode: How to Evaluate Security Tools for the Software Supply Chain
By the numbers:
- 82% of organizations currently carry security debt, an 11% increase year-over-year.
- 60% of organizations are affected by critical security debt, representing a 20% jump from 2025.
- 66% of this critical security debt originates from third-party code.
Questions worth separating out
Q: How should security teams evaluate software supply chain security tools?
A: Start with coverage, not vendor claims.
Q: Why do software supply chain risks persist even when teams scan code regularly?
A: Because scanning detects issues, but it does not automatically fix weak ownership, stale dependencies, or over-permissioned release paths.
Q: What breaks when supply chain security stops at detection?
A: Detection-only programmes often leave teams with no safe way to fix what they find.
Practitioner guidance
- Inventory direct and transitive dependencies Build an authoritative component inventory that includes direct dependencies, transitive dependencies, package registries, and SBOM output for critical applications.
- Enforce package intake controls in CI/CD Require package firewalling, policy checks, and signed or approved package sources at ingestion so risky components are stopped before they reach builds.
- Prioritise exploitability over raw severity Weight remediation queues by exploitability, reachability, and business impact so teams fix issues that can actually be used.
What's in the full article
Veracode's full article covers the operational detail this post intentionally leaves for the source:
- A step-by-step evaluation matrix for comparing dependency discovery, prevention, remediation, integration, and compliance capabilities.
- Specific questions to use in a proof of concept, including scan duration, false positive rate, and developer workflow impact.
- The article's prioritise-protect-prove framework translated into tool selection criteria for engineering managers.
- Guidance on balancing direct costs, developer productivity, and long-term security debt reduction.
👉 Read Veracode's guide to evaluating software supply chain security tools →
Software supply chain security tools: are your controls keeping up?
Explore further
02/08/2026 12:53 pm
Security debt is now a supply chain governance problem, not just an application hygiene issue. When 66% of critical security debt comes from third-party code, the control problem moves upstream into procurement, dependency intake, and build governance. That shifts responsibility from individual developer fixes to repeatable assurance across the delivery pipeline. Organisations that still treat dependency risk as a backlog issue are managing the symptom, not the source, so supply chain governance has to become a board-visible control domain.
A question worth separating out:
Q: How do organisations prove their software supply chain controls are actually working?
A: Use evidence, not assumptions. Track reduction in security debt, remediation time, false positive rates, blocked package events, and audit-ready reports over time. If the tool cannot show measurable change in dependency risk and developer behaviour, it is only producing activity, not assurance.
👉 Read our full editorial: Software supply chain security tools need visibility, prevention and proof
