Cómo un ataque de supply chain puede comprometer tu infraestructura: protege tu npm

Hay ataques que no entran tumbando la puerta, sino pasando como algo normal dentro de tu flujo de trabajo. Eso fue justamente lo que volvió tan delicado este caso: una PR maliciosa, cambios disfrazados dentro del proyecto y caracteres Unicode invisibles que ayudaban a ocultar código peligroso dentro de un preinstall.js.

Visto desde afuera puede parecer un detalle de desarrollo. En la práctica es un problema serio de seguridad y de infraestructura, porque basta con que alguien ejecute npm install en una estación comprometida para abrir la puerta a robo de credenciales, persistencia y movimiento lateral.

Qué pasó y por qué importa

La idea del ataque fue esconder comportamiento malicioso dentro del proceso de instalación de dependencias. El paquete parecía normal, pero durante la ejecución del script de instalación disparaba lógica ofuscada para recoger información sensible del sistema y enviarla fuera del entorno afectado.

Lo más delicado es que esto no depende de que un usuario abra un archivo raro manualmente. Basta con confiar en una dependencia, actualizar un proyecto o dejar que una automatización haga su trabajo sin controles adicionales.

Cómo funciona un ataque así

Normalmente la cadena se ve más o menos así:

• El atacante introduce una PR o cambio aparentemente legítimo.
• Se usan caracteres Unicode invisibles o técnicas de ofuscación para dificultar la revisión visual.
• El paquete ejecuta un preinstall.js durante npm install.
• Dentro del script aparecen patrones como eval() y Buffer.from() para reconstruir y ejecutar código oculto.
• Ese código puede exfiltrar cookies, tokens, credenciales locales o información de sesión.
• Después puede dejar persistencia o preparar el terreno para seguir explotando la máquina.

Eso es justamente lo que hace tan peligroso un ataque de supply chain: no ataca primero a la empresa, ataca la confianza del ecosistema y se mete por el camino que todos usamos a diario.

Por qué esto debe preocupar a un IT Manager

Aquí es donde el tema deja de ser solo de desarrolladores. Hoy muchos equipos técnicos, y también muchos agentes AI como Claude, Codex o Gemini, ejecutan tareas que incluyen npm install, builds, pruebas o entornos temporales. Si uno de esos paquetes viene comprometido, no solo se afecta una laptop: se puede exponer una estación privilegiada, un runner, una VM, un servidor de integración o incluso credenciales que luego toquen infraestructura real.

Dicho simple: si permites scripts de instalación sin control, estás dejando que código de terceros se ejecute dentro de tu ambiente con bastante más confianza de la que debería.

La solución práctica que recomiendo

La medida más simple y más rentable es desactivar por defecto la ejecución de scripts de npm, y habilitarlos solo cuando realmente hagan falta y el paquete esté verificado.

1. Desactivar scripts globalmente

npm config set ignore-scripts true

Con esto haces que npm install deje de ejecutar automáticamente scripts como preinstall, postinstall y similares.

2. Forzarlo también por proyecto

ignore-scripts=true

Ese valor dentro de un archivo .npmrc en cada proyecto ayuda a que el control no dependa solo de la configuración personal de una máquina.

3. Reconstruir solo binarios verificados

Si realmente necesitas que un paquete compile binarios o complete una instalación especial, hazlo de forma consciente:

npm rebuild <paquete>

La idea es reconstruir solo lo que ya validaste, no volver a abrir la puerta a todo el árbol de dependencias sin revisar.

4. Hardening en múltiples estaciones

Si administras varias máquinas de desarrollo o soporte, conviene automatizar esta base. Un ejemplo simple en PowerShell sería:

$users = Get-ChildItem C:\Users -Directory
foreach ($u in $users) {
  $npmrc = Join-Path $u.FullName '.npmrc'
  if (-not (Test-Path $npmrc)) {
    Set-Content -Path $npmrc -Value 'ignore-scripts=true'
  } elseif (-not (Select-String -Path $npmrc -Pattern 'ignore-scripts=true' -SimpleMatch -Quiet)) {
    Add-Content -Path $npmrc -Value 'ignore-scripts=true'
  }
}

Esto no sustituye una política central ni EDR, pero sí ayuda a bajar superficie de exposición rápido.

Qué hacer si sospechas infección

Si detectas actividad rara después de un npm install, mi recomendación no es “limpiar y seguir”. En un incidente así hay que asumir compromiso hasta demostrar lo contrario.

• Aislar de inmediato la estación o servidor afectado.
• Revocar tokens, cookies, secretos, credenciales SSH, accesos a Git y sesiones activas.
• Revisar runners, pipelines y máquinas donde ese entorno haya compartido credenciales.
• Tomar evidencia si tu proceso de respuesta lo exige.
• Formatear y reconstruir el equipo si hay duda razonable de persistencia.

Cuando hay ejecución arbitraria y exfiltración posible, improvisar limpieza parcial suele salir caro.

Conclusión

Este tipo de ataques nos recuerda algo incómodo pero real: la cadena de confianza del desarrollo también es infraestructura. Y hoy, con automatizaciones, agentes AI y pipelines que ejecutan dependencias a cada rato, el riesgo es más alto de lo que muchos creen.

Por eso esta configuración vale oro: 30 segundos de configuración vs semanas de recuperación. Si puedes cerrar una puerta tan sensible con una medida tan simple, no tiene sentido dejarla abierta.

Este artículo está basado en el excelente análisis de midudev sobre el ataque de supply chain que afectó al ecosistema npm.