doc: expand SECURITY.md with non-vulnerability examples

[RafaelGSS]

As discussed in the triage team, most of the reports we are receiving are using IA to fuzz your codebase, making this explicitly on SECURITY.md might avoid that amount of AI Sloop.

cc: @nodejs/security-triage

[nodejs-github-bot]

Review requested:

• @nodejs/tsc

[Renegade334]

This one seems a bit specific. I feel like we probably don't need to go down the line of exhaustively listing every received wontfix...

[RafaelGSS]

It's just an attempt to reduce the AI-sloop. If it fixes the problem, we might want to go down that line... in a separate file, possibly more specific to AI.

[rsclarke]

This is a bit disheartening to see since I decided to discuss this very issue with @RafaelGSS first to understand what falls in or out of the node js threat model.

Yes AI was used in the discovery, but there are three points that led to the discussion to seek clarification;

1. CWE-444 is given as an example vulnerability in this doc
2. The wording;

if the data passing through Node.js to/from the application can trigger actions other than those documented for the APIs

3. The paragraph (emphasis mine);

In addition to addressing vulnerabilities based on the above, the project works to avoid APIs and internal implementations that make it "easy" for application code to use the APIs incorrectly in a way that results in vulnerabilities within the application code itself. While we don’t consider those vulnerabilities in Node.js itself and will not necessarily issue a CVE, we do want them to be reported privately to Node.js first. We often choose to work to improve our APIs based on those reports and issue fixes either in regular or security releases depending on how much of a risk to the community they pose.

Despite AI involvement, it presented as an issue that ought to be addressed, if the means of reporting was incorrect, I apologise, I thought I did the right thing, but I do acknowledge that the use of AI in security is only going to exacerbate claims of vulnerabilities.

Lastly, here's the PR to actually try and harden/sanitise from CRLF through writeEarlyHints() to prevent this very footgun #61897. It still holds that's the applications responsibility for those header name/values, but at least there's some mitigation and consistency with other header setting functions.

Rather than specifically calling out CRLF in writeEarlyHints, could this example be updated to demonstrate the differentiator between an applications responsibility and node js, which I read as the intent of this. An issue within JSON.parse might be the responsibility of node js but the resulting value given some remote data is the applications.

[github-actions]

Fast-track has been requested by @RafaelGSS. Please 👍 to approve.

[mcollina]

lgtm