When is a vulnerability not a vulnerability? Overcoming the...
summary
Claims that a pragmatic SCA program can ignore over 90% of alerts by using reachability analysis to surface only code paths that call vulnerable functions. Implementation uses static analysis (semgrep, grep, linters, CodeQL), a vulnerability DB (NVD/OSV), and authored reachability rules; example: a PyTorch disclosure led to a rule that scans repos and enforces PR guardrails. Measured result: roughly 2% of reported vulnerabilities are reachable, reducing triage from ~1000→10→5; not foolproof—critical ones like log4j still require full removal.
AI-written summary · about
chapters (10)
- 0:00Introduction to talk
- 1:03Problem with security alerts
- 2:06Rise of open source software
- 4:53How traditional SCA tools work
- 7:43Challenges of upgrading dependencies
- 10:10What is reachability analysis
- 13:42Implementing reachability analysis
- 15:30Handling new disclosures and commits
- 17:58Benefits of reachability programs
- 19:22Conclusion and Q&A
related talks
54mOvercoming The Inundation Of Noisy Security Alerts
38mEffective Usage Analysis: Boosting Developer Productivity Via Innovative, Noise-reduced Vulnerability Analysis
23mPrioritisation of SCA Findings in Software Dependencies Using Static Reachability Analysis
56mNarrow – SCA Reachability Analysis Without The Effort
01h 06mEscaping Vulnerability Hell: Bridging the Gap Between Developers and Security Teams
49mOpen-source vulnerability management? Use the source, Luke!
45mEradicating Vulnerability Classes by Shelving SAST and Embracing Secure Defaults and Invariants
23mStopping vulnerabilities at the source