Notifications
Clear all
Topic starter
18/08/2026 2:34 pm
TL;DR: Only 28% of respondents have strong insight into transitive dependency layers, leaving roughly 72% of organisations making security decisions on an incomplete view of their software supply chain, according to Kusari's Application Security in Practice report. That visibility gap turns SCA into a partial control, not a full answer, because nested components can change between scans and evade remediation.
NHIMG editorial — based on content published by Kusari: Application Security in Practice and the transitive dependency attack surface
By the numbers:
- Only 28% of respondents feel they have strong insight into their transitive dependency layers.
- 47% of teams spend more than 5 hours per week on supply chain security remediation.
Questions worth separating out
Q: What breaks when organisations cannot see their transitive dependency attack surface?
A: When organisations cannot see transitive dependencies, they lose the ability to judge what is actually running, which vulnerabilities are reachable, and which fixes matter first.
Q: Why do transitive dependencies create more software supply chain risk than direct packages alone?
A: Transitive dependencies hide exposure inside nested libraries that are often missed by top-level package reviews.
Q: How do you know if dependency visibility is actually working?
A: You should be able to answer how many dependency layers you track, how current that data is, and whether your SBOM includes nested components with provenance.
Practitioner guidance
- Inventory the full dependency graph Map direct and transitive dependencies across every supported ecosystem, then compare SCA output to what is actually deployed in production to expose coverage gaps.
- Move from build-time checks to continuous monitoring Run dependency monitoring on every pull request and after each release so newly disclosed vulnerabilities in nested packages are detected before they accumulate into backlog.
- Add reachability and provenance to triage workflows Use reachability analysis to separate theoretical exposure from executable risk, and require provenance data for transitive components before prioritising remediation.
What's in the full article
Kusari's full analysis covers the operational detail this post intentionally leaves for the source:
- Per-ecosystem dependency visibility examples across npm, Maven, PyPI, NuGet, Gradle, and cargo.
- The report's maturity breakdown for teams that check posture daily or on every pull request.
- Operational detail on reachability analysis and EPSS-based prioritisation for transitive components.
- Remediation workflow examples for updating direct libraries to pull in patched nested packages.
👉 Read Kusari's analysis of transitive dependency visibility and supply chain risk →
Transitive dependency visibility is the governance gap teams miss?
Explore further
18/08/2026 3:21 pm
Dependency visibility is now a governance control, not an AppSec nice-to-have. The article shows that most organisations are operating with an incomplete map of their software supply chain, and that makes risk decisions structurally unreliable. When nested components can change outside the organisation's immediate view, security posture becomes a moving target rather than a governed state. Practitioners should treat full dependency visibility as a baseline control across build, release, and operations.
A question worth separating out:
Q: Who is accountable when a transitive dependency vulnerability reaches production?
A: Accountability should be shared but explicit: engineering owns the component graph, security defines policy and monitoring thresholds, and product or platform teams approve remediation priority. Frameworks such as the NIST Secure Software Development Framework and EU Cyber Resilience Act expectations make it clear that supply chain knowledge cannot be an afterthought.
👉 Read our full editorial: Transitive dependency blind spots are leaving most apps exposed
