I agree that the CVE program has different purposes and goals than Twitter.
I agree that the public reference requirement is a good thing. The example I gave on the call was this one: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-17444 IIRC our researchers noticed undocumented admin privileged accounts with easy passwords that were seen in many real-world deployments of this product. The vendor acknowledged the problem and fixed it, but failed to mention either the issue or CVE-2019-17444 in release notes. Our researchers did not pursue publishing any blog on this topic - likely they had moved into doing new research. While this may be a corner case: The vendor and the researcher have decided they no longer have skin in the game. Don't the consumers and vulnerability management community still have skin in the game? Especially when it is a real confirmed critical vulnerability in a popular tool used in many supply chains that could lead to yet another SolarWinds type of hack? What is the guidance to CNAs or CNA-LR when they get a request (and agreement) to assign a CVE to a real vulnerability (in emails, attached PoCs) but no clear public reference exists? not assign a CVE? Thank you, Chandan On Fri, Aug 20, 2021 at 9:13 AM Noble, Kathleen <kathleen.no...@intel.com> wrote: > I was going to jump in and say I see this as less a social medial platform > and more a Major Sports League. You want to play at the NBA you play by the > NBA's rules. The rules can change over time, but it doesn’t make a lot of > sense to change the game and remove the basket because a few potential > players are anti-basket. > > I agree we table the issue. > > Katie Noble > Director, Intel PSIRT and Bug Bounty > 503-207-8783 > kathleen.no...@intel.com > Keybase: katienoble > > -----Original Message----- > From: Landfield, Kent (Enterprise) <kent_landfi...@mcafee.com> > Sent: Friday, August 20, 2021 10:19 AM > To: Gazlay, Jay <jay.gaz...@cisa.dhs.gov>; Manion, Art <aman...@cert.org>; > Chandan B.N. <cnandakum...@paloaltonetworks.com>; CVE Editorial Board > Discussion <email@example.com> > Subject: Re: public reference requirement > > +1 > > Thank you, Gracias, Grazie, Mahalo, 谢谢, Merci!, Σας ευχαριστώ!, Спасибо!, > Bedankt,Danke!, ありがとう, धन्यवाद! > -- > Kent Landfield > McAfee Enterprise > +1.817.637.8026 > kent_landfi...@mcafee.com > > > On 8/20/21, 5:42 AM, "Gazlay, Jay" <jay.gaz...@cisa.dhs.gov> wrote: > > CAUTION: External email. Do not click links or open attachments unless > you recognize the sender and know the content is safe. > > Art, > > I concur with your point and path forward. > > Cheers, > Jay > > -----Original Message----- > From: Art Manion <aman...@cert.org> > Sent: Thursday, August 19, 2021 9:47 PM > To: Chandan B.N. <cnandakum...@paloaltonetworks.com>; CVE Editorial > Board Discussion <firstname.lastname@example.org> > Subject: Re: public reference requirement > > CAUTION: This email originated from outside of DHS. DO NOT click links > or open attachments unless you recognize and/or trust the sender. Contact > your component SOC with questions or concerns. > > > On 2021-08-18 16:58, Chandan B.N. wrote: > > This is no different than how Twitter users are seen as being > responsible for their tweets and not Twitter Inc., > > I was trying to not bring this up :) > > I'd say Twitter is much more of a platform with highly independent > contributors than the CVE Program currently is. Twitter might not be a > common carrier ISP, but CVE is not a social media platform. > > The author needs to bear responsibility for errors or bad behavior and > having only a CVE entry (today) is too much of a proxy. Responsibility is > arguably more important than the content. > > I think the program has moved and is moving towards being more > "content neutral" -- the upcoming Services and potential ADP pilot are > moves in that direction. I'm confident we can sort out some of the content > quality requirements, we need more CNA identity in place. > > I'll propose to table this for a year? > > Regards, > > - Art > > -- Sr Director, Product Security Assurance, Vulnerability Remediation, and PSIRT Palo Alto Networks https://security.paloaltonetworks.com/