How do you discover vulnerable libraries when the names developers use do not match the names in vulnerability databases? Jeremy Long, founder of OWASP Dependency-Check, explains the evidence-gathering and matching behind software composition analysis. He tells the project’s origin story, discusses accuracy and false positives, and describes how Dependency-Check fits alongside other dependency tools. The conversation explores delayed upgrades, automated update services, supply-chain integrity, and the limits of treating all vulnerabilities alike. Jeremy also explains how teams can begin with a local scan and move checks into their build pipelines. Along the way, he offers a maintainer’s perspective on a widely adopted open-source project and keeps one naming detail clear: it is Dependency-Check, not Dependency-Checker.
The Application Security Podcast is brought to you by Security Journey.
About Security Journey
Security Journey provides application security education for developers and everyone in the software development lifecycle.
→ Learn more about Security Journey
Connect with Jeremy Long:
→ Jeremy Long on GitHub
Mentioned in this episode:
→ OWASP Dependency-Check
→ OWASP Dependency-Track
→ National Vulnerability Database
→ Jenkins
Follow the Application Security Podcast:
➜ Home
➜ X
➜ LinkedIn
➜ YouTube
➜ Instagram
➜ Facebook
Chapters:
00:00 Dependency-Check with Jeremy Long
02:41 Jeremy’s path into security
06:38 The project’s origin story
09:43 How Dependency-Check identifies components
14:14 Turning component evidence into vulnerability findings
16:31 Accuracy and the limits of matching
19:49 Maintaining a widely used open-source project
21:25 Why available patches still go unapplied
26:28 Automated upgrades and the future of SCA
28:35 Build integrity and supply-chain security
31:17 Adoption and project reach
33:08 Local scans and build-pipeline integration
38:54 Dependency-Check, not Dependency-Checker
40:00 Jeremy’s final advice
