Utilizamos inteligencia artificial para traducir el sitio web y, aunque nos esforzamos por garantizar la precisión, es posible que las traducciones no sean siempre 100 % exactas. Agradecemos tu comprensión.
Inicio/
Blog
/
De Dune a npm: el gusano Shai-Hulud redefine…
De «Dune» a npm: el gusano Shai-Hulud redefine Supply Chain
Por
OPSWAT
|
Última actualización:
Comparte esta publicación
Los seguidores de «Dune» reconocerán «Shai-Hulud» como el nombre que se le da a los colosales gusanos de arena que remodelan el desierto con su fuerza imparable. Ahora, la comunidad de código abierto se enfrenta a una ciberamenaza igualmente formidable. El 15 de septiembre, la comunidad de software de código abierto se enfrentó a una de sus crisis más devastadoras hasta la fecha: un gusano autorreplicante, conocido como Shai-Hulud, se propagó por el ecosistema de npm, comprometiendo más de 180 paquetes en cuestión de horas.
Bibliotecas de confianza como @ctrl/tinycolor, crowdstrike-nodejs, string-kit, json-sugar, photon-colors , y las ramificaciones de typed.js y fecha y hora ya se ven afectadas. Con millones de descargas cada semana, las organizaciones están introduciendo, sin saberlo, infecciones activas directamente en sus procesos de compilación.
El gusano aprovecha los ganchos del ciclo de vida de npm para robar credenciales de GitHub y de la nube pública, y luego utiliza esos datos confidenciales para publicar actualizaciones maliciosas en otros proyectos.
Flujo del ataque
Una versión comprometida de @ctrl/tinycolor inyecta un script malicioso local (bundle.js).
El script bundle.js descarga y ejecuta TruffleHog para buscar secretos de GitHub en el equipo de la víctima.
Utilizando los secretos de GitHub descubiertos, el script enumera los repositorios a los que tiene acceso (ya sea como propietario, colaborador o miembro de la organización).
Para cada repositorio, recupera la rama predeterminada y crea una shai-hulud rama y sube un archivo de flujo de trabajo a .github/workflows/shai-hulud-workflow.yml .
El flujo de trabajo está configurado para activarse con eventos de envío. El ejecutor de GitHub Actions ejecuta el trabajo en el contexto del repositorio, que tiene acceso a los secretos.
El flujo de trabajo lee los secretos de GitHub y los envía a un punto final controlado por el atacante.
Por qué es importante ahora y a largo plazo
El código abierto es abierto por naturaleza. El registro de npm gestiona cientos de miles de millones de descargas cada mes, y cualquiera puede publicar un paquete. Esa apertura impulsa la innovación, pero también brinda a los atacantes la oportunidad de aprovecharse de la confianza a gran escala.
El brote pone de manifiesto una realidad ineludible: la confianza no es eterna. Un paquete que hoy es seguro puede verse comprometido mañana.
El presente frente al futuro: el equilibrio entre la automatización y la intervención humana
Ahora: Respuesta inmediata
Siguiente: Resiliencia a largo plazo
Auditoría npm depender de artefactos y analizarlos con varios motores.
Trata todos los paquetes como si no fueran fiables hasta que se demuestre que son seguros (por ejemplo, MetaDefender Software Supply Chain similares). Automatiza el análisis de artefactos para todos los paquetes.
Los desarrolladores detienen las instalaciones automáticas y comprueban manualmente las fuentes de las dependencias.
Los equipos de seguridad revisan periódicamente los paquetes de alto riesgo y avisan a sus superiores cuando detectan alguna anomalía.
Evita instalar la última versión automáticamente; especifica las versiones exactas y actualiza solo tras haberlas comprobado: npm install <package name>@<package version>
Gestores Secure : uso pnpm o npm.
Instalar con --ignorar-scripts para bloquear los scripts de postinstalación que supongan un riesgo.
Aplazar y verificar las actualizaciones – p. ej., edad mínima para la venta + Auditoría de pnpm.
Revocar y rotar los secretos expuestos.
Aplicar políticas de rotación automatizadas y configuraciones predeterminadas basadas en el principio del privilegio mínimo.
Los equipos de seguridad evalúan los usos sospechosos de las credenciales y determinan las medidas de contención.
Los directivos establecen normas de gobernanza y garantizan la rendición de cuentas para fomentar la confianza en la cadena de suministro.
Aplicar la autenticación de dos factores (MFA) y las comprobaciones de firmas en CI/CD.
Exigir que todas las versiones cuenten con confirmaciones firmadas y un historial de compilación verificable.
Los responsables deciden cuándo ralentizar la entrega para proteger la integridad.
Los consejos de administración consideran la confianza en el software como una cuestión estratégica de resiliencia, no como un mero trámite de cumplimiento normativo.
Una visión más amplia
Para los directivos, este ataque sirve de recordatorio de que el riesgo de la cadena de suministro de software es un riesgo para la empresa. Las autoridades reguladoras exigen controles verificables y los clientes esperan pruebas de integridad. Los consejos de administración ya no pueden eludir la responsabilidad sobre el código que sustenta las operaciones críticas.
Para los profesionales, este brote pone de manifiesto que los procesos deben evolucionar. Toda dependencia de código abierto debe considerarse no fiable hasta que se demuestre su seguridad. Las listas de materiales de seguridad (SBOM), los análisis de malware y la depuración constituyen la base, pero es la atención humana —detener, cuestionar, escalar— lo que evita que la automatización ciega introduzca el próximo virus.
La perspectiva OPSWAT
Fomentar Supply Chain
Incidentes como los ataques a la cadena de suministro en entornos de código abierto, como npm, demuestran que las cadenas de suministro de software se han convertido en cargas de trabajo críticas. El sector debe pasar de la confianza ciega a la confianza verificable.
George Prichici
Vicepresidente de Productos, OPSWAT
En OPSWAT, creemos que la confianza en la cadena de suministro debe construirse, no darse por sentada. Nuestro enfoque se centra en la defensa en profundidad:
Visibilidad completa de la cadena de suministro de software con integración de la lista de materiales de software (SBOM) para realizar un seguimiento de cada componente de software, identificar vulnerabilidades, gestionar los riesgos a lo largo del ciclo de vida del desarrollo de software (SDLC) y verificar la procedencia en cada etapa.
Multiscanning más de 30 motores para detectar malware polimórfico y otros tipos de malware en paquetes, especialmente en software de código abierto de terceros.
SandboxAdaptive : análisis basado en inteligencia artificial que detecta rápidamente incluso el malware más difícil de detectar.
ControlesSecure y transferenciaSecure que garantizan los límites de confianza en los procesos de CI/CD.
Estos controles no solo detectan riesgos, sino que también limpian activamente los archivos y garantizan la fiabilidad, lo que reduce la probabilidad de que incidentes como este se propaguen a niveles posteriores.
El desarrollo rápido y la seguridad sólida no son incompatibles. Los equipos de desarrollo necesitan procesos automatizados de análisis y aprobación integrados en la cadena de suministro de software para poder proteger el código sin ralentizar el ritmo.
George Prichici
Vicepresidente de Productos, OPSWAT
Seguridad que se adapta al ritmo del desarrollo
Con OPSWAT, la seguridad se integra directamente en los flujos de trabajo existentes:
Integración de procesos de CI/CD: análisis automatizados y aplicación de políticas en Jenkins, GitHub Actions, GitLab y otros entornos de compilación. Validación de paquetes npm, contenedores y binarios como parte de los pasos rutinarios de compilación.
Generación y validación de SBOM bajo demanda: genera y verifica automáticamente las listas de materiales (SBOM) para cada versión, garantizando la trazabilidad sin costes adicionales.
Experiencia transparente para los desarrolladores: la seguridad funciona en segundo plano y solo señala los problemas cuando es realmente necesario intervenir.
Ganchos de corrección automatizada: pon en cuarentena o limpia los archivos comprometidos sin interrumpir las compilaciones.
Una cultura de desarrollo centrada en la rapidez no tiene por qué entrar en conflicto con las comprobaciones de seguridad necesarias; los procesos automatizados de análisis y aprobación deberían ser imprescindibles, con un impacto mínimo en la velocidad de desarrollo.
Al integrar estas capacidades en el ciclo de vida del software, OPSWAT las organizaciones OPSWAT lograr tanto rapidez en el desarrollo como una confianza verificable, un equilibrio que, como demuestra el incidente de npm, resulta ahora esencial.
El gusano Shai-Hulud de npm es una clara señal de las amenazas que acechan al software en la actualidad. Los atacantes no necesitan infiltrarse en tu código. Pueden convencerte para que los instales tú mismo. Verifica cada artefacto, integra la resiliencia en cada etapa y capacita a las personas para que actúen cuando la automatización por sí sola no sea suficiente. Las organizaciones que se tomen esto en serio ahora marcarán el futuro de las cadenas de suministro de software seguras.
¿Está listo para proteger su cadena de suministro de software frente a las últimas ciberamenazas con soluciones personalizadas y perfectamente integradas?
