[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Convergence vs. multiple data entries

So we will have situations where a CVE is issued with some data (at a
minimum the description, affected, reference URLs, etc.) created by
the CNA that issued it, and a third party (another CNA, a non CNA
entity like a researcher, a vendor, etc.) may want to change that data
(e.g. the description mentions affected versions and a researcher
wants to add more). We have two main choices:

1) get the entities to cooperate and come up with a change (or not) to 
the data
2) allow the third party data to be added, with source information (so
e.g. you have vendor affected data from the vendor, and vendor
affected data from a third party researcher, sorting it out is left as
an exercise to the reader).

I would suggest we want to encourage #1, and possibly enforce it for
some of the data (e.g. the global description), but that there is also
value in allowing competing statements (e.g. vendor affects).

Some concerns with #1: with an original CVE this is "Easy", talk to
the CNA. But what do we do in a case like CVE-2009-3555 where
potentially a dozen vendors want to muck in? Does anyone who
previously had input on the change need to be consulted for future
changes, or does the original CNA "own" that CVE and we send everyone
to them simply?

Some concerns with #2: some data won't be that painful to have
multiple different sets of (e.g. impact) but some data will become
very confusing if there are multiple entries, especially if they
conflict (e.g. flaw type, it's supposed to be a single thing, if
someone puts buffer overflow, and someone else puts buffer
underread... er....) and of course the global description, I think
like the Highlander there can only be one, it's an assumption all the
tools have made (I know I did).

So in the short term we need to decide:

Do we allow convergence of the data? (I think the obvious answer is yes)

Do we allow multiple sets of data? (I think the answer is... maybe,
depends on what it is/who's doing it, so if we decide yes then doing
this becomes contingent  ont he business rules stuff from the
automation working group). Also we need to then rejigger the JSON
format a bit (and I would suggest major version # bump to 5 since it
won't be backwards compatible).

So we also need to define the data that we really care about (e.g. we
won't allow multiple CVE #'s in... right? what about requester?
description?) and which we care less about (I would suggest anything
data and not directly not at the root level is fair game..., so e.g.
affected:* and adding reference URLs for example).



-- 

Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: secalert@redhat.com
Page Last Updated or Reviewed: December 14, 2017