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