The Hidden Risk in Your Dependency Tree
Snyk's analysis of over one million open source projects revealed a significant supply chain issue: 78% of vulnerabilities exist in indirect dependencies—the packages your dependencies pull in, not the ones you explicitly chose. This structural weakness affects most modern software projects, highlighting a gap between how developers perceive their dependency footprint and where the actual risk resides.
The challenge is compounded by the fact that only one in three developers can remediate a high or critical-severity vulnerability within a day. When that vulnerability is buried three or four levels deep in your dependency tree, remediation timelines extend further as you wait for upstream maintainers to patch, release, and propagate fixes.
Awareness Timeline
This is a timeline of growing awareness:
2019: Snyk publishes findings showing 78% of vulnerabilities in indirect dependencies across one million scanned projects.
Ongoing: Development teams continue to add direct dependencies without visibility into the transitive tree those packages introduce. Vulnerability scanners flag issues in packages the team never explicitly installed. Remediation requires either waiting for upstream patches to cascade through multiple dependency layers or making architectural changes to eliminate the vulnerable chain entirely.
The pattern repeats across organizations: a critical CVE appears, the scanner identifies it in a package you've never heard of, and you discover it's pulled in through three intermediary dependencies. You can't patch it directly because you don't control the dependency relationship.
Missing or Failed Controls
Dependency visibility: Most teams track direct dependencies in their package.json, requirements.txt, or pom.xml files. They lack visibility into the full transitive graph. When a vulnerability appears in an indirect dependency, teams scramble to understand the relationship chain and impact scope.
Pre-commit dependency analysis: Teams that scan for vulnerabilities only in CI/CD or production environments discover issues after they've already merged code. By then, the vulnerable dependency is integrated into the application architecture.
Vendor security assessment for dependencies: You likely vet third-party services and commercial software but may not apply the same scrutiny to open source packages, especially those inherited indirectly. No one reviews the security posture of a logging library pulled in by your HTTP client.
Remediation ownership: When a direct dependency has a vulnerability, your team owns the upgrade. When an indirect dependency has a vulnerability, you're waiting for the maintainer of your direct dependency to upgrade their dependency and cut a new release, introducing delays you can't control.
Dependency pinning strategy: Some teams pin all versions for stability, while others use loose version ranges for automatic updates. Neither approach accounts for indirect dependencies—you might pin your direct dependencies but still pull in vulnerable indirect ones through version ranges in packages you don't control.
Relevant Standards and Requirements
PCI DSS v4.0.1 Requirement 6.3.2 mandates that you identify and address vulnerabilities using a risk-based approach. With 78% of your vulnerabilities hiding in indirect dependencies, you can't meet this requirement without visibility into your full dependency tree. The standard doesn't distinguish between direct and indirect dependencies—you're responsible for all code running in your cardholder data environment.
OWASP Top 10 A06:2021 – Vulnerable and Outdated Components directly addresses this risk. The guidance emphasizes knowing what you use, including all dependencies, and specifically calls out the difficulty of tracking transitive dependencies, recommending continuous inventory and monitoring.
NIST 800-53 Rev 5 Control SA-15 requires that you identify and document security flaws during development and testing. For indirect dependencies, this means scanning before merge and maintaining an accurate software bill of materials (SBOM) that includes the full dependency graph.
ISO 27001 Control 8.31 indirectly addresses this through environment isolation, but the control assumes you know what's running in each environment. Undocumented indirect dependencies undermine that assumption.
SOC 2 Type II Common Criteria CC7.1 requires that you identify, report, and act upon system changes and security incidents. A vulnerability in an indirect dependency is a security event requiring response—but you can't respond to what you can't see.
Actionable Steps for Your Team
Generate and maintain SBOMs: Use tools like syft, cyclonedx-cli, or your package manager's built-in SBOM generation to create a complete inventory of direct and indirect dependencies. Store these artifacts with each release. When a new CVE drops, you can quickly determine exposure across your application portfolio without running fresh scans.
Scan dependencies before merge, not just in CI/CD: Integrate dependency scanning into your pre-commit hooks or IDE. Tools like npm audit, pip-audit, or commercial SCA platforms can flag vulnerable dependencies before they enter your codebase. Catching issues at the developer workstation is faster and cheaper than catching them in CI/CD or production.
Set remediation SLAs based on dependency depth: A critical vulnerability in a direct dependency might have a 7-day SLA. The same severity in an indirect dependency needs a different approach—you might need to replace the direct dependency entirely if the maintainer doesn't respond. Document escalation paths for vulnerabilities you can't directly patch.
Evaluate direct dependencies by their dependency footprint: Before adding a new package, review what it pulls in. A lightweight HTTP client that introduces 40 transitive dependencies might be less secure than a slightly heavier library with 5 dependencies—or no dependencies at all. Make dependency count and depth part of your selection criteria.
Monitor upstream dependency activity: For critical direct dependencies, track the maintainer's responsiveness to security issues. If a package hasn't been updated in 18 months and has 15 open security issues, that's a signal to find alternatives before you're forced to during an incident.
Create fallback plans for unmaintained chains: When you identify an indirect dependency that's unmaintained or slow to patch, document alternatives now. Waiting until you have a critical CVE to research replacement options puts you in reactive mode.
Test dependency updates in isolation: When an indirect dependency updates to patch a vulnerability, test the full dependency chain before deploying. Updates can introduce breaking changes several layers deep. Your direct dependency might be compatible, but the integration between two indirect dependencies might break.
The 78% statistic isn't a prediction—it's the current state of your application portfolio. Your indirect dependencies are already there, introducing risk and subject to the same compliance requirements as the code you write. The question isn't whether to manage them, but how quickly you can gain visibility and control.
