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.
Editorial analysis by NHI Mgmt Group, 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 critical security debt originates from third-party code.
Key questions
Q: What breaks when software supply chain tools only detect vulnerabilities after code is installed?
A: Detection-only tooling creates a growing backlog because risky dependencies are already inside the build chain before anyone can block them.
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: How do organisations prove their software supply chain controls are actually working?
A: Use evidence, not assumptions.
Practitioner guidance
- Build a complete dependency inventory Map direct and transitive dependencies across every application, then generate SBOMs so you can see what enters the build and what reaches production.
- Enforce upstream package policy Use package firewalls or equivalent controls to block malicious or non-compliant packages before they are installed in developer workflows or CI pipelines.
- Tie remediation to risk and evidence Prioritise exploitable third-party issues, then track fixes with historical vulnerability records and remediation evidence that can support audit and executive review.
Bottom line: Third-party code now drives a disproportionate share of critical security debt, so software supply chain control must extend beyond first-party code review.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 12:53 pm
Software supply chain security is now an identity problem as much as a code problem: build pipelines, registries and package managers depend on machine identities, tokens and automated trust paths. When those identities are unmanaged, security tools can detect risk after the fact but cannot prove who or what was authorised to introduce code. Practitioners should treat dependency governance as part of non-human identity governance.
A few things that frame the scale:
- Breaches involving third parties rose to 48% of all breaches, a 60% increase on the previous year, according to Verizon's 2026 Data Breach Investigations Report.
A question worth separating out:
Q: What is the difference between scanning dependencies and proving software supply chain security?
A: Scanning finds issues, but proof shows that the organisation can trace what was shipped, what was fixed, and when it was fixed. Proof requires SBOMs, remediation records, historical trend data and reporting that stands up to audit or board review. Without that layer, security claims remain difficult to verify.
👉 Read our full editorial: Software supply chain security tools need visibility, prevention and proof