🔍 What’s Really in Your Dependencies?

Open source is everywhere—and that’s the problem. The average modern application has hundreds of third-party dependencies, many of which bring their own risks. While open source enables faster development, community innovation, and transparency, it also introduces blind spots, especially in transitive dependencies you didn’t explicitly choose.

This post explores how open source dependency risk arises, how real-world breaches exploit it, and how to manage it through tooling, policy, and secure build practices.

🔗 Direct vs. Transitive Dependencies

Direct dependencies are the libraries you explicitly declare in your codebase (e.g., in package.json or requirements.txt). Transitive dependencies—often far more numerous—are the dependencies of your dependencies. These are pulled in automatically and can number in the hundreds or thousands.

Transitive dependencies are especially dangerous because:

• They often escape regular code review.
• They can be quietly deprecated or hijacked (e.g., event-stream in NPM).
• They are more likely to include unmaintained or unvetted code.

In major ecosystems like NPM and PyPI, a single top-level library may bring in 50+ transitive packages with no centralized security vetting.

📉 Real-World Incidents

Open source dependency attacks are not hypothetical. Here are notable cases:

• event-stream (NPM): An abandoned maintainer handed control to an attacker who inserted malicious code targeting cryptocurrency wallets.
• UAParser.js: A popular library was hijacked and used to deploy cryptocurrency miners and credential stealers.
• Color.js / Faker.js: A disgruntled maintainer deliberately corrupted the library, affecting thousands of downstream applications.
• PyTorch-nightly: Attackers uploaded a malicious torchtriton package to PyPI that exfiltrated sensitive system info on install.

These cases highlight two key risks: package takeover and ecosystem-level trust failures.

🛠️ How to Manage Dependency Risk

Managing dependency risk requires both process discipline and tooling integration. Here’s how to start:

1. Use Software Composition Analysis (SCA)

Tools like OWASP Dependency-Check, Snyk, Dependabot, Renovate, and Anchore scan your projects for known vulnerabilities and out-of-date packages. They surface CVEs and license issues.

2. Monitor for Known Exploits

Integrate feeds from:

• NIST NVD (National Vulnerability Database)
• Google’s OSV Database
• GitHub Security Advisories

3. Enforce Dependency Policies

Use automated workflows to:

• Block known-bad packages (denylists)
• Set version pinning to prevent silent upgrades
• Flag or block packages without recent updates or security reviews

4. Scan Transitives Separately

Make sure your tools go beyond top-level packages. If your SCA isn’t scanning everything in the dependency tree, you’re missing the majority of your attack surface.

5. Run Builds in a Secure Sandbox

Prevent installation-time attacks (e.g., malicious install scripts) by running builds in hardened containers or ephemeral environments—never on developer laptops.

📋 Governance Tips for Open Source Use

Technical controls aren’t enough. You also need policy and governance:

• Define an approved package list or vetting process for new dependencies
• Assign responsibility for dependency reviews (e.g., during code review or release gates)
• Establish response plans for dependency-driven vulnerabilities (e.g., Log4Shell-like CVEs)
• Keep a record of historical SBOMs for released versions (see upcoming Post 2)

📣 Final Thought

Dependencies are software you didn’t write, can’t fully trust, and often don’t control. But you’re still responsible for the risk. By treating open source packages as part of your attack surface—rather than assuming “free” means “safe”—you can reduce exposure and respond quickly when threats emerge.

Need help auditing your open source risk or integrating SCA and SBOM tools into your pipeline? Let’s talk.