[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2733178.4axvx009n6@sarpedon>
Date: Wed, 09 Mar 2016 15:59:25 +0000
From: Tim Brown <tmb@...35.com>
To: oss-security@...ts.openwall.com
Subject: Re: Concerns about CVE coverage shrinking - direct impact to researchers/companies
On Sunday 06 March 2016 21:39:54 Gsunde Orangen wrote:
> I totally agree.
> The concern addressed by Kurt initially is fully valid (for both
> researchers and for companies that are not on Mitre's product/sources
> list), so a new (better: additional) solution is required.
> However, creating a new standard independently of CVE would be too
> disruptive and be a disservice to the software industry.
Quite, as much as I appreciate the options presented over the last few days, I
don't think any of them are the winning horse.
(To paraphase) if MITRE does not exist then it must be reinvented however the
days of multiple competing indexes of vulns should be avoided if possible. We
only have to look at the AV community to see how that degenerates. This one of
the main reasons that when we open sourced out disclosure tool kit, we
explicitly mandated the use of CVEs for tracking.
> I'd propose to work out a new solution together with Mitre, whilst
> keeping the CVE IDs as today.
As would I however, even with pointers from SC about who to poke within MITRE
we came up short tracking a warm body down for (~7) months (even one that was
willing to say no). That being said, we have now located a new warm body at
MITRE who has made themselves known to us, I am more than happy to approach
them about the following:
> Since 2014, virtually unlimited number of CVE IDs can be assigned per
> year [1], so a solution could be that
> - Mitre continues to assign 4 and 5 digit IDs as today
> - 6 digit IDs are reserved for the new process (hosted outside Mitre)
> If more than one million vulnerabilities need to be addressed in one
> year, we could follow the rule (odd digits -> Mitre, even digits ->
> "other process")
>
> >From Mitre's POC, this "other process" would become a "CNA", just with
>
> its own policy and process definition, not prescribed by Mitre.
> It would soon become clear to everyone (and all tools and products that
> rely on CVE) where to look at for the authoritative vulnerability
> information.
>
> And yes: OWASP.org could certainly be a perfect host for that new "CNA"
> - as Mark offered earlier ;-)
Indeed, such a project requires a vendor neutral host. If OWASP are up for it,
then I would gladly support them running with the above proposal, if not then
a good faith alternative ought to be sought.
Tim
--
Tim Brown
<mailto:tmb@...35.com>
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
