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

Re: recent CVE criticism

I suspect David Jorm may slightly have the wrong end of the stick or be basing this one some misinterpreted information (perhaps Google/WebKit CVE handling, which has been a bit messy historically? Or prject Zero related stuff?). Google is not a CNA and not on the board however so I can't see how they'd have much influence over Mitre. It's on my todo list to talk to him (full disclosure: he used to be my manager @Red Hat some time ago before he left). 

Like many groups we're nowhere near organized or competent enough to have some sort of CVE related conspiracy going on (and if there is one and I wasn't invited in I'll be proper annoyed ;). 

On Tue, May 31, 2016 at 10:20 PM, jericho <jericho@attrition.org> wrote:
FYI. Really curious what the 'Google' bit means re: secret rules.

--

http://www.scmagazine.com/alt-campaign-plans-to-replace-fundamentally-broken-cve-platform/article/498880/

https://conference.auscert.org.au/david-jorm

Presentation Title

CVE is logjammed, CNVD is nearly as bad, and my heart bleeds for the whole mess Abstract

In 2014-15 there were a range of high-impact vulnerabilities with catchy names: shellshock, heartbleed, logjam, etc. Debate raged around this trend, with many arguing that people took named vulnerabilities more seriously regardless of their actual impact. What people didn't really consider was whether naming vulnerabilities was necessary simply to ensure they had a useful canonical identifier associated with them.

This presentation will explore the common vulnerabilities and exposures (CVE) program, which aims to provide canonical identifiers to vulnerabilities. It will argue that CVE is fundamentally broken, and that the MITRE corporation running it is both unable to fix it, and unsuited to issuing canonical identifiers because of its conflict of interest as a government-funded program. A litany of failures of the CVE process will be detailed, along with inside information on the extent to which the process is governed by secret rules at the behest of large software companies *cough* Google *cough*.

Alternatives such as China's CNVD will also be examined, followed by discussion of a movement currently underway in the community to take over and fix the CVE process.



--

--
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: June 01, 2016