La llegada de npm v12 en julio marcó un punto de inflexión en la seguridad de las cadenas de suministro del ecosistema JavaScript. A partir de esta versión, los scripts de ciclo de vida de dependencias —preinstall, install, postinstall— y las compilaciones implícitas con node-gyp ya no se ejecutan a menos que el desarrollador los autorice explícitamente mediante un bloque allowScripts en el package.json. La medida es, sin duda, un avance significativo contra ataques de tipo supply-chain, pero también traslada a cada equipo una tarea tediosa y crítica: revisar una lista de paquetes y decidir cuáles son seguros. El problema es que npm solo informa de que un paquete quiere ejecutar un script, pero no revela qué hace realmente ese script. Un 'postinstall': 'node install.js' es una caja negra: la respuesta está dentro de install.js, dentro del tarball, y en todos los archivos que requiere. Hasta ahora, leer esos tarballs manualmente era la única opción. Pero han surgido herramientas como npm-script-lens que automatizan este análisis, y en Q2BSTUDIO creemos que su uso debería ser parte del estándar de cualquier proyecto que maneje dependencias de npm.
Para ilustrar la situación, imaginemos un proyecto típico que depende de sharp, prisma, chalk y core-js. Son 39 paquetes fijos en el lockfile. Al ejecutar npx npm-script-lens audit --fail-on-high, en unos segundos se descargan solo los tarballs de aquellos paquetes que tienen comportamiento en tiempo de instalación —la mayoría no lo tiene— y se obtiene un informe claro: 2 riesgos altos, 0 medios, 2 bajos y 35 sin comportamiento riesgoso. Al desglosar, @prisma/engines aparece como ALTO porque su postinstall descarga binarios del motor de base de datos a través de la red y ejecuta procesos con execa. sharp también es ALTO porque las compilaciones nativas con node-gyp rebuild y pkg-config implican ejecución de comandos del sistema. En cambio, core-js solo escribe un archivo y lee variables de entorno —su famoso banner postinstall—, considerado bajo. chalk y otros 35 paquetes no tienen ningún comportamiento en instalación. Con esta evidencia, el equipo puede construir un bloque allowScripts versión-por-versión, como exige npm v12, y decidir con conocimiento de causa: {'allowScripts': {'@prisma/engines@5.22.0': false, 'core-js@3.38.1': true, 'prisma@5.22.0': true, 'sharp@0.33.5': false}}.
El verdadero desafío, sin embargo, no es la auditoría inicial, sino las actualizaciones. Aprobar sharp@0.33.5 hoy no dice nada sobre sharp@0.34.0 el mes que viene. Los ataques más sofisticados (como el caso event-stream o la ola Shai-Hulud de este año) suelen ser secuestros de versiones: un paquete confiable gana silenciosamente una nueva capacidad que su versión anterior no tenía. Por eso el modo --diff de herramientas como npm-script-lens es clave: compara el lockfile actual con el de la rama base y muestra exactamente qué capacidades se han añadido. Por ejemplo, al pasar de sharp 0.32.6 a 0.33.5, el diff reporta: 'ganado vs 0.32.6: exec: node-gyp rebuild --directory=src · obf: require()'. Eso puede ser un cambio legítimo (sharp reestructuró su compilación nativa), pero es exactamente la misma línea que mostraría un ataque real. Tener esa información en un comentario de PR antes de aprobar la actualización es una práctica de seguridad que ninguna empresa debería ignorar.
En Q2BSTUDIO, como empresa de desarrollo de software y tecnología, llevamos años integrando la ciberseguridad en nuestros procesos de desarrollo. Cuando trabajamos en proyectos de aplicaciones a medida para nuestros clientes, uno de los primeros pasos es analizar la cadena de suministro de dependencias. La nueva política de npm v12 nos obliga a ser aún más meticulosos. Pero no solo se trata de scripts de instalación; también evaluamos el uso de servicios cloud como AWS o Azure, la implementación de inteligencia artificial y agentes IA, y la integración de soluciones de Business Intelligence como Power BI. Cada uno de estos componentes puede introducir riesgos si no se audita correctamente. Por ejemplo, un paquete que descarga binarios desde una CDN podría estar comprometido si el proveedor de cloud sufre un ataque. Por eso combinamos herramientas automatizadas con revisiones manuales, y recomendamos a nuestros clientes adoptar un enfoque similar.
Además de la auditoría estática de capacidades, es crucial contar con verificaciones externas. Las herramientas modernas ya cruzan cada paquete contra bases de datos como OSV.dev; si aparece un advisory MAL-*, se marca como MALICIOSO CONOCIDO y se bloquea automáticamente, independientemente del análisis de scripts. También manejan ofuscación: eval, new Function, require construidos con strings, y payloads en base64 o char-code son descifrados y re-analizados, de modo que el informe muestra lo que el código oculto realmente hace. Esto es vital porque los atacantes suelen esconder su carga útil.
Mantener el bloque allowScripts actualizado es otro reto. Como las entradas están ancladas a versiones específicas, cada actualización de dependencia invalida silenciosamente las aprobaciones anteriores. Para evitar que esto se convierta en una carga operativa, existen comandos como npm-script-lens sync que verifican si el bloque ha quedado desactualizado y permiten re-anclarlo preservando decisiones cuando la nueva versión no ha ganado capacidades, o marcándolas cuando sí. También hay modos interactivos (approve) y acciones de GitHub que publican informes como comentarios en PRs. Todo esto debería formar parte del pipeline de CI/CD de cualquier proyecto que quiera mantener la seguridad sin sacrificar la productividad.
Desde una perspectiva empresarial, la decisión de aprobar un script de instalación no es binaria. Un paquete como @prisma/engines puede tener 15 millones de descargas semanales y firma de proveniencia Sigstore, lo que indica que es el Prisma legítimo haciendo lo que siempre ha hecho. Pero un paquete con la misma popularidad pero sin firma y con un solo mantenedor debería levantar sospechas. La herramienta da evidencia; el equipo toma la decisión. En Q2BSTUDIO, cuando ayudamos a nuestros clientes a adoptar servicios cloud AWS o Azure, también aplicamos este nivel de escrutinio a las imágenes de contenedor, las librerías de runtime y las dependencias de infraestructura como código. La seguridad no es un añadido; es parte del diseño.
En cuanto a inteligencia artificial, los agentes IA están empezando a generar código y a gestionar dependencias de forma autónoma. Si un agente añade un paquete sin auditar sus scripts de instalación, el riesgo es enorme. Por eso existen servidores MCP (Model Context Protocol) como el que ofrece npm-script-lens mcp, que permite a los agentes de IA auditar un paquete antes de incorporarlo. En Q2BSTUDIO trabajamos con agentes IA para automatizar procesos de negocio, pero siempre bajo supervisión humana y con controles de seguridad automatizados. La automatización no debe ser un atajo para la seguridad; al contrario, debe reforzarla.
En definitiva, npm v12 ha cambiado las reglas del juego. Ya no podemos ignorar lo que ocurre durante la instalación de dependencias. La auditoría de scripts de ciclo de vida es una tarea que, bien hecha, protege todo el ecosistema del proyecto. Herramientas como npm-script-lens (licencia MIT) facilitan esta labor, pero la responsabilidad última recae en los equipos de desarrollo. En Q2BSTUDIO entendemos que la tecnología avanza rápido, y por eso ofrecemos servicios que van desde el desarrollo de aplicaciones a medida hasta la implantación de sistemas de Business Intelligence con Power BI, pasando por soluciones de ciberseguridad, cloud y automatización inteligente. Si tu equipo está migrando a npm v12 o simplemente quiere reforzar la seguridad de sus dependencias, probablemente necesites una visión externa y herramientas como las que aquí describimos. La evidencia está disponible; solo falta aprobarla con conocimiento de causa.
