CVE tracking

• users care how secure their systems are
• provide information to users on what commit ranges are useable
• would organisations contribute to the activity of mapping CVEs to git sha
• database users would probably be g.b.o. users too
• single http interface db (user and morph both talk to this)

Scale/uncertainty

• CVEs which affect core GNU etc libc, libpng - a few per month
• Mitre publishes a couple per day
• some 'vulnerabilities' are just bugs (not officially declared)
• some vulnerabilities can be addressed by workarounds, rather than updates

Requirements

• which shas are vulnerable to which cve
• what cves am i potentially vulnerable to given this set of definitions?
• for given project (or all projects) what commits are vulnerable to a given set of CVEs

• is this set of commits present in my definitions (am i vulnerable?)

• maybe fuzzy patch test (is fixed, but not necessarily by this specific patch)

• maybe try to get upstream fixers to notify in commit message FIXES CVE: foo?

  • but can't rely on this

• how to map upstream non-git to git commits? other vcs are a fact of life