Transitive dependencies security is one of the most misunderstood parts of modern software supply chain risk. Developers usually know their direct dependencies because they appear in files like package.json, pom.xml, composer.json, requirements.txt, or .csproj. But every direct dependency can bring its own dependencies, and those dependencies can bring more dependencies. These hidden packages are called transitive dependencies, indirect dependencies, or nested dependencies.
The problem is simple: attackers do not care whether a vulnerable package was installed directly or indirectly. If it runs in your production environment and exposes a vulnerable code path, it can create risk. This guide explains what transitive dependencies are, why vulnerabilities often hide there, how Log4Shell exposed the problem, why lock files matter, how to force-upgrade indirect packages, and how Vulert helps teams scan all dependencies, including the ones hidden deep in the tree.
What Are Transitive Dependencies?
Transitive dependencies are packages that your application receives because another package depends on them. A direct dependency is the package your team explicitly adds. A transitive dependency is pulled in automatically. For example, if you install express in a Node.js application, your package.json may only show Express. But Express depends on packages such as body-parser, qs, accepts, mime-types, and others. Those packages become part of your application even though you did not manually choose them.
Here is a simplified example:
npm install express@4.18.0
Your package.json may show only this:
{
"dependencies": {
"express": "^4.18.0"
}
}
But your actual dependency tree may include this:
your-app
└── express@4.18.0
├── body-parser
│ └── qs
├── accepts
│ └── mime-types
└── cookie
The shopping list analogy makes this easier. package.json is like your shopping list. It shows what you asked for. package-lock.json is like the full ingredient label. It shows what actually ended up in the food. Checking only the shopping list for allergens is not enough because the hidden ingredients may be the problem. In dependency security, the hidden ingredients are transitive packages.
A real-world example is qs. Your team may not install qs directly, but it can enter your application through a web framework or middleware package. If a vulnerable version is resolved, your application may be exposed even though no developer ever typed npm install qs. This is the core challenge of transitive dependencies security: the packages you did not choose can still become your responsibility.
Why Most Vulnerabilities Live in Transitive Dependencies
Modern applications depend on large dependency trees. A small web API can have hundreds of packages after installation. A Java service can pull in dozens of Maven artifacts from a few direct dependencies. A Python project may import a framework and receive a chain of helper libraries. A .NET application may reference a high-level SDK that brings JSON, HTTP, logging, and authentication packages underneath. This is normal software development, but it creates hidden risk.
Recent dependency research shows how serious the problem can be. A 2025 Maven ecosystem study found that vulnerabilities impacted 31.39% of latest releases through direct dependencies and 62.89% through transitive dependencies. That does not mean every ecosystem has the same percentage, but it clearly shows that indirect dependencies can represent a larger exposure path than direct packages.
In one large Maven ecosystem study, transitive dependencies exposed more latest releases to vulnerabilities than direct dependencies.
Developers naturally focus on direct dependencies because those are visible in project files and pull requests. Attackers focus on whatever is exploitable. That mismatch creates a blind spot. If your team reviews only direct packages, you may miss vulnerabilities in packages that are still shipped, loaded, and executed in production.
Transitive vulnerabilities also persist because ownership is unclear. When a direct package is vulnerable, the developer knows what to update. When an indirect package is vulnerable, the team must find which parent dependency introduced it, whether a parent update exists, whether an override is safe, and whether multiple dependency paths include different versions. This extra complexity delays remediation and increases the chance that the issue remains unresolved.
Log4Shell — The Defining Transitive Dependency Vulnerability
Log4Shell, tracked as CVE-2021-44228, became the defining example of hidden dependency risk. The vulnerability affected Apache Log4j, a widely used Java logging library, and allowed remote code execution in vulnerable applications. Its severity, broad reach, and exploitation activity made it one of the most important software supply chain incidents in modern history.
For many organizations, the hardest part was not understanding that Log4j was dangerous. The hardest part was finding where Log4j existed. Many teams did not add Log4j directly. It arrived through frameworks, application servers, logging bridges, enterprise libraries, vendor products, internal platforms, and nested dependency chains. Some organizations spent days or weeks discovering whether they were affected because they lacked complete dependency visibility.
Log4Shell exposed the weakness of manual dependency tracking. A team might search pom.xml files and find no direct Log4j reference, then assume they are safe. But the vulnerable library could still exist in a shaded JAR, transitive Maven dependency, vendor application, container image, or bundled component. This is why transitive dependencies security is not a theoretical topic. It decides whether teams can respond quickly during real emergencies.
The long tail of Log4Shell also shows why patch availability does not equal risk reduction. Even years after fixes were available, outdated Log4j versions remained in use across many environments. This persistence often comes from dependency sprawl, legacy systems, compatibility concerns, and poor visibility into nested components.
Why Transitive Dependencies Are Harder to Manage Than Direct Ones
Direct dependencies are relatively simple to manage. They appear in project files, have clear owners, and can often be updated with one command. Transitive dependencies are harder because they sit below the packages your team selected. They may not appear in package.json, pom.xml, or .csproj. Instead, they appear in lock files, dependency trees, resolved build output, SBOMs, or package manager metadata.
The first challenge is visibility. A developer may not know a package exists until a scanner reports it. The second challenge is control. You usually cannot update a transitive dependency directly without either upgrading the parent package or applying an override. The third challenge is compatibility. A parent package may depend on a specific version range because newer versions break expected behavior. Forcing a newer transitive version can fix the vulnerability but create runtime bugs.
There can also be multiple versions of the same dependency at different depths. A Node.js project may include two versions of a package because different parents require different ranges. A Java project may resolve conflicts through Maven’s dependency mediation rules. A Gradle project may select one version based on resolution strategy. This means “update the vulnerable package” is not always a one-step fix.
- Hidden location: Transitive dependencies often appear in lock files or dependency trees rather than top-level project manifests.
- Indirect ownership: The vulnerable package may be introduced by a parent dependency owned by another team or vendor.
- Upgrade complexity: Fixing an indirect package often requires updating the parent package or forcing an override.
- Multiple paths: The same vulnerable package may appear through several dependency paths at different versions.
- Compatibility risk: Overrides can fix security issues but may break packages that expected older behavior.
The Lock File Is the Truth — Why You Must Scan It
Lock files record the exact dependency versions installed or resolved by your package manager. For Node.js, package.json shows what you asked for, while package-lock.json shows the exact generated dependency tree. npm’s documentation describes package-lock.json as a file that describes the exact tree that was generated so later installs can produce identical trees.
This distinction matters for security. A package manifest often contains version ranges. For example, "express": "^4.18.0" allows compatible versions based on semantic versioning rules. The lock file records the exact version selected and the exact versions of all nested packages. If your scanner checks only the manifest, it may miss the resolved transitive packages that actually run.
Compare the difference:
{
"dependencies": {
"express": "^4.18.0"
}
}
The manifest above shows one package. The lock file may show hundreds of packages:
{
"packages": {
"node_modules/express": {
"version": "4.18.0"
},
"node_modules/qs": {
"version": "6.10.3"
},
"node_modules/body-parser": {
"version": "1.20.0"
}
}
}
Scanning only the first file is like checking a restaurant menu while ignoring the ingredient list. A good Software Composition Analysis workflow should scan lock files whenever available: package-lock.json, yarn.lock, composer.lock, Gemfile.lock, go.sum, Cargo.lock, packages.lock.json, and similar files. Vulert supports these lock files and can identify vulnerabilities across direct and transitive dependencies.
Warning: If your scanner checks only direct dependencies, it can miss the vulnerable package that actually reaches production through a nested path.
How to Force-Upgrade a Transitive Dependency
Sometimes the best fix is to upgrade the parent package that introduced the vulnerable dependency. That keeps compatibility responsibility with the package maintainer. But in emergencies, teams may need to force a specific version of a transitive dependency before the parent package releases an update. Package managers provide mechanisms for this, but they should be used carefully.
Overrides are powerful because they let you replace a vulnerable nested package with a fixed version. They are risky because the parent package may not have been tested against that version. After applying an override, run the full test suite, check application behavior, and monitor production carefully after deployment. Treat overrides as tactical fixes, not permanent dependency management strategy.
npm / Node.js — Using Overrides
In npm, you can use overrides in package.json to force a transitive package version. For example, if a vulnerable qs version appears under a parent package, you can force a safer version:
{
"dependencies": {
"express": "^4.18.0"
},
"overrides": {
"qs": "6.11.0"
}
}
After changing overrides, reinstall and test:
npm install
npm test
npm ls qs
Maven — Using dependencyManagement
In Maven, dependencyManagement can control versions used by transitive dependencies. For example, if a vulnerable transitive version of Log4j is present, you can force a safer version:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
<version>2.23.1</version>
</dependency>
</dependencies>
</dependencyManagement>
Then inspect the dependency tree:
mvn dependency:tree -Dincludes=org.apache.logging.log4j
Gradle — Using resolutionStrategy
In Gradle, resolutionStrategy can force a dependency version across configurations. This can be useful when a vulnerable transitive dependency must be replaced quickly:
configurations.all {
resolutionStrategy {
force "org.apache.logging.log4j:log4j-core:2.23.1"
}
}
Then verify the resolved dependencies:
./gradlew dependencies --configuration runtimeClasspath
Tip: Prefer upgrading the parent dependency first. Use overrides when the parent fix is unavailable or too slow for the risk level.
How to See Your Full Transitive Dependency Tree
Before you can fix hidden dependencies, you need to see them. Every major ecosystem provides commands to inspect the full dependency tree. These commands help developers answer three practical questions: Which package introduced the vulnerable dependency? How many versions exist? Which update path is safest?
For npm, use:
npm ls
To inspect one package:
npm ls qs
For Maven, use:
mvn dependency:tree
To inspect a specific group or artifact:
mvn dependency:tree -Dincludes=org.apache.logging.log4j
For Python, install and use pipdeptree:
pip install pipdeptree
pipdeptree
For Gradle, use:
./gradlew dependencies
These commands are useful during incident response, but they are not enough by themselves. Developers need to run them manually, interpret results, and repeat the process across repositories. For continuous visibility, use SCA tools that scan lock files and SBOMs automatically, store vulnerability history, and alert teams when new issues affect existing dependencies.
How SCA Tools Handle Transitive Dependencies
Software Composition Analysis tools identify open-source components and match them against vulnerability databases. The quality of the result depends heavily on what files the tool scans and how deeply it understands dependency resolution. A basic tool that scans only direct dependencies may be fast, but it can miss the real exposure. A stronger tool scans lock files or SBOMs and includes transitive packages with exact versions.
The difference matters enormously. A direct-only scan might report that express is fine. A lock-file scan might reveal that a nested version of qs is vulnerable. A direct-only scan might find no Log4j reference in your pom.xml. A full dependency graph scan might reveal Log4j through a framework, bridge, or vendor package. In security operations, that difference can decide whether a team patches quickly or remains exposed.
Vulert analyzes manifest files and SBOMs to detect known vulnerabilities across all dependencies, including transitive ones. It supports lock files such as package-lock.json, yarn.lock, composer.lock, go.sum, Gemfile.lock, Cargo.lock, packages.lock.json, and SBOM formats such as SPDX and CycloneDX. Teams can upload a file and receive results in about 60 seconds without sharing source code.
This is especially useful for 10–100 person engineering teams that need practical visibility without building a full security research process. Vulert provides fix guidance, exact versions to upgrade to, CLI commands where available, Dependency Health grouping, Jira integration, and vulnerability history reports for audits.
Key Takeaways
- Transitive dependencies are hidden but real: They may not appear in your top-level manifest, but they still run in your application and can introduce vulnerabilities.
- Direct-only scanning is not enough: Many vulnerabilities appear in indirect packages pulled in by frameworks, SDKs, plugins, or middleware.
- Log4Shell proved the risk: Many organizations struggled because Log4j was often buried deep inside dependency trees and vendor software.
-
Lock files are the source of truth: Files like
package-lock.json,composer.lock, andpackages.lock.jsonshow exact resolved versions. - Overrides are useful but risky: Force-upgrading a nested dependency can reduce urgent risk, but teams must test compatibility carefully.
- Vulert scans transitive dependencies: Upload lock files or SBOMs to detect vulnerable direct and indirect dependencies without sharing source code.
Frequently Asked Questions
1. How many transitive dependencies does a typical app have?
The number varies by ecosystem and project size. A small Node.js or Java project can easily have dozens or hundreds of transitive dependencies after installing only a few direct packages. The safest approach is to inspect the lock file or dependency tree instead of guessing.
2. How do I upgrade a transitive dependency I didn’t install?
First, identify the parent package that introduced it using commands like npm ls, mvn dependency:tree, or ./gradlew dependencies. Then upgrade the parent package if possible. If no parent fix exists, use overrides, dependency management, or resolution strategies carefully and test thoroughly.
3. Does Vulert scan transitive dependencies?
Yes. Vulert scans manifest files, lock files, and SBOMs to detect vulnerabilities across direct and transitive dependencies. This helps teams find hidden packages that are not visible in top-level manifests.
