Quantifying the Probability of Flaws in Open Source
summary
Analysis covers 30,000 GitHub projects used in enterprise apps, compares them to OpenSSF’s 1.2M repo database and finds only 48,000 overlap. Real app scans show 79% never updated a library; Java shows ~7% of libraries with known flaws and JavaScript pulls ~10× transitive deps. Remediation half‑life ranges ~237 days (low‑score) to ~168 days (high‑score), and about 36% vs 52% of flaws remain open at one year depending on OpenSSF score presence. OSV is used for vuln counts and BigQuery exports drop large portions of scorecard data.
AI-written summary · about
chapters (17)
- 0:00Open source security risks
- 1:46How developers select open source libraries
- 3:10Library update reality
- 4:38Known vulnerabilities focus
- 8:13Vulnerability data sources
- 10:22OpenSSF security scoring
- 13:32Used vs unused libraries
- 15:00Project activity vs security scores
- 17:50Remediation time for flaws
- 21:47OpenSSF scoring factors
- 27:24OpenSSF data collection challenges
- 30:32OpenSSF scoring metrics
- 34:05Project maintenance by language
- 37:44Vulnerability in dependencies
- 40:12Developer diversity in projects
- 41:18Factors in vulnerability modeling
- 47:03Key takeaways for devs
related talks
40mNurture vs. Nature in AppSec: Data-Driven Measurement of DevSecOps
42mAssessing the Risk of Open-source Components Using OpenSSF's Scorecard
25mHow do you trust your open source software?
32mExemplars, Laggards, and Hoarders: A Data-driven Look at Open Source Software Supply Chains
14mThe State of Open Source Vulnerabilities Management in 2019
44mSecuring Open Source Software - End-to-End, at Massive Scale, Together
37mOpenSSF Best Practices for Everyone!
36mEstimating Security Risk Through Repository Mining