La seguridad de la cadena de suministro de software se ha convertido en una preocupación primordial para los profesionales de la seguridad informática, siendo el gestor de paquetes **npm** un objetivo frecuente. **GitHub**, el custodio de **npm**, está tomando medidas decisivas para mitigar estos riesgos al introducir 'cambios disruptivos' en la próxima versión 12 de **npm**.  ### Deshabilitación de Scripts de Instalación por Defecto El núcleo de la actualización consiste en desactivar los scripts de instalación por defecto. Este cambio combate directamente las técnicas de ataque que aprovechan el comando `npm install` para ejecutar código malicioso a través de los hooks del ciclo de vida de **npm**. **GitHub** ha identificado los scripts del ciclo de vida en el momento de la instalación como la "superficie de ejecución de código más grande en el ecosistema **npm**". Actualmente, `npm install` ejecuta scripts de cada dependencia transitiva, lo que significa que un solo paquete comprometido en cualquier punto del árbol de dependencias puede ejecutar código arbitrario en la máquina de un desarrollador o en un CI runner. Al bloquear estos comportamientos, **npm** ahora requerirá la aprobación explícita del usuario antes de que la ejecución del código se inicie automáticamente durante la instalación. ### Cambios Clave en npm v12 Los próximos cambios son exhaustivos y apuntan a varios vectores de ataque comunes: * `npm install` ya no ejecutará scripts `preinstall`, `install` o `postinstall` de las dependencias, a menos que estén explícitamente permitidos en el proyecto. * `npm install` ya no resolverá dependencias de **Git**, ya sean directas o transitivas, a menos que se permita explícitamente a través de `--allow-git`. * `npm install` ya no resolverá dependencias desde URLs remotas, como tarballs `https`, a menos que se permita explícitamente a través de `--allow-remote`. Esto también se extiende a las compilaciones nativas de `node-gyp`, donde un paquete con un `binding.gyp` pero sin un script de instalación explícito seguirá siendo bloqueado, ya que **npm** ejecuta implícitamente un `node-gyp rebuild` para él. De manera similar, los scripts `prepare` de dependencias de **Git**, archivos y enlaces serán bloqueados. ### Mitigación de Exploits de Dependencias de Git Al establecer `--allow-git` en `none` por defecto, **GitHub** cierra una ruta crucial de ejecución de código donde un archivo de configuración `.npmrc` de una dependencia de **Git** podría anular el ejecutable de **Git**. Esta vulnerabilidad existía incluso con la bandera `--ignore-scripts`, que está diseñada para evitar que los paquetes ejecuten automáticamente scripts del ciclo de vida integrados durante la instalación. ### Preparación del Desarrollador y Mejores Prácticas **GitHub** recomienda que los desarrolladores se preparen para estos cambios actualizando a **npm** 11.16.0 o una versión más reciente. Después de actualizar, los desarrolladores deben ejecutar una instalación normal y revisar cualquier advertencia mostrada. El flujo de trabajo recomendado es usar `npm approve-scripts --allow-scripts-pending` para identificar paquetes con scripts, aprobar los de confianza y luego confirmar el `package.json` actualizado. Solo los scripts explícitamente aprobados continuarán ejecutándose después de la actualización, mientras que los scripts no aprobados serán bloqueados. Este cambio de confianza implícita a aprobación explícita mejora significativamente la postura de seguridad del ecosistema **npm**. A principios de este año, **npm** también introdujo `min-release-age`, una configuración diseñada para rechazar cualquier versión de paquete publicada menos de un número especificado de días. Esto actúa como una salvaguarda adicional contra paquetes maliciosos recién publicados, fortaleciendo aún más la cadena de suministro de software.