What is a transitive dependency and why someone else's dependency can still break your project

Hook

When you add a package to a project, it is easy to think about it as a single, isolated dependency. In reality, most modern packages pull in other packages too. Those nested packages are called transitive dependencies.

In plain language, they are the dependencies of your dependencies. You did not add them directly, but your code still depends on them.

A simple example

Imagine you install library A. It uses library B, and B uses library C.

• A is a direct dependency of your project.
• B and C are transitive dependencies.

If a vulnerability appears in C, it can still reach your application even if you never touched C yourself.

Where you see this in practice

Transitive dependencies matter in several common workflows:

• package managers, where dependency trees grow automatically;
• SBOM generation, where you want a complete component inventory;
• SCA scanners, which check for vulnerabilities beyond top-level packages;
• CI pipelines, where lockfiles pin versions but do not remove nested risk.

Why it matters

Beginners often inspect only the packages they explicitly installed. That gives a false sense of control. The real risk may live two or three levels deeper in the tree.

That is why transitive dependency is not just jargon. It is a core concept in software supply-chain security.

Common mistakes

• Looking only at top-level dependencies.
• Assuming a lockfile automatically makes the system safe.
• Ignoring version changes in nested packages.
• Not checking whether the scanner covers every level of the tree.
• Forgetting that one popular library can pull in many others.

Quick checklist

• Review the full dependency tree, not just the top level.
• Check whether your SCA tool can see nested packages.
• Confirm that the lockfile is actually used in CI.
• Look at whether critical packages drag in unnecessary dependency chains.
• Treat indirect dependencies as part of your risk review.

Bottom line

A transitive dependency is a dependency you did not add manually, but it can still affect your project. If you want real control over risk, you need to look beyond the packages you installed yourself and inspect the whole chain.