Proposal: Moving security reports to a public workflow

[RafaelGSS]

I've been handling Node.js security for quite a long time, and I want to propose a strategy that may sound controversial, but I believe it deserves serious discussion given the reality we're facing today.

Over the last six months, the Node.js project has seen a significant increase in both contributions and HackerOne reports. In my view, this surge is largely driven by AI: contributors are using LLMs to fuzz and scan our codebase for potential vulnerabilities, and the reports we're receiving are remarkably similar -> strongly suggesting they originate from the same or similar LLM/tooling.

We've already taken steps to address this:

• We raised the signal requirement for who can open reports against the project https://nodejs.org/en/blog/announcements/hackerone-signal-requirement
• We expanded our Threat Model to clarify what is and isn't in scope https://github.com/nodejs/node/blob/main/SECURITY.md, with more PRs in progress to improve it further
• We are automatically closing reports that don't match our requirements

These measures have helped, but they haven't solved the problem. We are still overwhelmed. Reports that get automatically closed due to insufficient signal are now reaching our OpenJS CNA email and following our escalation path, and soon that team will be overwhelmed too.

The obvious path would be dropping bounties for security reports, but I have a second strategy that I think is worth considering

Most of the reports we receive are not vulnerabilities. They don't meet the bar defined by our threat model, but that doesn't mean they aren't bugs worth fixing. The reports are also highly duplicated, which tells us something important: anyone with access to a capable LLM (such as Opus 4.6) can surface the same findings at any time. These findings are effectively public already. If a commonly available tool can reproduce them on demand, treating them as private secrets provides a false sense of security. More effectively, our disclosure policy is set to 90 days and due to the fact I mentioned above, anyone would be able to find valid vulnerabilities before we even issue a security release.

So why do we need a private workflow for them?

I'm proposing that Node.js handle all security reports through a public workflow, similar to how Chromium/V8 has operated for a long time (@nodejs/v8 please correct me if I'm wrong). Most of what we receive aren't vulnerabilities, but they are bugs, and they'd get fixed faster if they were visible to the entire contributor community instead of sitting in a private queue. The security team's capacity would be freed up to focus on dependency vulnerabilities and shipping releases faster (as we won't need to lock ci, and follow all 26 steps) rather than triaging a flood of AI-generated noise. We would of course still need a defined process for the rare cases that do warrant an embargo.

I'd love to hear everyone's thoughts. The goal is to find a sustainable approach that keeps Node.js secure without burning out the people doing the work.

cc: @nodejs/tsc @nodejs/security @nodejs/security-triage

[richardlau]

Probably someone more familiar with V8 can comment, but I don't believe their whole process is public. I think the patches may be, but there definitely are issues that get referenced that I am not able to view.

FWIW, different project but https://daniel.haxx.se/blog/2026/02/25/curl-security-moves-again/ chronicles what the Curl project is going through with respect to handling security reports.

[BethGriggs]

My initial reaction is that your premise makes sense. If a broadly available LLM can rediscover the same/similar issues on demand, then they're not really private anymore and the process is more procedural than protective.

The main caution is not to swap one kind of overload for another, though. I suspect public issues will add pressure for more frequent and/or immediate releases to remediate the problem. It might also be tricky to define the boundary for what should still be embargoed.

That being said, moving all the H1 reports designated as N/A to the public issue tracker, by default, could be an interim step to try.

[RafaelGSS]

That being said, moving all the H1 reports designated as N/A to the public issue tracker, by default, could be an interim step to try.

The problem is that we still need to evaluate all the reports, so the overload will still exist and possibly worsen, since we will be forwarding this to the issues section anyway.

[BethGriggs]

Just suggestion as something to try sooner - I doubt there will be a quick or timely agreement on moving the entire process public (I could be wrong).

I'd hope that the presence of those on the public issue tracker might help in a minor way in the meantime - by encouraging a wider base of contributors tackle a bunch of the low-hanging fruit and similar issues. At the very least, it provides a public record to stop all the back/forth required with the declined Hackerone reports.