doc: clarify security triage dispositions and permission boundaries

[RafaelGSS]

Clarify SECURITY.md by defining security triage dispositions, documenting same-process self-harm exclusions, and separating Permission Model reports into vulnerability, security-interest, and excluded cases. Also correct the worker_threads guidance: workers with modified execArgv or env may not inherit the parent permission configuration, while worker creation itself remains gated by --allow-worker.

[nodejs-github-bot]

Review requested:

• @nodejs/tsc

[BethGriggs]

It might just be me, but I find this line slightly hard to follow as it's written. I think the wording is easy to overlap with vulnerabilities that we reject due to requiring untrusted input.

[RafaelGSS]

Do you have a suggestion?

[BethGriggs]

Maybe something like this? But non-blocking if others prefer the original version:

Suggested change

	* **Vulnerability**: Reachable through an element Node.js does not trust and
	causes disclosure or loss of integrity or confidentiality of protected data,
	arbitrary code execution, or runtime unavailability under the DoS criteria
	described below.
	* **Vulnerability**: A Node.js defect that an untrusted party can exploit to
	disclose protected data, compromise its integrity or confidentiality, execute
	arbitrary code, or make the runtime unavailable under the DoS criteria below.

[RafaelGSS]

I’m just confused with what “protected data” means here. Someone could reasonably interpret “protected” as protected by application authorization, filesystem permissions, the Permission Model, or something else outside Node’s threat model

[BethGriggs]

Ah, I just kept that term as it was in the original

[BethGriggs]

My main confusion was with this part:

Vulnerability: Reachable through an element Node.js does not trust

But, perhaps need to rethink the whole line.

[RafaelGSS]

See: #65436 (comment)