---
title: Reportes de Seguridad
layout: about
---

# Reportes de Seguridad

Para más detalles de las Políticas de Seguridad activas, revise esta [página](https://github.com/nodejs/node/security/policy).

## Reportando errores en Node.js

Reporta errores de seguridad de Node.js atreves de [HackerOne](https://hackerone.com/nodejs).

Normalmente, la confirmación de recepción de los informes suele tardar hasta 5 días. Dentro de 10 días, se puede esperar una respuesta más detallada que indica los pasos siguientes. Se pueden alargar estos plazos cuando nuestros voluntarios de clasificación están de vacaciones, como el fin del año.

Después de la respuesta inicial a tu informe, el equipo de seguridad se esforzará por mantenerte informado sobre el progreso hacia una solución y el anuncio completo, y puede solicitar información adicional u orientación sobre el problema reportado.

### Programa de recompensas por errores de Node.js

El proyecto Node.js participa en un programa oficial de recompensas por errores para investigadores de seguridad y divulgaciones públicas responsables. El programa se gestiona a través de la plataforma HackerOne. Consulte [https://hackerone.com/nodejs](https://hackerone.com/nodejs) por más detalles.

## Reportar un error en un módulo de terceros

Los errores de seguridad dentro de módulos de terceros deben ser reportados a sus respectivos
mantenedores.

## Política de divulgación

Aquí está la política de divulgación de seguridad para Node.js:

- El informe de seguridad es recibido y se asigna a un responsable principal. Esta persona coordinará el proceso de corrección y lanzamiento. El problema es convalidada en cada versión de Node.js soportada. Una vez confirmado se determina una lista de todas las versiones afectadas. Se audita el código para encontrar posibles problemas similares. Se preparan correcciones para todas las versiones soportadas. Estas correcciones no se comprometen al repositorio público, sino que se mantienen localmente a la espera del anuncio.

- Se elige una fecha de embargo sugerida para esta vulnerabilidad y un CVE (Vulnerabilidades y Exposiciones Comunes (CVE®)) será solicitado para la vulnerabilidad.

- En la fecha de embargo, se envía una copia del anuncio a la lista de correo de seguridad de Node.js. Los cambios se suben al repositorio público y se despliegan nuevas versiones en nodejs.org. Dentro de las 6 horas posteriores a que se notifique a la lista de correo, se publicará una copia del aviso en el blog de Node.js.

- Típicamente la fecha de embargo será fijada 72 horas desde la creación del CVE. Sin embargo, esto puede variar dependiendo de la severidad del error o la dificultad en aplicar la solución.

- Este proceso puede durar algún tiempo, en particular cuando requiere coordinación con mantenedores de otros proyectos. Nos esforzamos por resolver el problema con prisa; sin embargo, debemos seguir este proceso de lanzamiento para asegurar que las divulgaciones se manejan uniformemente.

## Recibiendo actualizaciones de seguridad

Las notificaciones de seguridad se distribuirán mediante los siguientes métodos.

- [Grupo de Google](https://groups.google.com/group/nodejs-sec)
- [Blog de Node.js](/blog)

## Comentarios sobre esta política

Si quieres recomendar ideas para mejor este proceso, por favor visita el repositorio [nodejs/security-wg](https://github.com/nodejs/security-wg).

## Mejores Prácticas de la OpenSSF

<a
  href="https://bestpractices.coreinfrastructure.org/projects/29"
  style={{ display: 'inline-flex' }}
>
  <img
    alt="Insignia OpenSSF"
    src="https://bestpractices.coreinfrastructure.org/projects/29/badge"
    style={{ display: 'inline' }}
  />
</a>

La [Insignia de Buenas Prácticas](https://github.com/coreinfrastructure/best-practices-badge) de la Fundación de Seguridad del Software Abierto (OpenSSF) es una manera en que los proyectos de Software Libre y de Código Abierto (FLOSS) pueden mostrar que siguen las mejores prácticas. Los proyectos pueden auto-certificarse voluntariamente sobre cómo siguen cada buena práctica. Los consumidores de la insignia pueden evaluar rápidamente qué proyectos FLOSS siguen las mejores prácticas y, como resultado, tienen más probabilidades de producir software seguro de alta calidad.
