feat: add csv with missing

[marco-ippolito]

Created a CSV with every CVE in our list, and the missing EOL lines
@nodejs/security-wg

[RafaelGSS]

The first line I reviewed points exactly to why I told you that this process isn't that simple as it seems.

To make it work we'll need to find exactly which versions were End-of-Life in the moment the patched version came out. For instance, if the CVE is being patched to v8.x and v6.x line is not EOL yet, it implies that version is not affected by that vulnerability, on the other hand, v7.x was EOL and should be included. We'll need to correlate the version date using @pkgjs/nv and https://github.com/nodejs/Release/blob/main/schedule.json to make it correct.

[mcollina]

lgtm

[mhdawson]

@marco-ippolito to help me understand, does this just mark all EOL version as vulnerable to all CVEs that we have not checked for applicability or is it based on research you have done?

[marco-ippolito]

@marco-ippolito to help me understand, does this just mark all EOL version as vulnerable to all CVEs that we have not checked for applicability or is it based on research you have done?

This marks as vulnerable every version that wad EOL when the cve was assigned. Its not based on research

[ljharb]

… we're not planning on adding those to the CVE, though, right? especially given MITRE's response, an affected version needs to be one that's been explicitly validated as affected, not just "maybe/probably? we haven't checked"

[mhdawson]

@marco-ippolito thanks for confirming

[mhdawson]

@ljharb other projects (I think spring was the one mentioned) tag all EOL versions as vulnerable to all new CVE's without checking. I believe that was the pattern we are planning to follow.

[ljharb]

oof, ok. that's really unfortunate, but i guess it's better than nothing.

[RafaelGSS]

oof, ok. that's really unfortunate, but i guess it's better than nothing.

Yeah, that's exactly what I tried to bring to the OpenSSF discussion. We don't have the capacity to assess all EOL lines against CVEs, but still, we want to inform users they shouldn't be using an EOL. As Michael mentioned, this is the only viable option we found -- although sometimes imprecise.

[RafaelGSS]

LGTM. We should update the vuln database too. Use a new field on this instead.

[marco-ippolito]

Should we create an issue to track next steps?

[RafaelGSS]

Should we create an issue to track next steps?

I'd merge this PR only when H1 updates the CVE, then we can create the issue to update the vuln DB.

In theory, we already have: #1443

[marco-ippolito]

All right so we should create a ticket on H1 and send them the csv.