Transitive Dependency
A transitive dependency is an indirect dependency your software inherits through a direct dependency. Understanding them is critical for supply chain security, license compliance, and vulnerability management.
Last updated: March 24, 2026
What is a transitive dependency?
A transitive dependency is a dependency that your software project inherits indirectly. Rather than being declared explicitly in your project’s manifest (e.g. package.json, requirements.txt, or go.mod), it is pulled in because one of your direct dependencies depends on it.
For example, if your application depends on library A, and library A depends on library B, then library B is a transitive (or indirect) dependency of your application. This chain can extend multiple levels deep — library B might depend on library C, making C a second-level transitive dependency.
Why transitive dependencies matter
Modern software projects rely on a large number of open-source packages. A typical application may declare tens of direct dependencies but end up with hundreds or even thousands of transitive dependencies. This has important implications:
Security
Vulnerabilities in transitive dependencies are just as dangerous as those in direct dependencies. High-profile supply chain attacks — such as the event-stream incident in the npm ecosystem — have exploited transitive dependencies to inject malicious code into thousands of downstream projects. Because developers often have limited visibility into their transitive dependency tree, these vulnerabilities can go undetected for extended periods.
License compliance
Every transitive dependency carries its own license. A project that only audits direct dependencies may inadvertently include a transitively-imported package with an incompatible license (e.g. a copyleft license in a proprietary codebase). Automated license scanning tools should cover the full dependency tree, not just the top level.
Stability and maintenance
If a transitive dependency is abandoned, deprecated, or introduces a breaking change, it can cascade through the dependency chain and break your application — even if your direct dependencies remain unchanged. Pinning versions and using lock files helps mitigate this risk.
Direct vs. transitive dependencies
Direct dependencies are packages you explicitly add to your project. You control their version, you choose to include them, and you interact with their API directly.
Transitive dependencies are packages pulled in automatically by your direct dependencies (or by other transitive dependencies). You typically do not interact with them directly, but they are still compiled, bundled, and executed as part of your application.
How to manage transitive dependencies
Effective management of transitive dependencies involves several practices:
Use lock files (package-lock.json, yarn.lock, Pipfile.lock) to pin the exact versions of all dependencies, including transitive ones.
Run dependency audits regularly using tools like npm audit, Snyk, or Dependabot to catch known vulnerabilities in your full dependency tree.
Visualize the dependency tree using commands like npm ls, pipdeptree, or go mod graph to understand what your project actually depends on.
Minimize direct dependencies — each direct dependency adds its own transitive tree. Evaluate whether a dependency is truly needed before adding it.
Use Software Composition Analysis (SCA) tools to continuously monitor your full dependency graph for security, license, and quality risks.
Transitive dependencies and the EU Cyber Resilience Act
The EU Cyber Resilience Act (CRA) requires manufacturers of products with digital elements to ensure the security of their entire software supply chain. This explicitly includes transitive dependencies. Organizations must maintain an accurate Software Bill of Materials (SBOM) that lists all components — direct and transitive — and must have processes in place to identify and remediate vulnerabilities anywhere in the dependency tree.
Failure to account for transitive dependencies can result in non-compliance, as the CRA treats the entire dependency chain as within scope for vulnerability handling and reporting obligations.