Title: What about something like letsencrypt and ACME, but for bugs?
Date: 2020-05-13 23:45

Before [Let's encrypt](https://letsencrypt.org/), around 30% of the web
requests done by firefox were encrypted, now it's around 80-90%. The main
reason behind this change is of course that *Let's encrypt* issues certificates for
free. But there is an other important related change: not only is the web now encrypted,
but certificates are automatically rotated, thanks to the [ACME](
https://en.wikipedia.org/wiki/Automated_Certificate_Management_Environment )
protocol. So it's both openly specified, with an API, and it's free.

And now, on a completely unrelated topic: semi-public/public bug producing machineries:

- Google's [OSS-Fuzz](https://github.com/google/oss-fuzz) and [Syzkaller](https://syzkaller.appspot.com/upstream)
- [Fuzzit](https://fuzzit.dev/), an Israeli startup 
- [FuzzBuzz]( https://fuzzbuzz.io/ ), an US startup 
- Entities relying on open-source, like [fastly]( https://www.fastly.com/blog/how-fuzz-server-american-fuzzy-lop )
- Entities producing  code, like [Mozilla]( https://blog.mozilla.org/security/2019/07/10/grizzly/ )
  or [Microsoft]( https://www.microsoft.com/security/blog/2020/05/04/mitigating-vulnerabilities-endpoint-network-stacks/ )
- Universities like [TU Darmstadt](https://www.gosecure.net/blog/2019/07/30/fuzzing-closed-source-pdf-viewers/),
  the [EPFL](https://hexhive.epfl.ch/epflprojects/ ), … and their students,
  either as part of their research or curriculum.
- Code forges, like [github](https://securitylab.github.com/disclosures ) and
  their [CodeQL](https://securitylab.github.com/tools/codeql) magic, or
  [gitlab]( https://about.gitlab.com/solutions/dev-sec-ops/ ) and others
- Individual and companies, for fame, PR purpose, technical excellence, …, like
  [Checkpoint]( https://research.checkpoint.com/2018/50-adobe-cves-in-50-days/),
  [Collabora](https://www.collabora.com/news-and-blog/blog/2020/05/12/using-syzkaller-fuzzing-your-changes/), …

If you've fuzzed at scale, you know that it's usually way easier to find crashes than to get them fixed,
and if you're an user, you know that it's easier to get the latest version than to find to what crashes
your current installed one is vulnerable.

Wouldn't it be neat to have a standardized protocol to ask various "*fuzzing
authorities*" if a given [CPE](https://en.wikipedia.org/wiki/Common_Platform_Enumeration) is prone to (known) crashes,
what is the mean time between the discovery of crashing input and a fix,
how many crashes were found this month by how many CPU, what is the
usual severity/type of crash, … and if the fateful 90-days deadline is passed, being able to get the reproducers?

I know that some people are already crawling bugtrackers and grepping [VCS](
https://en.wikipedia.org/wiki/Version_control ), either to find juicy 1-days,
or to shove into some pricey *intelligence feed*. But as a user, I think it
would be fantastic if I could with a simple query have all those information,
before deciding to deploy a particular software.

Maybe something a bit like
- the [Core Infrastructure Best practise program](
https://www.coreinfrastructure.org/programs/best-practices-program/ ), but
useful.
- CVE, but for every single crash
- [debsecan]( https://wiki.debian.org/DebianSecurity/debsecan ) but not only for Debian packages