Proposal: Moving security reports to a public workflow

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) EDIT: Chromium/V8 does not handle security reports in public, though the issue tracker allows flipping visibility of bugs easily. See https://www.chromium.org/Home/chromium-security/. 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

Start with SECURITY.md and the linked HackerOne signal-requirement announcement to understand the current threat model, reporting rules, and escalation path. Review the discussion and define what a public workflow would need to cover, including the rare reports requiring an embargo; done means the project has agreed on and documented a sustainable process.