npm v12 endurece los scripts por defecto seguridad reforzada que podría romper tus builds si no autorizas cada script

GitHub y el equipo de npm han decidido endurecer el comportamiento por defecto del instalador de paquetes: en npm v12 se desactivarán por defecto los scripts de instalación y se restringirá la resolución de dependencias desde repositorios Git o URLs remotas a menos que el desarrollador lo autorice explícitamente. La medida busca cerrar una de las vías más explotadas en ataques a la cadena de suministro: la ejecución automática de código durante "npm install" mediante los hooks del ciclo de vida (preinstall, install, postinstall y prepare).

El cambio responde a un riesgo real y frecuente: un paquete comprometido en cualquier punto de la cadena transitoria puede ejecutar código en la máquina del desarrollador o en un runner de CI. Muchos proyectos, bibliotecas y herramientas dependen de scripts que corren automáticamente al instalar dependencias, y esa confianza por defecto es lo que los atacantes han utilizado para insertar puertas traseras o ejecutar payloads maliciosos en entornos de desarrollo y despliegue.

Las implicaciones prácticas son duales. Por un lado, mejora la seguridad al obligar a la aprobación explícita de la ejecución de scripts y la resolución de fuentes no registradas; por otro, puede romper builds y flujos de desarrollo que hoy dependen de compilaciones nativas automáticas (node-gyp), prepare scripts desde referencias Git, o paquetes instalados desde tarballs remotos. Los equipos y proyectos que usan dependencias con compilación nativa o referencias directas a repositorios tendrán que adaptarse.

GitHub recomienda prepararse ya actualizando a npm 11.16.0 o superior, ejecutar una instalación normal y revisar las advertencias que npm muestra. La herramienta ofrece un flujo de aprobación con npm approve-scripts --allow-scripts-pending, que permite revisar, aprobar los scripts de confianza y comprometer los cambios al package.json para que solo los aprobados sigan ejecutándose tras subir a npm v12. Es una oportunidad para auditar conscientemente qué paquetes realmente necesitan ejecutar código localmente.

Como medidas prácticas para reducir el impacto y mejorar la seguridad de tu cadena de suministro, considera lo siguiente: prueba los cambios en una rama aislada y en runners de CI antes de migrar; actualiza las imágenes o contenedores de CI para incluir la nueva versión de npm; evita dependencias Git o remotas sin justificar y, si las necesitas, autorízalas de forma explícita; prioriza el uso de lockfiles y versiones fijadas; y trata con especial cuidado los paquetes que realizan compilación nativa (node-gyp), ya que npm puede bloquear rebuilds implícitos.

Además, integra controles complementarios: habilita el análisis de dependencias y alertas (por ejemplo, Dependabot o Snyk) para detectar cambios sospechosos, obliga a la verificación humana para cambios de dependencia en pull requests relevantes, habilita 2FA y políticas de publicación en el registro npm para los mantenedores, y conserva evidencia de procedencia con SBOM y firmas cuando sea posible. La documentación de buenas prácticas de GitHub sobre seguridad de la cadena de suministro es un buen punto de partida: https://docs.github.com/en/code-security/supply-chain-security.

Para entender exactamente qué scripts y comportamientos se verán afectados conviene leer la documentación oficial de npm sobre scripts y lifecycle hooks; esto ayuda a identificar en tu árbol de dependencias dónde se ejecutan scripts y cuáles necesitas aprobar explícitamente: https://docs.npmjs.com/cli/v12/using-npm/scripts. Aprovecha la ventana previa al lanzamiento para auditar y reducir la superficie de ataque: menos scripts confiables por defecto = menos riesgo de ejecución no autorizada.

En resumen, npm v12 representa un avance significativo en la protección de la cadena de suministro de JavaScript al convertir una extensión de confianza tácita en un permiso explícito. Los equipos que adopten estas medidas con planificación, pruebas y controles adicionales reducirán su exposición a ataques supply-chain y, al mismo tiempo, evitarán interrupciones inesperadas en sus procesos de construcción y despliegue.