Direct dependencies are packages a project explicitly declares and controls in its configuration files. Transitive dependencies are the packages those direct dependencies pull in automatically. The difference matters because direct dependencies are visible and easier to govern, while transitive dependencies can introduce security, compatibility, and compliance risk without being named in the project itself.
Why This Matters for Security Teams
Direct and transitive dependencies are not just a build-time concern. They shape the attack surface, patching effort, license exposure, and the confidence a team can place in software composition data. Security teams often focus on what developers intentionally added, but the more difficult risk often arrives several layers down the dependency tree, where version drift, abandoned packages, and hidden maintainers can undermine trust.
That is why software composition analysis, dependency policy, and build pipeline controls need to work together rather than as separate checks. NIST SP 800-53 Rev 5 Security and Privacy Controls is a useful reference point for supply chain, configuration management, and continuous monitoring expectations, especially when teams need to show how dependency risk is governed across development and release processes.
The practical issue is that transitive dependencies can change without a developer touching the top-level manifest, so a clean code review can still ship a weak component. In practice, many security teams encounter dependency exposure only after an upstream package changes or a vulnerability bulletin forces an emergency rebuild, rather than through intentional dependency governance.
How It Works in Practice
In secure software development, a direct dependency is one that appears in the project’s manifest, lockfile, or build definition. A transitive dependency is introduced because a direct dependency relies on it. That distinction affects how teams assess ownership, update cadence, and blast radius. A direct package can usually be pinned, reviewed, and replaced with relative clarity. A transitive package may be several layers deep, shared by multiple direct packages, or brought in through platform tooling that developers do not notice day to day.
Operationally, teams should treat dependency management as a control loop rather than a one-time inventory exercise. The goal is to know what is in the application, which layers are intentional, and which components require policy decisions. Good practice usually includes:
- Maintaining an accurate lockfile or equivalent artifact so builds are reproducible.
- Tracking both direct and transitive packages in software composition analysis outputs.
- Setting update rules for direct dependencies and exception handling for deep transitive trees.
- Reviewing high-risk packages for maintainer health, release frequency, and known vulnerability exposure.
- Connecting dependency data to CI/CD gates so risky changes are caught before release.
Where this becomes more important is in containerized builds, monorepos, and package ecosystems with dense trees of nested libraries. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls maps well to this problem because it reinforces controlled change, secure configuration, and monitoring across the pipeline. These controls tend to break down when build systems fetch floating versions or when multiple package managers are mixed in the same delivery path, because the resulting dependency graph becomes hard to reproduce and verify.
Common Variations and Edge Cases
Tighter dependency control often increases maintenance overhead, requiring organisations to balance faster delivery against stronger supply chain assurance. That tradeoff is especially visible when a team inherits a large codebase with dozens of indirect libraries that cannot be updated independently without breaking compatibility.
There is no universal standard for how deep a team must inspect every transitive dependency, so best practice is evolving. For critical software, many teams prioritize depth of visibility over depth of manual review: they accept that every nested package cannot be read line by line, but they still require a complete bill of materials, vulnerability alerting, and policy-based exceptions for risky components.
Two edge cases matter often. First, a dependency may be both direct and transitive in different parts of the build, which can complicate version resolution and vulnerability attribution. Second, generated artifacts and vendored code can hide dependency relationships from standard scanners, so teams need build-aware controls rather than reliance on a single inventory tool. The main operational lesson is that direct dependencies are the ones the team chooses, while transitive dependencies are the ones the ecosystem chooses on its behalf.
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 set the technical controls, and EU Cyber Resilience Act define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.SC | Dependency governance is a software supply chain risk management concern. |
| MITRE ATT&CK | T1195 | Software supply chain compromise often enters through third-party dependencies. |
| EU Cyber Resilience Act | Product security obligations increasingly require software component visibility. |
Maintain component inventories and update processes that support secure-by-design obligations.
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 secure-by-design development and retrofitting security onto AI-generated code?
- What is the difference between version pinning and tag management in secure software delivery?
- What is the difference between direct access and effective access in Active Directory?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 1, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
