Re: Initial Guidance on Linux Issues

[Art Manion <amanion@cert.org>]

Dave Mann:
>> Independent of the question of feasibility, is it required that there be 
>> CVE ids associated with all packages that are distributed by a 
>> commercially supported Linux distribution?  Or, is there a smaller 
>> sub-set of package for which we need full coverage while still allowing 
>> partial coverage of the others?

On 2012-05-17 03:45 , Mark J Cox wrote:
> Our (Red Hat) processes and procedures require that every vulnerability is 
> given a CVE name.  We use CVE as our primary key in a number of situations 
> including our bug database and CVE database as well as for internal 
> tracking of issues, instead of using any other unique identifier.

Here are all the current issues:  Coverage, assignment authority, and
speed/timing (and quality, Mark proposed information required to obtain
a CVE ID).

We could try to come up with a shorter (<2100) list of Linux packages
that get CVE IDs, but this wouldn't meet Red Hat's current requirement.

If CVE is not to be funded/staffed to cover Linux packages (much less
small PHP web apps and Chinese software), somebody else (CNAs?) has to
do more assignment/tracking.

I'd suggest we look at some form of more distributed CVE assignment,
with more authority (for lack of a better word) given to CNAs, and maybe
adding CNAs.  Maybe if CVE's role was to "accredit" or monitor CNAs,
maintain the master list, and handle disagreements, then CNAs would do
the bulk of the assignment.  I don't know exactly how far this direction
to move, or what it would mean for CVE's efforts to disambiguate and to
write the dense CVE text that goes with an entry.

I guess I don't see much choice other than to shift more of the burden
to CNAs and possibly accept more REJECTs and less consistent (and
possibly lower quality) descriptions.  Well, another choice would be
sufficient funding, probably of a combination of organizations
(obviously including MITRE), where "sufficient" includes all Linux
packages, among many other things.

Maybe the board could come up with a definition of "sufficient coverage,
quality, and speed," then look for ways (including effort/funding) to
meet that definition.  Then the exercise is requirement building, not
budgeting what is possible with current effort.

As some of you on the board may know, I'm generally a proponent of
giving every reasonable public vulnerability report on the planet an ID,
then adding value (like disambiguation, quality dense descriptive text,
CVSS scores, etc).


 - Art