Assigning a CVE for EOL is actually outside the normal practice (there is another standard for that underway) and is not in line with Rule 4.1 as part of the CVE program.
I do agree with Greg K-H that open source projects should become CNAs. But do want to note that missing elements of the CVE when submitting allows CISA-ADP to 'vulnrich' your data. Here is where misinterpretation and/or lack of understanding by CISA confuses downstream users and once you gain that 'critical' stigma in the system, you have to be persistent to get that changed. Is that a problem? I think so and so do a number of PSIRTs so now we have to contend with CISA-ADP and NVD to adjust their scores when the CNA is 'the authoritative source' within the CVE Program. Pete On Sat, Jan 25, 2025 at 2:02 AM Greg KH <[email protected]> wrote: > On Fri, Jan 24, 2025 at 10:55:39AM -0800, Alan Coopersmith wrote: > > Their reasons for this are detailed on the blog post at: > > https://nodejs.org/en/blog/vulnerability/upcoming-cve-for-eol-versions > > including getting CVE scanners to report EOL versions as vulnerable even > > if no existing CVE specifically says that they are. > > > > While I can understand their reasoning, I can just imagine the noise if > > every project started issuing CVE's for every version that reaches EOL. > > I think that's a great idea for projects to start doing (especially ones > that are a CNA which I recommend all open source projects become.) > > And as for "noise", I think that will just be a "drop in the bucket" of > the overall CVE assignment numbers these days as just how many different > software versions are going EOL each month? > > thanks, > > greg k-h > >
