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.
At a glance
What this is: This analysis examines the transitive dependency attack surface and shows that most organisations lack strong visibility into nested software components that materially shape application risk.
Why it matters: For IAM, PAM, NHI, and application security teams, the same governance problem appears whenever trust is granted to inherited components that are not continuously inventoried, verified, or remediated.
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.
- 84% of healthcare organisations cite legacy systems as their biggest supply chain risk.
👉 Read Kusari's analysis of transitive dependency visibility and supply chain risk
Context
The transitive dependency attack surface is the hidden layer of indirect software components that enter applications through libraries, frameworks, and build chains. Most teams can name their direct dependencies, but they cannot reliably see what those dependencies pull in, which leaves security decisions based on an incomplete asset picture. In application security, that is not just a tooling gap, it is a governance gap.
This matters because point-in-time scanning gives false confidence when nested packages can change after the last build, and because remediation effort grows sharply once issues are discovered late. The article's 28% visibility figure is a warning sign, and the same pattern shows up in identity programmes when inherited trust is treated as if it were continuously verified.
Healthcare and energy are especially exposed because legacy systems make nested components harder to map, which is typical rather than exceptional in large enterprise estates.
Key questions
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. That produces reactive patching, duplicate effort, and false confidence from partial SBOMs. The result is slower remediation and a supply chain programme that cannot prove coverage.
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. If defenders only track direct components, they can miss the code attackers are most likely to exploit. A dependency-aware inventory reduces that blind spot and gives teams a realistic view of what is actually present in production.
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. If vulnerability response times are falling and emergency triage is dropping, visibility is improving. If scans still trigger surprise incidents, the control is not mature enough.
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.
Technical breakdown
Why transitive dependencies escape standard SCA coverage
Software composition analysis usually starts with declared manifests such as package.json, pom.xml, or requirements.txt. That means it is strongest at identifying direct dependencies and weaker at governing the full dependency graph, especially when build-time resolution is the only visibility mechanism. A transitive dependency can be safe at one scan and vulnerable at the next if a nested package updates between releases. The control failure is not scanning itself, but assuming a scan is equivalent to continuous visibility.
Practical implication: treat SCA as one signal, then add continuous dependency monitoring across all build pipelines.
How SBOM completeness changes the risk picture
An SBOM that omits nested components is an inventory of preference, not of actual exposure. Full dependency graphs matter because provenance, versioning, and inheritance determine whether a vulnerable package is reachable in a running application or merely present in a tree. Reachability analysis helps narrow priority, but it only works if the organisation can first see the entire component chain. Without that, remediation becomes reactive and the organisation cannot prove supply chain due diligence.
Practical implication: generate SBOMs that include transitive components and verify provenance before using them for prioritisation.
Why visibility maturity predicts better remediation outcomes
The article links stronger transitive visibility with faster vulnerability response and fewer surprise incidents. That relationship is logical: organisations that map their dependency graph frequently can detect changes sooner, route fixes to the right owners, and avoid repeated triage cycles. In governance terms, visibility is a control multiplier because it improves both detection and decision quality. The deeper lesson is that dependency sprawl behaves like identity sprawl, where the hard part is not finding one object but maintaining trustworthy lifecycle control over many of them.
Practical implication: align dependency monitoring frequency with release velocity, not with quarterly reporting cycles.
NHI Mgmt Group analysis
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.
Transitive dependency sprawl creates a trust gap that looks a lot like identity sprawl. In identity programmes, unmanaged accounts and inherited privileges become dangerous because no one can explain who has access, why, or for how long. The same pattern appears here: inherited software components accumulate risk without clear ownership, lifecycle control, or continuous verification. That is why identity leaders should recognise software supply chain visibility as a cousin problem to NHI governance.
Continuous monitoring matters more than one-time resolution. Build-time dependency resolution is useful, but it does not answer the operational question of what changed after the last scan. The security model that works best is one where dependency state is observed continuously and prioritised with reachability and exploitation context. Organisations that still rely on periodic scans are accepting exposure windows they cannot defend.
Legacy estates are where transitive blind spots become persistent rather than episodic. Healthcare and energy environments show how opaque build chains, older platforms, and vendor-delivered code make nested dependency governance harder than in greenfield applications. That does not make the problem unique to those sectors, only more visible there. Practitioners should assume older estates need more manual verification and tighter supply chain controls, not less.
Transitive dependency visibility is the named concept this report should force into board conversations. The real issue is not simply dependency count, but whether the organisation can prove its full inherited attack surface at the speed of release. Once that question cannot be answered, compliance claims, remediation timelines, and developer productivity all degrade together. The practitioner conclusion is straightforward: if you cannot see the chain, you do not control the chain.
What this signals
The operational signal for practitioners is that dependency visibility should be treated like lifecycle visibility in identity programmes: if the inventory is stale, the control is already failing. Teams that manage secrets, workload identity, or service accounts can use the same governance instinct here, because inherited software components create a similar trust problem across build and runtime.
Dependency visibility debt: when organisations rely on periodic scans instead of continuous graph visibility, they accumulate remediation debt that eventually shows up as release friction, incident noise, and audit weakness. That debt becomes harder to pay down as legacy systems and multi-ecosystem builds expand, so the right response is to push inventory, monitoring, and ownership closer to the development workflow.
For practitioners
- 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.
- Define ownership for remediating inherited components Document who updates direct libraries, who validates nested package changes, and who approves workarounds when a transitive vulnerability cannot be patched immediately.
Key takeaways
- Transitive dependency visibility is the difference between knowing your software supply chain and only guessing at it.
- The article's 28% visibility figure shows that most organisations still make AppSec decisions with an incomplete dependency map.
- Continuous monitoring, complete SBOMs, and explicit ownership are the controls that turn inherited risk into governed risk.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack surface, NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0007 , Discovery; TA0010 , Exfiltration | Dependency blind spots affect discovery of vulnerable components and downstream impact. |
| NIST CSF 2.0 | PR.IP-1 | The article centres on secure development and supply chain inventory practices. |
| NIST SP 800-53 Rev 5 | CM-8 | CM-8 directly covers system component inventory, including software dependencies. |
| CIS Controls v8 | CIS-16 , Application Software Security | CIS-16 addresses secure development and dependency risk in application software. |
| ISO/IEC 27001:2022 | A.5.21 | Supplier relationships and ICT supply chain risk are central to this dependency problem. |
Map supply chain exposure to ATT&CK discovery and exfiltration tactics, then prioritise the components most likely to be abused.
Key terms
- Transitive Dependency: A transitive dependency is a package that your software uses indirectly through another library rather than calling it directly. These dependencies often hide in Java estates, which makes visibility and runtime validation necessary to understand what code is actually present and active.
- Software Bill of Materials: A software bill of materials is an inventory of the components and dependencies used in an application. It helps teams identify what they shipped, but it becomes most useful when paired with source verification, signature checks, and policy enforcement for third-party code.
- Reachability analysis: Reachability analysis checks whether a vulnerability can actually be exploited in the application’s real code paths and dependency graph. It helps teams distinguish theoretical findings from issues that an attacker can reach, which makes prioritisation far more accurate for both AppSec and identity risk management.
- Transitive Dependency Visibility: Transitive dependency visibility is the ability to identify, track, and continuously observe nested software components across the full dependency graph. It turns inherited code from an unknown into a governed asset, and it is a prerequisite for credible supply chain security decisions.
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.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect lifecycle control and access governance across identity-driven security programmes.
Published by the NHIMG editorial team on August 18, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
