Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 4 Mar 2016 16:56:13 -0500
From: Adam Caudill <adam@...mcaudill.com>
To: "oss-security@...ts.openwall.com" <oss-security@...ts.openwall.com>
Cc: Art Manion <amanion@...t.org>, Kurt Seifried <kseifried@...hat.com>, 
	cve-editorial-board-list <cve-editorial-board-list@...ts.mitre.org>
Subject: Re: RE: Concerns about CVE coverage shrinking - direct
 impact to researchers/companies

CVE clearly plays an important role - customers and clients rely on
them, researchers need them to coordinate with vendors - they play an
important role in so many parts of vulnerability disclosure and
management - yet as Kurt points out, researchers request CVEs, and the
requests are rejected because of this coverage policy (assuming the
researcher gets a response; anyone that has watched this list has seen
the issues with requests not being responded to). By rejecting these
requests, and leaving legitimate vulnerabilities in software with a
significant user base without a CVE, it makes work for difficult for
researchers, for vendors, and for customers.

The level of frustration in the research community has been growing,
with steady calls for a new CVE-like solution that is designed to
address these needs in a more effective way. I greatly appreciate the
work that has been done, but at this point CVE is becoming less
useful, less relevant - if this isn't addressed, my expectation is
that a CVE-like solution will be adopted by the community, and
researchers will begin moving away from requesting CVEs.

At least one (very prolific) researcher has already moved to
self-assigning CVE-like IDs that are outside of the normal CVE range
to address this issue. Others are trying to create their own
registries, and as Kurt points out, some are just not requesting IDs
of any sort now.

This is a legitimate problem, the frustration level is growing, some
type of solution is needed.

--Adam Caudill
http://adamcaudill.com


On Fri, Mar 4, 2016 at 3:25 PM, Mike Prosser <mprosser@...antec.com> wrote:
> While it would have an impact for sure on our community, I think the biggest impact would be on customers since CVEs have become a Vulnerability Name when calling support with concerns....rather than just a common tracking reference.
>
> -Mike
> Symantec Software Security Group
>
>
> -----Original Message-----
> From: owner-cve-editorial-board-list@...ts.mitre.org [mailto:owner-cve-editorial-board-list@...ts.mitre.org] On Behalf Of Art Manion
> Sent: Friday, March 04, 2016 1:08 PM
> To: Kurt Seifried <kseifried@...hat.com>; cve-editorial-board-list <cve-editorial-board-list@...TS.MITRE.ORG>; oss-security <oss-security@...ts.openwall.com>
> Subject: Re: Concerns about CVE coverage shrinking - direct impact to researchers/companies
>
> On 2016-03-04 13:24, Kurt Seifried wrote:
>> So I've now heard from several security researchers that they are
>> unable to get CVEs for issues that need CVEs (e.g. widely used
>> hardware/software with flaws that have real world impacts and need to
>> be properly tracked. This has definitely resulted in issues being
>> publicized with no CVE that then makes it much harder to track and
>> deal with these issues.
>
> I think it's been said on this list previously -- these are two separate
> activities:
>
> 1. Assigning IDs
>
> 2. Analysis, deconfliction, write-up
>
> Binding these together results in delay, because #2 takes considerably more calendar time and effort.  Another result is a limited but fairly high quality set of entries (once #2 is complete).
>
> I share Kurt's concern that CVE is not meeting a researcher/disclosure use case of having IDs for vulnerabilities, and that the community will at some point stop bothering with CVE.
>
> I'm not sure how bad such an outcome would be, or what impact that would have on CVE.
>
>  - Art

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ