Paquetes npm maliciosos detectados en Red Hat Cloud Services

Alcance del incidente

• Se introdujeron paquetes npm maliciosos en los repositorios de clientes JavaScript de Red Hat Cloud Services, al parecer a través de una canalización CI/CD comprometida (GitHub Actions + OIDC), no mediante credenciales estáticas robadas.
• Los paquetes afectados son bibliotecas frontend compiladas dentro de algunas imágenes de contenedor de Red Hat; el impacto parece recaer principalmente en los consumidores de esas imágenes, más que en los usuarios directos de npm.
• Varias análisis (enlazadas en el hilo) enumeran las canalizaciones compartidas y clasifican esto como parte de gusanos npm más amplios de estilo “mini‑Shai-Hulud” / TrapDoor.

¿Es esto un problema de npm o un problema del ecosistema?

• Muchos sostienen que todos los gestores de paquetes modernos de lenguajes (npm, PyPI, crates.io, Composer, NuGet, RubyGems, etc.) comparten el mismo riesgo básico: cualquiera puede publicar, el código se ejecuta con amplia autoridad y los mantenedores suelen ser individuos.
• Otros dicen que npm es peor debido a:
  • Scripts de ciclo de vida/postinstall que ejecutan código arbitrario durante la instalación de forma predeterminada.
  • Gráficos de dependencias enormes y profundamente anidados, y una cultura de muchos paquetes diminutos.
  • Normas de rápido movimiento de “actualiza siempre a la última versión”.
• Contrapunto: los ganchos de ciclo de vida y funciones similares existen en muchos sistemas (dpkg/rpm, RubyGems, Pip, NuGet), así que algunos ven injusto o sesgado culpar solo a npm.

Mitigaciones propuestas

• Períodos de enfriamiento de dependencias (1–7 días) para evitar instalar versiones publicadas recientemente, apoyándose en escáneres y mantenedores para detectar malware dentro de esa ventana. Compatible con pnpm, Yarn 4, npm 11, pip, uv, y mediante herramientas de terceros.
  • Partidarios: barato, eficaz en ataques recientes que se detectaron en horas/días.
  • Escépticos: si todos retrasan las actualizaciones, los atacantes pueden añadir bombas de tiempo; aun así hay que gestionar CVEs urgentes.
• Fortalecimiento de CI/CD:
  • Separar los trabajos de “build/test” de los de “sign/release” para que los gusanos no puedan republicar automáticamente.
  • Usar publicadores de confianza, MFA y publicación escalonada; pero esto no ayuda si la propia CI está comprometida.
• Reducción del radio de explosión:
  • Ejecutar instalaciones/pruebas dentro de contenedores, sandboxes o entornos con menos privilegios.
  • Evitar usar máquinas de desarrollo que también contengan claves o wallets sensibles.
• Gobernanza y modelos de empaquetado:
  • Llamadas a emular a las distribuciones Linux: mantenedores curados, capas de revisión, canales más lentos (testing/unstable).
  • Sugerencias de incorporar dependencias, fijar versiones exactas, evitar bibliotecas innecesarias y preferir ecosistemas con gráficos de dependencias más planos y pequeños.

Críticas culturales

• Varios comentarios culpan a la cultura JavaScript/Web: paquetes diminutos, cambios rápidos, dependencias transitivas profundas y fuerte dependencia de actualizaciones automáticas.
• Otros subrayan que a los usuarios les importa más la comodidad que la seguridad hasta que algo falla; la seguridad se ve como un requisito invisible que a menudo se añade tarde.