Direct dependencies are the packages a team adds intentionally to a project. Transitive dependencies are the additional packages those direct dependencies pull in behind the scenes. Both matter for security and compliance, but transitive dependencies are often the larger blind spot because they expand the attack surface, licensing obligations, and maintenance burden without being chosen explicitly.
How direct and transitive dependencies differ in supply chain risk
Direct dependencies are the packages you intentionally add and expect to review. Transitive dependencies are the packages they bring in, often several layers deep, which can be harder to inventory, patch, and govern. The risk difference is not just count, it is visibility: direct dependencies are chosen on purpose, while transitive ones often become part of your attack surface without explicit approval.
That distinction matters because a dependency graph expands quickly. A small number of direct packages can hide a much larger set of indirect libraries, build tools, and runtime components, and those hidden layers can introduce vulnerable code, abandoned maintainers, conflicting licenses, or unexpected update paths. In practice, most teams need to treat the transitive tree as part of the software bill of materials, not as background noise.
Why transitive dependencies usually create the bigger blind spot
Transitive risk is larger because the team that consumes the software rarely owns the upstream release decisions for those nested packages. A direct dependency can usually be pinned, reviewed, or replaced deliberately. A transitive dependency may be introduced by a framework or plugin you trust, which means the exposure is inherited rather than selected. That is why supply chain incidents often land in the nested layers rather than in the obvious top-level package.
Operationally, the hidden depth is what makes the problem harder. Teams may know they use a package, but not know which lower-level packages are actually executing in CI, production, or developer tooling. The same applies to licensing and maintenance burden: obligations and patch work can arrive through a dependency you never intended to ship directly, yet you still inherit the responsibility to track it.
For broader supply chain context, SLSA is useful because it frames build provenance and artifact integrity, which are often the practical controls for reducing uncertainty across nested dependency chains. Likewise, NIST SSDF (SP 800-218) helps teams connect dependency selection to secure development practices rather than treating it as a one-time procurement choice.
What changes in practice when you manage both layers
Direct dependencies are the layer where teams make conscious choices, so they are best suited to policy enforcement, version pinning, and approval workflows. Transitive dependencies are the layer where teams need visibility, monitoring, and exception handling, because they are the most likely place for surprise exposure. A package can be safe today and become risky tomorrow through a nested update chain, even when the top-level dependency name has not changed.
The most useful mental model is that direct dependencies define your intentional software choices, while transitive dependencies define much of your inherited risk. That means the control objective is different for each layer: choose direct packages carefully, but continuously inventory and verify the full closure of nested packages. When nested packages are treated as outside scope, teams miss the place where adversaries, abandoned code, and licensing surprises are most likely to appear.
External guidance such as the NIST Cybersecurity Framework 2.0 supports this distinction by encouraging governance, identification, and protection activities that extend beyond first-order assets. For software teams, OpenSSF is also relevant because it provides supply chain security guidance that helps teams inspect and harden the broader open source ecosystem they consume.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
SLSA, NIST SP 800-53 Rev 5, OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply chain provenance and integrity | Directly applies to nested artifact trust and build provenance in dependency chains. |
| Recommendation — Verify artifact provenance and restrict untrusted dependency paths. | ||
| NIST SP 800-53 Rev 5 | SA-12 — Supply Chain Protection | Addresses supplier and component risk that arises through direct and transitive software dependencies. |
| CM-8 — System Component Inventory | A complete dependency view requires inventorying shipped components, including transitive ones. | |
| Recommendation — Apply SA-12 to manage component provenance and supplier risk. Maintain an accurate component inventory that includes transitive packages. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Dependency choice and verification are part of secure application architecture and build hygiene. |
| Recommendation — Review dependency inclusion and update practices during secure design and review. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Covers software supply chain practices, including review and control of third-party components. |
| Recommendation — Assess third-party components and enforce software supply chain safeguards. | ||
Practitioner Guidance
What to prioritise: Build two inventories, one for the direct packages you approve and one for the full transitive closure that actually ships. If you only track the first layer, you will understate both security exposure and compliance work.
What to verify: For every critical build or runtime artifact, verify that you can answer three questions quickly: what was chosen intentionally, what arrived transitively, and which of those transitive packages are pinned, monitored, or exceptioned. If you cannot produce that view, the dependency process is not yet operationally mature.
Common mistake: Treating a top-level package review as equivalent to supply chain review. That shortcut misses the nested packages that usually drive the largest blast radius when a maintainer disappears, a version is compromised, or a license obligation changes unexpectedly.
Practitioner takeaway: Direct dependencies are the governance layer, but transitive dependencies are usually the exposure layer, so mature software supply chain risk management has to control both.
Related resources from NHI Mgmt Group
- Why do transitive dependencies create more software supply chain risk than direct packages alone?
- What is the difference between software supply chain risk and NHI risk?
- What is the difference between direct and transitive dependencies in secure software development?
- What is the difference between treating software supply chain risk like internal code risk and treating it as a separate control problem?
