Topic starter
19/08/2026 3:24 pm
TL;DR: Transitive dependencies account for roughly 95% of open-source vulnerabilities, so surface-level scanning covers only a fraction of real software supply chain risk, according to Kusari and Endor Labs research. The governing issue is not missing CVEs, but missing recursive visibility, reachability analysis, and ownership across the full dependency graph.
Editorial analysis by NHI Mgmt Group, based on content published by Kusari: “The 95% Problem: Why Transitive Dependencies Are Your Biggest Software Supply Chain Blind Spot in 2026”.
By the numbers:
- According to Endor Labs research cited by Kusari, roughly 95% of open-source vulnerabilities reside in transitive dependencies rather than directly declared packages.
Key questions
Q: What breaks when transitive dependencies are not fully inventoried?
A: Teams lose sight of the software they actually ship.
Q: Why do transitive dependencies create more remediation complexity in application security programs?
A: Transitive dependencies complicate remediation because the vulnerable code is not always imported directly by the application.
Q: How do you know if dependency governance is actually working?
A: You know it is working when risky upgrades are caught before deployment, automated changes correlate with successful tests, and engineering teams stop discovering hidden breakage only after release.
Practitioner guidance
- Generate recursive SBOMs for every build Capture the full dependency graph, including nested packages inherited through package manager resolution, so the inventory matches what ships to production.
- Add reachability analysis to SCA triage Check whether a vulnerable function is actually invoked by application code before escalating remediation, especially for deeply nested libraries.
- Prioritise by blast radius, EPSS, and KEV Use exploitability and exposure context to decide what gets fixed first, instead of treating every flagged transitive component as equally urgent.
Bottom line: Transitive dependency blind spots can make a clean scan misleading because the majority of inherited risk sits beyond direct package lists.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/08/2026 4:09 pm
Transitive dependency visibility is now a supply chain governance problem, not a tooling gap. The article shows that scanning direct dependencies leaves most inherited risk outside the control boundary. In practice, the failure is not the absence of alerts but the absence of a complete object model for what the software actually contains. Practitioners should treat recursive dependency inventory as a governance control, not an optional enhancement.
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.
A question worth separating out:
Q: Should teams prioritise recursive SBOMs before automated remediation?
A: Yes, because automation built on an incomplete inventory simply accelerates bad decisions. A recursive SBOM establishes the software truth set, while remediation automation acts on that truth. Without the complete graph first, teams may patch the wrong packages or miss transitive exposure entirely.
👉 Read our full editorial: Transitive dependency risk exposes the software supply chain blind spot