En los últimos días se han reportado ataques de supply chain npm y Python que involucran paquetes distribuidos a través de ecosistemas de desarrollo. La preocupación principal es que versiones manipuladas pueden dar a atacantes acceso a entornos de TI y a datos sensibles, especialmente si tu organización utiliza librerías de terceros en sus procesos de construcción y despliegue.
Si desarrollas software y empleas dependencias de npm o de paquetes de Python (por ejemplo, desde PyPI), conviene actuar con rapidez: revisa posibles indicadores de compromiso, reduce el impacto mediante rotación de credenciales y refuerza las prácticas para evitar que una actualización comprometida vuelva a colarse.
Qué está pasando con los paquetes de npm y Python
npm es un gestor de paquetes utilizado para Node.js, un entorno muy usado para construir aplicaciones. En estos incidentes, se vieron comprometidos tanto paquetes de npm como paquetes de Python, de modo que un atacante puede introducir malware dentro de un componente que, en apariencia, es legítimo.
La mecánica es especialmente riesgosa: el paquete malicioso se distribuye como si fuera una actualización o parte normal del software. Así, en vez de atacar directamente tu infraestructura, el adversario apunta al eslabón de confianza: la dependencia externa.
Casos destacados: Trivy, axios y el movimiento de malware
Uno de los ejemplos mencionados en el aviso se relaciona con Trivy, una herramienta de seguridad y exploración que se utiliza en entornos, incluyendo aplicaciones Node.js. El 19 de marzo, se reportó que atacantes obtuvieron acceso indebido a la instancia de desarrollo de Trivy. Posteriormente, se distribuyó una versión alterada que permitiría acceder a datos sensibles de autenticación.
Además, se indicó que se añadieron backdoors, es decir, mecanismos para ejecutar comandos de forma remota en sistemas comprometidos. Para completar el ciclo, con los datos de autenticación capturados se intentó propagar CanisterWorm-malware, que exfiltra credenciales desde entornos de desarrollo y luego busca comprometer paquetes adicionales.
De acuerdo con reportes de seguridad, tras el compromiso inicial de Trivy se llegó a observar al menos un conjunto de npm-packages afectados mediante esta vía; el número real podría ser significativamente mayor. También se mencionan posibles compromisos de versiones de librerías de Python como LiteLLM y Telnyx siguiendo un procedimiento similar.
Otro caso señalado es axios, una librería muy utilizada para comunicarse mediante HTTP. A finales de marzo se informó que axios en npm habría sido comprometido: se habrían agregado componentes maliciosos a una versión legítima, de manera que el malware se distribuya como actualización del paquete.
Por qué el riesgo es alto en entornos de desarrollo
El impacto no se limita a “tener un paquete sospechoso”. Si tu organización integra un paquete comprometido en su software, los atacantes pueden obtener acceso a credenciales y, a partir de ellas, entrar en otros entornos (por ejemplo, entornos de desarrollo o sistemas dentro de la red).
También hay consecuencias para usuarios finales: si las puertas traseras (o funciones maliciosas) se incorporan a tu software, podrían quedar presentes en la aplicación distribuida.
El aviso incluye una indicación de que la información obtenida podría usarse para exfiltración de datos (potencialmente sensibles). Desde ahí, el escenario podría escalar a chantaje: publicar datos en internet si no se cumple una exigencia de rescate. Alternativamente, los datos robados podrían revenderse a otros cibercriminales, quienes aprovecharían credenciales para ataques posteriores.
Señales a revisar en tu entorno
El primer paso recomendado es comprobar si tu entorno de desarrollo contiene elementos que puedan apuntar a una intrusión. Se mencionan como referencia ciertos paquetes y versiones, porque su presencia puede ser un indicio de compromiso.
Paquetes y versiones para comprobar
- Trivy versión 0.69.4
- axios versiones 1.14.1 y 0.30.4
Importante: incluso si no utilizas esas dependencias específicas, el atacante podría haber llegado a tu entorno mediante otro paquete comprometido. Por eso, también se recomienda revisar indicadores de compromiso (IOC) que han sido compartidos por equipos de seguridad. Si encuentras esos IOC en tus sistemas, debes considerarlo una señal de posible compromiso y actuar en consecuencia.
Qué hacer si sospechas compromiso
Si identificas indicios de que tu entorno podría estar comprometido, la respuesta debe ser rápida y ordenada.
- Activa tu proceso de respuesta a incidentes (IR). Si no tienes personal especializado o necesitas acelerar el análisis, considera involucrar un proveedor de servicios de respuesta ante incidentes.
- Rota todas las credenciales, tokens y datos de autenticación que el atacante podría haber usado. No basta con cambiar una sola clave: trata el incidente como potencialmente transversal.
- Informa a tus clientes cuando corresponda, para que puedan aplicar medidas de protección en sus propios entornos.
Este enfoque busca cortar el acceso y reducir el margen de daño, mientras se determina el alcance real del incidente.
Medidas preventivas para reducir el riesgo
Una vez que atiendes el posible impacto, el objetivo es evitar que incidentes similares vuelvan a ocurrir. El aviso reúne varias recomendaciones prácticas que encajan bien en equipos que construyen y despliegan software con dependencia de terceros.
1) Versionado y controles de integridad
Utiliza pinning de versiones cuando tu software dependa de librerías externas. Cuando sea posible, en lugar de basarte solo en números de versión, intenta fijar hashes de las librerías para disminuir la probabilidad de descargar una variante comprometida.
2) Ajusta el ritmo de actualizaciones
La recomendación incluye una cooldown period (un periodo de espera) para actualizaciones de dependencias. La idea es: aplica actualizaciones críticas de seguridad con rapidez, pero considera retrasar algunas actualizaciones “regulares” durante unos días cuando sea viable.
3) Reduce el riesgo de scripts en instalación
Los postinstall scripts pueden ser un punto de abuso. Una medida citada es deshabilitarlos al instalar dependencias, por ejemplo usando el parámetro “–ignore-scripts” en el comando npm ci.
4) Inspecciona en CI/CD
Integra herramientas de escaneo para entornos de CI/CD y así detectar actualizaciones y paquetes maliciosos antes de que pasen a etapas posteriores del pipeline.
5) Confía solo en publicadores verificados y usa auditorías
Procura utilizar paquetes de trusted publishers. Además, emplea el comando npm audit para comprobar autenticidad y revisar posibles alertas de seguridad en dependencias.
6) Publicación segura con OpenID Connect
Para quienes publican paquetes, se aconseja implementar npm Trusted Publishing mediante OpenID Connect (OIDC), en lugar de depender de un token fijo como NPM_TOKEN. La finalidad es minimizar el riesgo de robo o uso indebido de credenciales de publicación de larga duración.
Resumen: actúa con criterio y refuerza tu cadena
La supply chain npm y Python se ha convertido en un vector real para comprometer credenciales, introducir puertas traseras y facilitar exfiltración de datos. Si tu organización desarrolla software con dependencias de npm o Python, revisa las versiones y señales recomendadas, activa respuesta ante incidentes si detectas indicios y rota credenciales de inmediato.
Después, fortalece tu proceso de desarrollo con controles como pinning, políticas de actualización, desactivación de scripts no necesarios, escaneo en CI/CD y auditorías. Con estas acciones, reduces la probabilidad de que una actualización comprometida afecte tu infraestructura y la de tus usuarios.
Fuente: https://www.ncsc.nl/alerts/ontwikkelaars-opgelet-gecompromitteerde-npm-en-python-packages
