AI
The Case for a Dedicated Open Source Top 10
The main OWASP Top 10 addresses open source risk through a single entry, A06. After talking with 20 CISOs, the project team concluded that entry misses too much detail. Studies on the Census 2 Java project set found 80 to 85% of code came from open source dependencies. At that scale, one line item is not enough. The dedicated top 10 breaks the risk into categories: known vulnerabilities, compromised packages, unmaintained software, dependency tracking failures, and sizing mismatches. Each carries distinct mitigations.
Call Graph Analysis for Vulnerability Reachability
Most SCA tools flag vulnerabilities at the package level. A package with 1,000 functions may contain exactly one vulnerable function. If your code never calls that function, your actual exposure is lower. Call graph analysis maps function-to-function invocations from your application down through every dependency. Given that path, you can determine whether a CVE’s vulnerable function is reachable from your code. If it isn’t, you can deprioritize the fix. The catch: building this requires a database of vulnerable functions, which NVD and OSV often don’t provide at that granularity.
Supply Chain Compromise and Abandoned Software
A legitimate package becomes a vector when someone injects malicious code into it. The attack surface for open source maintainers mirrors an enterprise: phishing, credential theft, social engineering, or simple abandonment where a new owner takes over. Version pinning and lock files block automatic upgrades to compromised releases. Digest verification confirms downloads match expected hashes. The unmaintained variant is quieter: code keeps working until a vulnerability surfaces and no one fixes it. The Gorilla web toolkit declared maintenance abandoned publicly; most projects don’t give that warning.
Phantom and Mis-Sized Dependencies
Knowing which dependencies you actually use is harder than it sounds. Dynamic imports decide at runtime which package to load, so they won’t appear in any manifest. Rebundled binaries, common in Python packages that include compiled C code, hide third-party components from most scanners. On the sizing side: npm libraries that do one thing expose you to full supply chain risk for code you could write in 15 lines. Oversized libraries carry transitive dependencies you never need. Tooling for sizing trade-offs is still early-stage.
Q&A
What tools exist for analyzing whether a dependency is over- or under-used? Call graph tools can show a dependency has 300 functions but your code uses only 20, giving a rough metric, but no mature tool fully captures the sizing trade-off yet. ▶ Watch (23:44)
Notable Quotes
from my code to the vulnerable function George Apostolopoulos · ▶ Watch (7:41)
an popular open source is like an Enterprise attack right so all the attack vectors you can think attacking Enterprise apply to individuals right George Apostolopoulos · ▶ Watch (10:59)
because I get a lot of risk for 10 lines George Apostolopoulos · ▶ Watch (18:51)
Key Takeaways
- 80 to 85% of Java project code comes from open source dependencies, making supply chain risk unavoidable.
- Call graph analysis lets you confirm whether a vulnerable function is actually reachable from your code before prioritizing a fix.
- Version pinning and lock files are the first line of defense against automated updates that pull in compromised releases.
About the Speaker(s)
George Apostolopoulos is a computer science professional with over two decades of experience, specializing in the intersections of cybersecurity and machine learning. He is a member of the technical staff at Endor Labs, focusing on analytics and applications of AI to software.