From oss-security  Mon Jun 24 17:00:28 2019
From: "David A. Wheeler" <dwheeler () dwheeler ! com>
Date: Mon, 24 Jun 2019 17:00:28 +0000
To: oss-security
Subject: Re: [oss-security] Thousands of vulnerabilities, almost no CVEs: OSS-Fuzz
Message-Id: <E1hfSKS-00015J-V5 () rmmprod07 ! runbox>
X-MARC-Message: https://marc.info/?l=oss-security&m=156139565710502

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

On Mon, 24 Jun 2019 11:59:43 -0400 (EDT), "Stuart D. Gathman" <stuart@gathm=
an.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 a=
t least one
of the most serious vulnerabilities assigned a CVE so that people will upgr=
ade
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=