Productos FTTH

Tienda FFTH desde 2004

Entradas Mensuales

Síguenos en:

Canal Oficial Telegram de elhacker.NET Grupo Facebook elhacker.NET Twitter elhacker.NET Canal Youtube elhacker.NET Comunidad Steam: Grupo elhacker.NET Mastodon

Entradas populares

PostHeaderIcon GitHub añade publicación escalonada a npm para bloquear ataques de cadena de suministro


GitHub ha implementado una mejora de seguridad significativa en el ecosistema npm mediante la disponibilidad general de publicaciones escalonadas (staged publishing) y nuevos controles durante la instalación. El objetivo principal de estas medidas es reducir los ataques automatizados a la cadena de suministro que afectan a los paquetes de código abierto, cambiando la forma en que se publican y distribuyen los paquetes para evitar que estén disponibles de manera inmediata y sin control tras su publicación.




GitHub ha introducido una actualización de seguridad importante para el ecosistema npm con la disponibilidad general de la publicación por etapas y nuevos controles en el momento de la instalación, destinados a reducir los ataques automatizados a la cadena de suministro dirigidos a paquetes de código abierto.

La función de publicación por etapas, recién lanzada, cambia la forma en que se publican y distribuyen los paquetes de npm.

En lugar de hacer que un paquete esté disponible inmediatamente después de publicarlo, npm ahora coloca el archivo tarball del paquete precompilado en una cola de espera.

Un mantenedor humano debe aprobar explícitamente el paquete antes de que sea instalable públicamente.

GitHub añade el estado de espera (staging) a npm

Este enfoque introduce un punto de control de seguridad crítico, especialmente para los flujos de trabajo automatizados de CI/CD que suelen ser el objetivo de los ataques a la cadena de suministro.

Incluso si un atacante compromete un pipeline o inyecta código malicioso, el paquete no puede ser lanzado sin una aprobación manual.

Los beneficios clave de seguridad incluyen:

  • Aprobación humana obligatoria aplicada con autenticación de dos factores (2FA).
  • Visibilidad de los paquetes en espera a través de la CLI de npm y npmjs.com.
  • Protección contra intentos de publicación no autorizados o automatizados.
  • Prueba de presencia reforzada para los mantenedores durante el lanzamiento.

La función está disponible a partir de la versión 11.15.0 de la CLI de npm y requiere que cambies el comando tradicional npm publish por npm stage publish para los flujos de trabajo por etapas.

GitHub recomienda combinar la publicación por etapas con la publicación confiable utilizando OpenID Connect (OIDC).

Esta configuración permite que los sistemas de CI/CD publiquen paquetes directamente en la cola de espera sin exponer credenciales de larga duración.

Las organizaciones pueden imponer políticas de publicación únicamente por etapas, asegurando que:

  • Se rechacen los comandos directos de npm publish.
  • Solo se permita npm stage publish desde los pipelines de CI.
  • La aprobación final sea completada por un mantenedor en un dispositivo de confianza.

Este modelo reduce significativamente el riesgo de robo de credenciales y lanzamientos maliciosos automatizados.

Además de la publicación por etapas, GitHub ha introducido nuevas banderas (flags) de seguridad al momento de la instalación en npm 11.15.0.

Estas banderas proporcionan un control granular sobre dónde se pueden instalar las dependencias, ayudando a prevenir fuentes maliciosas o inesperadas.

Las nuevas banderas incluyen:

  • --allow-file: Controla las instalaciones desde archivos locales o tarballs.
  • --allow-remote: Restringe las dependencias obtenidas de URLs remotas.
  • --allow-directory: Gobierna las instalaciones desde directorios locales.
  • --allow-git (existente): Controla las instalaciones desde repositorios Git.

Cada bandera admite dos modos: all (predeterminado) o none, y se puede configurar a través de .npmrc o package.json.

Estos controles te permiten implementar políticas estrictas de listas blancas, reduciendo la superficie de ataque de fuentes que no pertenecen al registro y que a menudo se utilizan en ataques de inyección o confusión de dependencias.

Impacto en la seguridad

GitHub también confirmó que en la versión 12 de la CLI de npm, el comportamiento predeterminado para --allow-git cambiará de all a none, señalando un cambio hacia configuraciones de seguridad predeterminadas más estrictas.

Se te anima a adoptar estas restricciones pronto configurando manualmente las nuevas banderas.

Por ejemplo, una organización puede configurar su entorno para bloquear todas las instalaciones que no provengan del registro:

  • Establecer --allow-remote=none
  • Establecer --allow-file=none
  • Establecer --allow-directory=none
  • Permitir solo paquetes del registro de confianza

Combinado con la publicación por etapas, esto crea un pipeline controlado donde tanto la creación como el consumo de paquetes están estrechamente asegurados.

Estas actualizaciones abordan directamente los vectores comunes de ataque a la cadena de suministro, incluyendo:

  • Inyección de código malicioso en pipelines de CI/CD.
  • Confusión de dependencias a través de fuentes externas.
  • Publicación de paquetes no autorizada.

Al introducir la validación humana y controles de dependencias más estrictos, GitHub está moviendo a npm hacia un modelo de cadena de suministro de confianza cero (zero-trust).

Se recomienda encarecidamente a las organizaciones que utilicen npm actualizar a la CLI de npm 11.15.0 o posterior y actualizar sus flujos de trabajo para aprovechar plenamente estas nuevas protecciones.



Fuentes:
https://cybersecuritynews.com/github-adds-staged-publishing-to-npm-to-block-automated-supply-chain-attacks/

0 comentarios :

Publicar un comentario

Los comentarios pueden ser revisados en cualquier momento por los moderadores.

Serán publicados aquellos que cumplan las siguientes condiciones:
- Comentario acorde al contenido del post.
- Prohibido mensajes de tipo SPAM.
- Evite incluir links innecesarios en su comentario.
- Contenidos ofensivos, amenazas e insultos no serán permitidos.

Debe saber que los comentarios de los lectores no reflejan necesariamente la opinión del STAFF.