Un botón “Aprobar todo”: NPM finalmente desactiva la ejecución automática de los scripts de instalación

npm prepara uno de los cambios más notables de los últimos años. En la nueva versión del gestor de paquetes, los desarrolladores ya no podrán ejecutar por defecto los scripts de instalación de bibliotecas ajenas. En el papel parece un golpe potente contra los paquetes maliciosos, pero ese paso no resolverá el problema por completo.

Según el anuncio de npm, en la versión npm 12 varias capacidades peligrosas pasarán a estar prohibidas por defecto. La novedad principal afecta a los scripts que se ejecutan al instalar paquetes. Ahora, el comando npm install puede ejecutar automáticamente preinstall, install y postinstall no solo en la dependencia directa, sino también en paquetes anidados cuya existencia a menudo el desarrollador ni siquiera conoce.

Fueron precisamente esos scripts los que durante años ayudaron a que paquetes maliciosos se instalaran rápidamente en los equipos de desarrolladores y en entornos de integración continua. Bastaba con instalar una dependencia infectada para que el código malicioso tuviera oportunidad de ejecutarse de inmediato. En npm 12 se desactivará la ejecución automática. Los desarrolladores tendrán que autorizar manualmente los scripts necesarios mediante npm approve-scripts, revisar los paquetes afectados y prohibir los innecesarios por separado con npm deny-scripts.

Además, las dependencias procedentes de repositorios Git requerirán la bandera explícita --allow-git. Esa medida cierra una vía peligrosa en la que una dependencia podía, mediante su propio archivo .npmrc, sustituir el ejecutable de Git y ejecutar código incluso con --ignore-scripts activado. Las dependencias en forma de archivos remotos por HTTPS también pasarán a requerir una autorización separada con --allow-remote. La salida de npm 12 se espera aproximadamente en julio de 2026, y ya se puede empezar a prepararse en npm 11.16.0 y versiones posteriores.

Los cambios parecen contundentes porque los scripts de instalación llevan tiempo siendo una de las principales vías de infección en el ecosistema npm. Muchos ataques se basaban precisamente en que un paquete ejecutaba código en el momento de la instalación, mientras el desarrollador aún no había abierto el proyecto ni inspeccionado la dependencia. La ejecución automática se desactivará, y eso realmente reducirá el número de ataques masivos y complicará la vida de los atacantes.

Paralelamente, gana popularidad otro mecanismo de protección sencillo: retrasar la instalación de versiones recién publicadas. En npm ese parámetro apareció en la versión 11.10.0. El desarrollador puede prohibir la instalación de un paquete hasta que la versión nueva lleve disponible en abierto un número de días determinado. La lógica es simple: muchas versiones infectadas se detectan y eliminan rápido, por lo que una pausa corta permite filtrar parte de las amenazas sin análisis complejo. Un enfoque similar ya lo usan pNPM, Yarn y Bun.

En el mercado también crece la demanda de capas de protección para cadenas de suministro. Esas herramientas interceptan el intento de instalar un paquete, comprueban indicadores de riesgo conocidos y pueden bloquear una dependencia peligrosa. En este ámbito hay soluciones abiertas y comerciales, incluidas Datadog, npq, Socket, Aikido y Endor Labs. Pero estos medios solo ayudan hasta que los desarrolladores no omiten las advertencias para poder compilar el proyecto con urgencia.

La principal debilidad del nuevo modelo de npm no está en la tecnología, sino en los hábitos de las personas. Muchos paquetes legítimos usan realmente scripts de instalación. Entre ellos están esbuild, sharp, core-js, puppeteer, Nx, bufferutil, utf-8-validate y bcrypt. Unos descargan binarios para una plataforma concreta, otros compilan módulos nativos con node-gyp, y otros preparan el entorno tras la instalación.

Tras la salida de npm 12 esos paquetes pueden dejar de funcionar salvo que se autoricen manualmente los scripts. Los desarrolladores empezarán a aprobar scripts uno por uno, especialmente si el proceso de compilación falla antes de una entrega. Con el tiempo, una protección útil corre el riesgo de convertirse en otra ventana que todos aprueban y cierran automáticamente. Navegadores, sistemas operativos y entornos de desarrollo ya se han enfrentado a un problema parecido.

Los atacantes tampoco desaparecerán. Si el script de instalación deja de ejecutarse por sí mismo, el código malicioso puede moverse a otra fase. Por ejemplo, a comandos de configuración inicial, a un cargador separado, a un script externo o a un binario descargado desde un servidor remoto. Si una biblioteca ya en uso está infectada, el script de instalación puede no ser necesario porque la carga útil se ejecutará dentro de la aplicación.

Por eso a los defensores les resultará más difícil distinguir el comportamiento normal del peligroso. Los autores legítimos que aún necesiten descargar un archivo o compilar un módulo pueden pasar a esquemas de evasión. La descarga externa, la ejecución indirecta y las configuraciones no estándar antes parecían un indicador claro de malware, pero tras el endurecimiento de las reglas parte de los proyectos normales empezará a verse igual de sospechosa.

El resultado es una imagen ambigua. npm 12 realmente cierra una de las vías más cómodas para los ataques masivos. El retraso en la instalación de versiones nuevas y las capas de protección también dan a los equipos una oportunidad real de detener intentos de infección antes de la ejecución de código. Pero los paquetes maliciosos no desaparecerán, y parte de la actividad simplemente se desplazará a lugares con menos control y peor visibilidad.

Se puede activar el retraso de instalación de versiones nuevas desde ahora, sin esperar a npm 12. Es mejor preparar con antelación los scripts permitidos para no tener que aprobar todo de forma caótica al migrar a la nueva versión. Las herramientas de protección también son útiles si el equipo está dispuesto a respetar sus reglas.

Pero la principal defensa no reside en la configuración de un único parámetro. El equipo debe entender de qué paquetes depende el proyecto, para qué sirve cada dependencia directa y anidada, qué acciones están permitidas al instalar y quién toma esas decisiones. npm ha dado un paso importante, pero la seguridad de la cadena de suministro no surgirá por sí sola tras cambiar un puñado de ajustes.