Re: Thousands of vulnerabilities, almost no CVEs: OSS-Fuzz

["David A. Wheeler" <dwheeler () dwheeler com>]

> On Mon, 24 Jun 2019, Bob Friesenhahn wrote:
> > Most oss-fuzz issue detections are not CVE worthy.  For example, a one-byte 
> > read "heap overflow" is not likely to cause any actual harm but oss-fuzz 
> > would classify it as "heap overflow".

On Mon, 24 Jun 2019 11:59:43 -0400 (EDT), "Stuart D. Gathman" <stuart () gathman org> wrote:
> Nevertheless, it is a bug.  Fuzzers are amazing.  Going forward, the
> best plan is for more projects to include fuzzing as part of the
> build process testing.

It is a bug, fuzzers are amazing, and more projects should include fuzzing.

But CVEs are supposed to only be assigned to vulnerabilities or exposures.
Many bugs are not vulnerabilities or exposures that lead to vulnerabilities.

If a bug *is* a vulnerability, then yes, it should have a CVE assignment,
and there are clearly a lot of vulnerabilities without CVE assignments.

In particular, many organizations have a rapid upgrade process
if some software version has a CVE, and a slow process otherwise.
(There are things that need doing besides upgrading software.)
If a particular version of software has a serious vulnerability, it needs at least one
of the most serious vulnerabilities assigned a CVE so that people will upgrade
it more rapidly.  In the end, the goal should be to get software fixed
*and* deployed - if it's not deployed when it needs to be, it didn't help.
Downstream needs to do their part by being prepared to upgrade... but
suppliers need to make it clear why something needs to be upgraded quickly
(if that's the case) so that the faster process will be used.
We should be focusing on the "final impact", that is,
we should be trying to reduce the cases where an attacker can exploit
a known vulnerability in deployed software... *without* breaking the bank.

--- David A. Wheeler