Triage new reports against last EOL line/s

[marco-ippolito]

When we get a new vulnerability report, we’ll test it against the last EOL version, or maybe even the last two.
The point is NOT to start fixing vulnerabilities for EOL versions (we still won’t accept reports targeting them),
but to give users a better understanding of the risks involved in sticking with unsupported software.

We’ll check if the reported issue can be reproduced on EOL versions,
but only on a “best effort” basis.
Some reports will be easy to confirm, others might take more digging, others will be impossible to test. Either way, this should add minimal burden to our current workflow.
Reports for EOL versions won’t lead to any fix, it’s purely informational. Our focus stays on LTS versions.
In case a report is find reproducibile on a EOL version, it will be included in the version range when releasing the CVE.

Why This Matters:

By testing EOL versions, we can help users see the risks of staying on outdated software. It’s not about adding more work for us.

It's important to set the right expectation to users.
There might be false negatives, since this is at best effort (which at the end of the day is true for every volunteering job).
But even if we can find 1 vulnerability is still better than 0 that we do now.

I will volunteer for this extra effort + security triaging.

@nodejs/security-wg

[RafaelGSS]

As I said in different discussions, I don't think this is sustainable or accurate. Quoting myself in the TSC channel:

That's why we always ask the reporter to use different active versions of Node.js, and sometimes, the vulnerability is explored differently. That's why I think that testing against EOL versions without the reporter's consent/help is prone to false negatives.

Also:

Reports for EOL versions won’t lead to any fix, it’s purely informational. Our focus stays on LTS versions.
In case a report is find reproducible on a EOL version, it will be included in the version range when releasing the CVE.

I don't think that's correct. We should not issue any CVE to EOL lines, this has also a downside that users would think they are
"safe" if we issue a CVE to v16.x but not to v14.x (because it wasn't reproducible) and it won't mean the vulnerability is not there.

[marco-ippolito]

I don't think that's correct. We should not issue any CVE to EOL lines, this has also a downside that users would think they are "safe" if we issue a CVE to v16.x but not to v14.x (because it wasn't reproducible) and it won't mean the vulnerability is not there.

It can be easily documented. Now users think they are safe anyways (before the universal CVE at least).

[RafaelGSS]

It can be easily documented. Now users think they are safe anyways (before the universal CVE at least).

Yeah, that's why we came up with #1419

[ljharb]

It's also worth noting that anyone on the planet can file a CVE against an EOL version, and node can't stop that from happening as long as it's plausible - so this is more like, should node take ownership of this, or should we allow "not node" to take ownership of it?

[RafaelGSS]

IMO If another CNA wants to issue CVE against the EOL version of Node.js that's up to them, we (Node.js) shouldn't do anything around it.

[mcollina]

I would propose a different take: always include the past 2 release lines when issuing CVEs, with a disclaimer like the one offered by spring boot:

Older, unsupported versions are also affected

https://spring.io/security/cve-2024-38829

[ljharb]

Marking a version as definitively affected when it hasn't been verified to be imo is worse than not indicating it at all.

[mcollina]

Marking a version as definitively affected when it hasn't been verified to be imo is worse than not indicating it at all.

Considering some of the feedback I've received from the "security community", it might be preferred to issue a blanket CVE for EOL lines.

[ljharb]

Didn't node already do that?

A specific CVE, however, should only indicate affected versions when they definitively apply.

[mcollina]

Didn't node already do that?

No, because:

A specific CVE, however, should only indicate affected versions when they definitively apply.

which is my point. Include the last two release lines anyway.