Repository navigation
Proposal: Moving security reports to a public workflow #1826
Description
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
Activity
richardlau commentedon Feb 26, 2026
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 commentedon Feb 26, 2026
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 commentedon Feb 26, 2026
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 commentedon Feb 26, 2026
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.
vdeturckheim commentedon Mar 2, 2026
Wow, that's a very interesting take. I think it is a good idea. Being transparent about potential vulnerabilities gives the end user a stronger position in a world where exploit discovery is cheap.
I think this is pretty exciting!
joyeecheung commentedon Mar 3, 2026
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/
joyeecheung commentedon Mar 3, 2026
I also wonder about this. Part of the reasoning of this proposal is that
But the reviews still need to done by an existing collaborator at least, so we might get swamped by AI generated PRs and cannot keep up with the reviews instead, which isn't necessarily much better than getting swamped by AI generated reports without PRs...
I think an alternative approach is to give the access to all collaborators. This still increase the size of the potential volunteer base but also, puts some safeguard against still being swamped by AI differently (at least our nomination process generally try to make sure collaborators are humans acting in good faith).
Qard commentedon Mar 3, 2026
I have mixed feelings, but I think am overall in support.
The main concern I have is that malicious actors will use this as a free source of automated attack ideas. They can discover this with a bunch of code-scanning with an LLM already, but it's a bunch more work to get. Making the issues public before a fix is available provides an easy signal to consume for automating attack construction.
That having been said, this already happens when our embargo ends anyway, given that most orgs are slow to upgrade their installs. It moves the goal post a bit to make a wider window for doing that, but might be just as helpful for orgs to be made aware of these issues early so they can watch for them, find their own temporary mitigations, and potentially even contribute fixes themselves.
RafaelGSS commentedon Mar 3, 2026
You mean all collaborators to have access to nodejs-private and HackerOne? I'm not sure if folks would be interested in going to reports daily, and I have my doubts that this is different from just making it public on nodejs/node - either we restrict access to nodejs/security-triage team (as it is nowadays) or we don't, IMHO.
I don’t believe this is a major issue. Reports often remain in the fix queue for an extended period, and as noted in the issue, that delay can reduce overall security. During the typical 1–3 month window before a security release, many of these issues could realistically be identified by others using any LLM tool. If report issues and PRs were handled publicly, fixes could follow the regular release process and likely ship much sooner.
joyeecheung commentedon Mar 3, 2026
If the root cause is being swamped by LLM-generated notifications, and their users are motivated to use an agent to do whatever reward this would bring, does it really make that much of a difference for them to change the prompt from "find all vulnerabilities in this threat model" to "find all vulnerabilities in this threat model, and open a PR to fix it"? We will then still need people to triage the PRs and review them and take care of the CI for them, and this subset is still limited to collaborators, so in practice it doesn't seem to make that much of a difference sharing it to public v.s. to collaborators in terms of workforce needed to get them fixed.
Public PRs also commonly stall for months or years for the lack of caretaking, even if their authors are eager. Even if we have more non-collaborators being eager about landing, this will still be bottlenecked by the same number of collaborators who can actually spend time to make it land faster with reviews and CI caretaking. The difference of limiting access to all collaborators v.s. the public is probably primarily that the collaborators will then feel public pressure instead of private pressure, but it's uncertain whether that does do wonders in convincing the volunteers to do more volunteering.
By relaxing the access to all collaborators, we can also relax the Jenkins permissions, I think that also means we can have a more loose embargo (i.e. only restricted to collaborators) and it would also help release/shipping (minus the consideration that heavier load in CI means weakened CI stability to support releasing security fixes). Non collaborators still cannot speed up the CI process, since they don't have access to CI even outside the embargo.
marco-ippolito commentedon Mar 3, 2026
I agree, instead of making it public we should make it accessible to all collaborators
jsumners commentedon Apr 15, 2026
Open reports means anyone with an interest in having them solved can learn about them and provide a solution. I am in favor of this proposal.
bmuenzenmeyer commentedon Jul 15, 2026
An observation in support of the premise
Linus Torvalds spoke at OSS Summit NA in Minneapolis recently, and he observed this very thing, and concluded that these vulnerabilities (and disclosures) are essentially public already.
A question: has anyone at Node.js or Open JS Foundation reached out or learned more of Akrites? I feel like this LF project was made for this moment, helping collectively triage and respond to an influx of reports.
Associate Membership is open to
Recognized open source foundations and projects, at no cost.