En el segundo trimestre de 2026, Aikido Intel analizó alrededor de 7,5 millones de versiones de paquetes. Entre nuestros sistemas automatizados y nuestros investigadores humanos, confirmamos la existencia de 19 500 paquetes maliciosos. Los atacantes han estado aprovechando las dependencias de código abierto para infiltrarse en el software, y ataques a la cadena de suministro comenzó a experimentar un fuerte aumento a mediados de 2025. Paquetes populares como axios y herramientas de seguridad como Trivy y Checkmarx se vieron comprometidos.
Esta guía repasa las mejores prácticas de seguridad en la cadena de suministro que habrían impedido los ataques de los últimos 18 meses. Si quieres profundizar más, echa un vistazo a la lista de comprobación práctica para protegerte contra ataques a la cadena de suministro. La lista de comprobación práctica completa abarca 30 controles relacionados con los contenedores, el refuerzo de la infraestructura de código (CI) y mucho más, clasificados por orden de prioridad para que sepas por dónde empezar.
{{cta}}
Detén el malware antes de que se instale
Aplicar una antigüedad mínima del paquete de 48 horas
Un periodo de espera bloquea cualquier versión publicada recientemente. La mayoría de las versiones comprometidas se marcan y se retiran a las pocas horas de su publicación, lo que significa que el filtro de 48 horas las detecta. El filtro establece un intervalo de tiempo entre la publicación y la adopción. Aplícalo en el registro privado o en el gestor de paquetes. npm tiene edad mínima de lanzamiento desde la versión 11.10.0, y tanto Yarn como Bun incluyen sus propios controles de edad.
Bloquear los hooks posteriores a la instalación con «ignore-scripts»
No es necesario utilizar un paquete para que se ejecute código en tu equipo; basta con instalarlo. Cuando ejecutas «npm install», npm ejecuta cualquier script de postinstalación que haya escrito el autor del paquete con tus privilegios. Para desactivar los scripts de instalación, utiliza --ignore-scripts e incluye en la lista de permitidos los pocos paquetes que realmente necesitan compilar algo. Aplica la misma configuración en la integración continua (CI) y en los equipos de los desarrolladores, para detectar las credenciales almacenadas en el portátil.
Los parámetros predeterminados del ecosistema van por buen camino
pnpm desactivó por defecto los scripts de instalación de dependencias en la versión 10, en enero de 2025, y posteriormente activó por defecto un periodo de espera de 24 horas en v11 en abril de 2026. npm v12 Se lanzó el 8 de julio de 2026 con los scripts de instalación de dependencias desactivados por defecto, aunque tus propios scripts siguen ejecutándose, y no tiene ningún tiempo de espera predeterminado, por lo que aún puedes configurar edad mínima de lanzamiento Tú mismo. Actualizar tu gestor de paquetes es la forma más económica de cubrir parte de ambos controles. Los equipos que utilicen versiones anteriores u otros ecosistemas necesitan la configuración explícita indicada anteriormente. Lo que un periodo de espera habría evitado
El axios El atacante publicó un señuelo legítimo, plain-crypto-js@4.2.0, el 30 de marzo, y luego sustituyó el archivo malicioso plain-crypto-js@4.2.1 a las 23:59 UTC. El sistema de detección automática lo detectó seis minutos después. axios@1.14.1 se puso en marcha a las 00:21 UTC del 31 de marzo, y axios@0.30.4 A continuación, a la 01:00, npm retiró ambas versiones de Axios unas tres horas después de que se publicara la primera. Un plazo de 48 horas habría evitado que los equipos tuvieran que lidiar con ninguna de las dos, dejándoles unas 45 horas de margen.
CanisterWorm volvió a publicar versiones de parches incrementadas de todos los paquetes que mantenían sus víctimas, llegando a más de 60 paquetes en 24 horas. La mayoría fueron detectados a los pocos minutos de su publicación, por lo que un filtro de 48 horas los habría mantenido fuera de tu resolutor. Al menos uno pasó desapercibido durante unas 53 horas, razón por la cual el filtro funciona mejor junto con la detección de malware durante la instalación.
Fija todo lo que pueda salir a la deriva
Guarda un archivo de bloqueo y aplícalo en tu pipeline
Un archivo de bloqueo recoge la versión exacta y el hash de integridad de cada dependencia, incluidas las transitivas. Aplicarlo significa que tu pipeline ejecuta «npm ci» en lugar de «npm install», ya que «npm ci» realiza la instalación siguiendo estrictamente el archivo de bloqueo y falla directamente si el archivo «package.json» se ha desviado de él. Todos los demás ecosistemas cuentan con el mismo modo, aunque con un nombre diferente, como --archivo-de-bloqueo-congelado en pnpm, --inmutable en Yarn, --bloqueado en «Cargo», y --require-hashes en pip. Haz que sea una comprobación obligatoria antes de la fusión, para que el control se aplique a todo el equipo.
Fija tu pipeline a los SHA de las confirmaciones
Todas las plataformas de integración continua (CI) permiten incorporar dependencias y, en la mayoría de los casos, se hace referencia a ellas mediante una etiqueta o el nombre de una rama. Ambos son punteros que quien controle el repositorio de código fuente puede modificar en cualquier momento. Fijarlo a un SHA de commit elimina la posibilidad de desviaciones, ya que un SHA hace referencia a un árbol de código específico y no se puede reorientar. GitHub Actions, GitLab, Buildkite y Jenkins aceptan uno en lugar de una etiqueta. CircleCI funciona de forma diferente, ya que las versiones de orb publicadas son inmutables una vez lanzadas, por lo que basta con una versión exacta.
El inconveniente es que dejarás de recibir automáticamente las correcciones de la cadena de suministro, así que combina esta solución con un bot que abra PR para actualizar el SHA. Renovate gestiona, entre otros, Actions y GitLab, y puede realizar por ti la conversión inicial de etiquetas a SHA. Dependabot Mantiene actualizadas las acciones fijadas existentes, pero solo es compatible con GitHub Actions.
Añadir imágenes de base a los resúmenes
Una etiqueta de imagen de contenedor también es un puntero mutable. «node:22-alpine» apunta este mes a una imagen diferente a la del mes pasado, y en tu Dockerfile no hay nada que indique con cuál la compiles.
Fija la línea «FROM» a un resumen para que la compilación sea reproducible y los cambios del desarrollador original requieran tu aprobación. A continuación, programa una recompilación automática, ya que fijar un resumen también implica que dejarás de recibir parches del desarrollador original hasta que lo modifiques deliberadamente.
¿Qué medida habría evitado que...
En marzo de 2025, los atacantes han comprometido el tj-actions/changed-files Se tomaron medidas y se reasignaron todas las etiquetas de versión a una confirmación maliciosa que volcaba secretos de CI en los registros del flujo de trabajo. Aproximadamente 23 000 repositorios hacían referencia a ella y, en los repositorios públicos, cualquiera podía leer esos registros.
Todos los flujos de trabajo que hacían referencia a una etiqueta descargaban el código malicioso en su siguiente ejecución. Los repositorios que tenían fijado el SHA de una confirmación no se vieron afectados.
Controlar el acceso y la identidad
Tokens de ámbito
Un token con derechos de publicación para toda la organización es peligroso, ya que quien lo obtenga podrá publicar cualquier cosa que sea de tu propiedad. Utiliza tokens con permisos más específicos, limitados a repositorios y paquetes concretos, y emite una credencial independiente para cada pipeline en lugar de compartir una misma credencial entre los runners y las máquinas. Renuévalas según un calendario definido y de forma inmediata ante cualquier sospecha, y revócalas en cuanto alguien abandone un proyecto.
Un desarrollador de CrowdSec que ya no trabajaba en la empresa conservó el acceso a GitHub para terminar algunos trabajos, y su ordenador portátil se vio afectado por el ataque a TanStack. Un atacante utilizó el token de ese equipo para clonar 170 de los repositorios privados de CrowdSec en unos nueve minutos. La empresa se enteró cuatro meses después, cuando el código apareció en un foro.
Migrar las cuentas de los administradores a FIDO2 o a claves de acceso
Una contraseña de un solo uso basada en el tiempo (TOTP) es mejor que nada, pero es vulnerable al phishing. Un atacante captura el código en una página de inicio de sesión falsa muy convincente y lo reproduce en el sitio web auténtico dentro del plazo de treinta segundos, lo cual es suficiente para hacerse con el control de la cuenta sin necesidad de utilizar malware. FIDO2 y las claves de acceso están vinculadas criptográficamente al dominio legítimo. Si mantienes un paquete de uso generalizado, mantén actualizado el correo electrónico de la cuenta y vigílalo, ya que npm bloquea las cuentas de alto impacto durante 72 horas tras un cambio de correo electrónico o una recuperación de la autenticación de dos factores (2FA) y envía la alerta a la dirección anterior.
Trata el equipo de desarrollo como si fuera un entorno de producción
Instala un sistema de detección de amenazas en cada equipo de los desarrolladores
Un portátil de desarrollador contiene código fuente, credenciales de la nube, tokens de publicación y una sesión autenticada para acceder a la mayor parte de tu infraestructura; por eso, los terminales de los desarrolladores se han convertido en uno de los principales objetivos de ataques a la cadena de suministro. Las herramientas EDR tradicionales detectan las amenazas una vez que ya se están ejecutando, lo que deja un margen de tiempo en el que se pueden sustraer credenciales o instalar paquetes maliciosos antes de que se active ninguna alerta.
Busca herramientas para dispositivos finales que comprueben las instalaciones de npm y pip en el momento en que se realizan, y que puedan aplicar políticas durante la instalación, como requisitos mínimos de antigüedad de los paquetes o listas de permitidos para extensiones de IDE y complementos de navegador.
Aplicar la lista de extensiones permitidas de forma centralizada
Las extensiones de IDE y los complementos de navegador se ejecutan con privilegios reales y se actualizan sin pedir permiso. Mantén una lista de extensiones autorizadas y aplícala desde una política centralizada. Nuestra guía de seguridad sobre extensiones de navegador profundiza específicamente en los aspectos relacionados con el navegador.
Lo que esto habría evitado
En abril de 2026, Aikido descubrió una extensión falsa de WakaTime en OpenVSX que contenía un binario nativo que se cargaba antes que cualquier lógica legítima de la extensión, descargaba una segunda carga útil desde una página de GitHub Releases y la instalaba a la fuerza en todos los editores compatibles del equipo utilizando el propio instalador de línea de comandos de cada editor. Con una sola instalación, VS Code, Cursor, Windsurf y VSCodium quedaron infectados. Una lista de permitidos centralizada habría impedido esto, ya que una extensión falsa de WakaTime publicada por una cuenta desconocida no figuraría en la lista de aprobadas.
La limitación de una lista de permitidos es que solo resulta útil mientras la extensión aprobada se mantenga limpia. GlassWorm también ha comprometido extensiones legítimas que muchos equipos habrían aprobado, y estas se actualizan sin que se genere ningún archivo de diferencias que permita su revisión; por eso es importante contar con una capa de seguridad en el momento de la instalación, además de la lista.
Protege a tus agentes
Comprobar los permisos en el momento de la configuración y ejecutar el código en un entorno aislado
Un agente capaz de ejecutar comandos de shell arbitrarios y acceder a tu base de datos de producción está a solo una llamada a una herramienta comprometida de sufrir una filtración total. Concede únicamente los permisos que requiera la tarea específica y revísalos del mismo modo que revisarías una cuenta de servicio. A continuación, ejecuta el agente en un entorno aislado con controles de salida de red, de modo que, aunque el agente se vea comprometido, no pueda acceder a nada fuera de los límites que hayas establecido.
La delimitación del ámbito en el momento de la configuración y el entorno aislado en tiempo de ejecución resuelven las dos mitades del problema. La primera limita lo que el agente puede solicitar. La segunda limita lo que ocurre cuando algo hace que el agente solicite más.
Tratar los servidores MCP como dependencias
Los servidores MCP conllevan los mismos riesgos de la cadena de suministro que cualquier otra dependencia, por lo que solo debes instalar servidores MCP procedentes de fuentes verificadas, como el registro oficial de MCP en GitHub. En el caso de los servidores MCP distribuidos a través de npm, fíjalos mediante el hash de integridad en tu archivo de bloqueo. Para los basados en Git, fíjalos a un SHA de commit completo en lugar de a una rama o etiqueta. Comprueba que el repositorio esté actualizado y que el editor sea conocido antes de realizar la instalación. Si obtienes el servidor de un registro, trata un servidor MCP no verificado del mismo modo que tratarías un paquete de npm no verificado.
En septiembre de 2025, apareció en npm un paquete llamado «postmark-mcp» que se hacía pasar por el servidor oficial de MCP que ActiveCampaign mantiene para el servicio de correo electrónico Postmark. Su función consistía en permitir que un asistente de IA enviara correos electrónicos a través de tu cuenta de Postmark, y durante quince versiones hizo exactamente eso y nada más. La versión 1.0.16 añadió una línea. Cada correo electrónico que enviaba el servidor se copiaba en copia oculta a una dirección controlada por el atacante, a través de la propia cuenta de la víctima, lo que significaba que los restablecimientos de contraseña, las facturas y cualquier otra cosa que se le pidiera a un agente que enviara también iban a parar a manos de un desconocido.
Trata cualquier entrada no fiable que llegue a un agente como si se tratara de la ejecución de código
La investigación «PromptPwnd» de Aikido fue la primera demostración confirmada en el mundo real de que la inyección de comandos podía comprometer los flujos de trabajo de CI/CD, lo que afectó al menos a cinco empresas de la lista Fortune 500. Un título de incidencia malicioso introducido en un flujo de trabajo de la CLI de Gemini provocó que el agente escribiera secretos del repositorio en un hilo público de incidencias utilizando su propio acceso legítimo.
Audita cualquier flujo de trabajo que transfiera el título de una incidencia o la descripción de una solicitud de incorporación de cambios a una indicación para el agente. Considera que la salida del agente que llega a un comando de shell o a una operación de escritura en un archivo no es fiable hasta que algo la valide.
Detectar paquetes maliciosos en el momento de la instalación y, de nuevo, en el repositorio
Los creadores de código inventan nombres de paquetes que suenan verosímiles y que no existen, y los atacantes han empezado a registrar esos nombres por adelantado y a esperar. El agente lo instala sin pensárselo dos veces, porque el nombre coincide con lo que esperaba encontrar.
Para prevenir el «slopsquatting» es necesario detectar el malware en dos puntos. El primero es en el equipo, en el momento de la instalación, donde se detecta si el agente extrae algo durante una sesión; se trata del mismo control mencionado anteriormente en la sección sobre el momento de la instalación. El segundo es en el repositorio, donde se comprueba cualquier solicitud de incorporación de cambios que introduzca una nueva dependencia antes de que nadie la fusione. Esta segunda capa existe porque un nombre de paquete erróneo puede introducirse en el código fuente desde el equipo de un desarrollador que nunca haya tenido configurado el control en el momento de la instalación.
Ten un plan para la primera hora tras un ataque de malware
Recopilar registros de auditoría
Transmite el registro de auditoría de tu organización a un SIEM. Los eventos más importantes son las modificaciones en el registro y el uso de tokens, ya que son los primeros indicios de una brecha de seguridad. En cuanto a los aspectos concretos sobre los que debes activar alertas, nuestra lista de comprobación de seguridad de GitHub Actions recoge los eventos que conviene configurar.
El atacante de Axios realizó la publicación manualmente utilizando un token de npm de larga duración sustraído del equipo comprometido del responsable del mantenimiento, por lo que no había ningún inicio de sesión sospechoso que detectar. Lo que permitió a los equipos de respuesta establecer la cronología de los hechos fue el registro del repositorio: el cambio del correo electrónico de la cuenta a una dirección controlada por el atacante y, a continuación, la publicación de dos versiones con 39 minutos de diferencia entre ellas, ambas con marca de tiempo.
Genera SBOM firmadas para que la cuestión de la exposición tenga una respuesta
Cuando se publica un nuevo CVE o sale a la luz un paquete comprometido, los equipos que no disponen de un « lista de materiales de software » (SBOM) actualizado pasan horas rastreando manualmente las dependencias para averiguar si se ven afectados. Genera uno para cada artefacto de compilación, incluidas las dependencias transitivas, ya que la mayoría de las vulnerabilidades se encuentran a varios niveles de profundidad. La carga maliciosa de Axios llegó a través de un paquete que nadie había instalado explícitamente. Firma el archivo « SBOM » en el momento de la compilación para que quede vinculado criptográficamente a la compilación que lo generó, y guárdalo junto con el artefacto en tu registro para que ambos permanezcan sincronizados.
Practica las jugadas de rotación antes de que las necesites
Documenta qué credenciales se rotan en cada canal y quién tiene la autoridad para rotar cada tipo. A continuación, anota cómo se comprueba que una rotación se ha completado realmente y realiza un simulacro. Conoce de antemano tu «opción de emergencia ». GitHub Enterprise permite la revocación masiva de credenciales, ya sea para un usuario afectado o para todos los usuarios de la empresa a la vez. Es una medida drástica, pero es mejor que rotar servicio por servicio cuando aún no se sabe hasta qué punto se ha producido la filtración.
Cómo ayuda « Aikido Security » a proteger contra ataques a la cadena de suministro
Aikido Security abarca las capas de instalación y de repositorios descritas en esta entrada. Su sistema de detección se ejecuta en Aikido Intel, que analiza todos los paquetes nuevos en una media de seis minutos y, a menudo, señala los maliciosos en el plazo de uno o dos minutos tras su publicación.
La protección de dispositivos cubre lo que se instala en los equipos de los desarrolladores y bloquea los paquetes y extensiones maliciosos en toda la organización. Safe Chain es la versión gratuita y de código abierto para particulares que bloquea los paquetes maliciosos en el momento de la instalación.
La misma detección de Aikido Intel se aplica a tus repositorios, por lo que cualquier dependencia maliciosa que llegue a una solicitud de incorporación de cambios se marca antes de que nadie la fusione, incluido un nombre de paquete erróneo procedente de un equipo sin protección en el momento de la instalación. SAST Cubre la capa de configuración, marcando las entradas no fiables que llegan a la línea de comandos de un agente, lo que se conoce como el patrón «PromptPwnd».
