A direct dependency is a package that a project explicitly includes and uses. It sits at the first layer of the software bill of materials for an application, and it can introduce additional transitive packages beneath it. In AppSec, direct dependencies matter because they are often the control point for remediation.
Expanded Definition
A direct dependency is the software package, library, or module that an application explicitly declares and calls. In software composition analysis, it is the first visible layer of the dependency graph, while transitive dependencies sit beneath it and are pulled in indirectly. That distinction matters because remediation usually begins with the package the development team selected, pinned, or updated directly.
In application security, direct dependencies are easier to inventory than indirect ones, but they are not automatically safer. They can still introduce vulnerable transitive packages, unsafe build behaviour, or version conflicts that prevent timely patching. This makes them central to NIST Cybersecurity Framework 2.0 style governance, where software asset visibility and risk treatment depend on knowing what is actually in use.
The term is sometimes used loosely to mean “any dependency in the project,” but that collapses the difference between what the team chose and what the package manager resolved. The most common misapplication is treating a transitive package as a direct dependency, which occurs when teams review lock files without understanding which entries were explicitly declared versus indirectly introduced.
Examples and Use Cases
Implementing dependency management rigorously often introduces versioning and testing overhead, requiring organisations to weigh fast feature delivery against the cost of controlled upgrades.
- A Python service declares requests in its requirements file. That package is a direct dependency, even though it may pull in certifi and urllib3 as transitive dependencies.
- A Java application includes log4j through Maven. The explicitly referenced artifact is the direct dependency, and security teams focus remediation on that first because it is the easiest place to force a safe version.
- An npm project adds a crypto library directly for token signing. If a vulnerability emerges, the development team can patch the top-level entry without waiting for every downstream package to release a fix.
- A build pipeline imports an internal SDK used across multiple services. Even when the SDK is trusted, it remains a direct dependency and should be tracked in the software bill of materials, alongside guidance from sources such as the NIST Cybersecurity Framework 2.0.
Why It Matters for Security Teams
Security teams need to know which dependencies are direct because that is where policy enforcement, update cadence, and ownership are most practical. Direct dependencies define the control surface for dependency pinning, code review, and remediation workflows. If the team cannot identify them accurately, vulnerability reporting becomes noisy, patching slows down, and risk acceptance decisions lose credibility.
Direct dependency visibility also supports software supply chain assurance. Under NIST Cybersecurity Framework 2.0, organisations are expected to understand assets and manage exposures; direct dependencies are part of that inventory. They also shape how teams interpret guidance from the SLSA framework and OWASP Dependency-Track style tooling, because the remediation path is usually to the declared package rather than every transitive child. In identity-heavy platforms, a direct dependency can also carry authentication or secrets-handling logic, so a flawed update may affect access flows as well as application stability.
Organisations typically encounter the operational impact of direct dependencies only after a critical library advisory lands, at which point the declared package becomes the unavoidable entry point for containment and recovery.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack surface, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.SC | CSF 2.0 supply chain governance covers software component visibility and risk treatment. |
| NIST SP 800-53 Rev 5 | SA-12 | System and services acquisition supports controlled use of third-party software components. |
| ISO/IEC 27001:2022 | A.5.9 | Asset inventory practices extend to software components that must be identified and managed. |
| OWASP Non-Human Identity Top 10 | NHI systems often rely on libraries that handle credentials, tokens, and service-to-service trust. |
Track direct dependencies that process secrets or identity flows with the same rigor as NHI assets.
Related resources from NHI Mgmt Group
- What is the difference between direct access and effective access in Active Directory?
- What is the difference between IAM roles and direct API keys for AI workloads?
- What is the difference between direct account compromise and SaaS supply chain compromise?
- When does a dependency compromise become an identity incident?
