Right, like OSVDB or Secunia. Even if a site doesn't go away, there's a good chance they do something that breaks URLs (like switching to another CMS) and they may not include redirects.
Do we capture and save the data for every URL we list with a CVE? If not, we should. Regards, Ken On Fri, Aug 20, 2021 at 12:44 PM Tod Beardsley <tod_beards...@rapid7.com> wrote: > Incidentally, websites can and do go away. > > If a CVE has a reference that's no longer valid, surely that doesn't > invalidate the CVE? > > On Fri, Aug 20, 2021 at 12:34 PM Chandan B.N. < > cnandakum...@paloaltonetworks.com> wrote: > >> 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 <firstname.lastname@example.org> >>> 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 <email@example.com> >>> 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/ >> > > NOTICE OF CONFIDENTIALITY: At Rapid7, the privacy of our customers, > partners, and employees is paramount. If you received this email in error, > please notify the sender and delete it from your inbox right away. Learn > how Rapid7 handles privacy at rapid7.com/privacy-policy > <https://www.rapid7.com/privacy-policy/>. To opt-out of Rapid7 marketing > emails, please click here > <https://information.rapid7.com/communication-preferences.html> or email > priv...@rapid7.com. -- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.
Description: S/MIME Cryptographic Signature