Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

Proposal: Moving security reports to a public workflow

Aberta
  • Algo errado?
#1,826 13 comentários 7 reações 0 responsáveis Ver no GitHub

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
35/100
Tipo de issue
Funcionalidade
Clareza
Precisa de esclarecimento
Status de atividade
Pouca atividade
Stack de tecnologia
javascript, node.js
Domínio
security

Direção de pesquisa

Comece por SECURITY.md e pelo anúncio vinculado da HackerOne sobre os requisitos de sinalização para entender o modelo de ameaças atual, as regras de reporte e o caminho de escalonamento. Revise a discussão e defina o que um fluxo de trabalho público precisaria abranger, incluindo os relatos raros que exigem um embargo; considera-se concluído quando o projeto tiver acordado e documentado um processo sustentável.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

security-wg-agenda

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:

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

Linguagem predominante
JavaScript
Estrelas
693
Forks
143
Merge médio
8d 7h
PRs com merge (30d)
3

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de nodejs/TSC

Todas as issues de nodejs/TSC

Issues semelhantes

Mais issues de JavaScript

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.