How to Answer “What’s Affected?” in Open Source
summary
OSV converts messy CVE data into precise artifact-level ranges by adding Git-aware semantics to its minimal schema: version events introduced/last_affected/fixed, commit-level ranges, and support for introduced zero. The team uses commit hashes and patch-id to detect cherry-picks, enumerates all commits between tags or fixes, and applies a deterministic graph rule — a commit is affected only if there is a path from an introduced commit to it that does not pass through a fixed commit — feeding an OSV API that scanners, VEX, reachability, and static analysis consume.
AI-written summary · about
chapters (18)
- 0:00Introduction
- 0:26Vulnerability matching challenge
- 2:13CVE schema and NVD problems
- 3:17Open Source Vulnerability schema
- 4:21Ecosystem versioning rules
- 5:02Version ranges and LTS branches
- 7:50Git commits for tracking
- 8:32Edge cases in Git graphs
- 10:59Affected commits in merges
- 12:42Commit status resolution rules
- 14:05Zero in Git graphs
- 15:48OSV vulnerability data sources
- 17:54Version ranges from CVE
- 19:40Versions to Git tags
- 20:45Affected commits and versions
- 21:26Tooling and actionable data
- 22:28Precise vulnerability reports
- 23:15Q&A
related talks
41mScalable Management of Vulnerabilities in Open Source
24mLessons from OSV: Vulnerability Management for Open Source
31mVEX! or... How to Reduce CVE Noise With One Simple Trick!
36mAll you wanted to know about sw vulnerabilities…but were too busy to look into
55mLet’s Talk About Fitness for Purpose: Comparing and Contrasting the CVE List with OSV.dev
42mNavigating the Sea of CVEs: Securing Your Linux Distributions
39mFrom Discovery to Fix: What 10,000 Open Source Projects Reveal About CVE Remediation
37mGoverning Global Vulnerabilities: Standards for Open Source Resilience