Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Proposal: Moving security reports to a public workflow

Abierto
  • ¿Algo no está bien?
#1,826 13 comentarios 7 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Tranquilo
Stack tecnológico
javascript, node.js
Área
security

Línea de trabajo

Empieza por SECURITY.md y el anuncio de HackerOne enlazado sobre los requisitos de señales para entender el modelo de amenazas actual, las reglas de notificación y la ruta de escalación. Revisa la discusión y define qué tendría que cubrir un flujo de trabajo público, incluidos los informes poco frecuentes que requieren un embargo; se considerará terminado cuando el proyecto haya acordado y documentado un proceso sostenible.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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

Lenguaje dominante
JavaScript
Estrellas
693
Forks
142
Merge medio
8 d 7 h
PR fusionados (30 d)
3

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de nodejs/TSC

Todos los issues de nodejs/TSC

Issues similares

Más issues de JavaScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.