Extend security reporting for LTS lines beyond their lifetimes

[bengl]

Today, the reported (and fixed) security vulnerabilities in Node.js core are stored in this repo in JSON, but they only end up in the data if the vulnerability is fixed. This means that EOL release lines may or may not be vulnerable to any given vulnerability, if basing this on the data in this repo alone. AFAICT, vulnerabilities simply aren't reported on EOL lines. While this shouldn't be an issue, since folks are asked not to run EOL versions of Node.js in production, in practice folks run EOL versions of Node.js long past their lifetimes.

My suggestion is that the security process be amended to report whether LTS Node.js release lines that have been EOL for less than two years are vulnerable to any given vulnerability. I'm not suggesting extending the LTS timeline in general (at least not in this issue 😄). I'm only suggesting that vulnerabilities be reported on them for an additional two years.

This would serve two purposes:

1. It would give users greater clarity into the scope of vulnerabilities, and whether or not they need to upgrade due to known vulnerabilities (yes, even though they should not run EOL versions anyway).
2. Publishing data on known vulnerabilities in release lines where they won't be fixed provides extra incentive to upgrade.

[mcollina]

While I understand where you are coming from, assessing any vulnerability for old lines is tricky. In some cases we can't even build them on modern systems
or they won't run.

What we can change is set the minimum version to 2 LTS prior unless we know exactly when the vuln was introduced.

This does not change the workload, and it something that can help updating.

[bengl]

While I understand where you are coming from, assessing any vulnerability for old lines is tricky. In some cases we can't even build them on modern systems or they won't run.

That's why I suggested 2 years, and not all time. Are there versions of Node.js older than LTS EOL + 2y where this would be an issue?

Either way, even a best effort approach would be helpful here. e.g. "We make best-effort attempts to report vulnerabilities for LTS EOL release lines that have been EOL for less than two years, but note that a lack of report does not imply lack of vulnerability, since it's sometimes impossible to test with older versions." or similar language.

What we can change is set the minimum version to 2 LTS prior unless we know exactly when the vuln was introduced.

I see. So an assumption of vulnerability even if not testable? That might help the situation, but it might also cause a boy-who-cried-wolf scenario. I'm not sure 🤷.

[cjihrig]

I don't think we should do this. End of life should mean end of life. If we start looking at EOL + 2 years, people will start asking for EOL + 3 years and so on. In my experience, companies know that they are running an EOL version and will even go so far as hiring a company to provide support past EOL. I think we should allow for that model and not provide "official" post EOL support from a project of volunteers.

[Qard]

Can we test back to the x.0.0 of our oldest release and if the vulnerability is present there communicate clearly that we've tested back to there but most likely the vulnerability exists beyond that range? Like stating a confirmed impacted range and suggesting something like <=x.0.0 where x.0.0 is the oldest version we tested against?

[RafaelGSS]

It's impractical to test all EOL Node.js versions when we receive a HackerOne report. The safest approach I could reach on https://github.com/RafaelGSS/is-my-node-vulnerable is:

• If you are using an EOL version and NO security release was made in that period. You are ok (with some warning recommending the upgrade)
• If you are using an EOL version and a security release was made after the EOL version. You are in danger.

It's hard to assess some H1 reports and if we expand the scope to EOL LTS versions that can be easily a nightmare for the ones in the rotation.

[mhdawson]

It's hard to assess some H1 reports and if we expand the scope to EOL LTS versions that can be easily a nightmare for the ones in the rotation.

This is the key issue in my mind. It requires more work, who is going to do that work? Our support lifecycle is a balance between what the project takes on in terms of work and the needs of the community.

I think that it would be great if people did this assessment and shared it. If there are a group of people who want to volunteer to do that work the project might help through some resources (maybe similar model to unofficial builds) but I'd see is as an "unofficial" source without the project commiting to do the work.

[github-actions]

This issue is stale because it has been open many days with no activity. It will be closed soon unless the stale label is removed or a comment is made.

[marco-ippolito]

It's hard to assess some H1 reports and if we expand the scope to EOL LTS versions that can be easily a nightmare for the ones in the rotation.

This is the key issue in my mind. It requires more work, who is going to do that work? Our support lifecycle is a balance between what the project takes on in terms of work and the needs of the community.

I think that it would be great if people did this assessment and shared it. If there are a group of people who want to volunteer to do that work the project might help through some resources (maybe similar model to unofficial builds) but I'd see is as an "unofficial" source without the project commiting to do the work.

I'd like to reopen this issue since I'd be interested in doing the work

[RafaelGSS]

I’m currently at -1. While a company like HeroDevs could sponsor a review of all reports to determine if they affect all versions, it's possible that some reports may impact different versions in ways not covered in the report. Consequently, the security researcher may overlook these variations, and we won’t be aware of them, apart from the fact that this is not sustainable without a sponsorship.

[marco-ippolito]

@RafaelGSS it doesnt have to be retro-active. It can be done for new report. Whenever we triage a new report, I'll take care of reproducibility in EOL versions. This work will be sponsored by HeroDevs.

[RafaelGSS]

@RafaelGSS it doesnt have to be retro-active. It can be done for new report. Whenever we triage a new report, I'll take care of reproducibility in EOL versions. This work will be sponsored by HeroDevs.

I'm not considering retroactive reports. My statement is valid for new reports too.

[marco-ippolito]

If we don't produce a CVE, users will think that even though their version is EOL, it is safe, which is absolutely not true. We still won't accept reports for older versions, but at least if reproducible, issue the CVE for that version.

[RafaelGSS]

End-of-Life (EOL) versions should be viewed as inherently insecure. If users are seeking a security tool to identify whether they are using a version with a public CVE, the tool should also assess if the version is EOL and recommend an upgrade.

[mhdawson]

I'm +1 on supporting people who want to make sure people using EOL versions are at risk of CVEs etc. At the same time I'd be hesistant of something which implies the project has agreed to assess/asign CVEs for EOL versions.

A few ideas:

1. Figure out a way for the project to let third parties like HeroDevs to assign CVEs to EOL versions, making it clear that it's not something the project commits to itself.
2. When a version goes EOL, issue a single CVE indicating that the version is EOL and should be considered vulnerable.
3. provide a repo where discussion/collaboration on identifying if CVEs apply to older versions or not can take place (along the lines of https://github.com/nodejs/nodejs-dependency-vuln-assessments, where the README.md makes it clear there is no commitment from the project on doing an assessment but a place is being provided where collaboration on those assessments can take place/be documented.

@marco-ippolito not sure if any of those would help with what you wanted to accomplish?

[RafaelGSS]

For your second suggestion @mhdawson, see: #1401

[mhdawson]

@RafaelGSS thanks for the pointer, commented there.