L’arribada de npm v12 al juliol va marcar un punt d’inflexió en la seguretat de les cadenes de subministrament de l’ecosistema JavaScript. A partir d’aquesta versió, els scripts de cicle de vida de les dependències —preinstall, install, postinstall— i les compilacions implícites amb node-gyp ja no s’executen tret que el desenvolupador els autoritzi explícitament mitjançant un bloc allowScripts al package.json. La mesura és, sens dubte, un avenç significatiu contra atacs de tipus supply-chain, però també trasllada a cada equip una tasca tediosa i crítica: revisar una llista de paquets i decidir quins són segurs. El problema és que npm només informa que un paquet vol executar un script, però no revela què fa realment. Un 'postinstall': 'node install.js' és una caixa negra: la resposta està dins de install.js, dins del tarball, i a tots els fitxers que requereix. Fins ara, llegir aquests tarballs manualment era l’única opció. Però han sorgit eines com npm-script-lens que automatitzen aquest anàlisi, i a Q2BSTUDIO creiem que el seu ús hauria de ser part de l’estàndard de qualsevol projecte que gestioni dependències de npm.
Per il·lustrar la situació, imaginem un projecte típic que depèn de sharp, prisma, chalk i core-js — 39 paquets fixats al lockfile. En executar npx npm-script-lens audit --fail-on-high, en uns segons es descarreguen només els tarballs d’aquells paquets que tenen comportament en temps d’instal·lació —la majoria no en té— i s’obté un informe clar: 2 riscos alts, 0 mitjans, 2 baixos i 35 sense comportament arriscat. En desglossar, @prisma/engines apareix com a ALT perquè el seu postinstall descarrega binaris del motor de base de dades a través de la xarxa i executa processos amb execa. sharp també és ALT perquè les compilacions natives amb node-gyp rebuild i pkg-config impliquen execució de comandaments del sistema. En canvi, core-js només escriu un fitxer i llegeix variables d’entorn —el seu famós banner postinstall—, considerat baix. chalk i altres 35 paquets no tenen cap comportament en instal·lació. Amb aquesta evidència, l’equip pot construir un bloc allowScripts versió-per-versió, com exigeix npm v12, i decidir amb coneixement 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 veritable repte, però, no és l’auditoria inicial, sinó les actualitzacions. Aprovar sharp@0.33.5 avui no diu res sobre sharp@0.34.0 el mes que ve. Els atacs més sofisticats (com el cas event-stream o l’onada Shai-Hulud d’enguany) solen ser segrestos de versions: un paquet fiable guanya silenciosament una nova capacitat que la seva versió anterior no tenia. Per això el mode --diff d’eines com npm-script-lens és clau: compara el lockfile actual amb el de la branca base i mostra exactament quines capacitats s’han afegit. Per exemple, en passar de sharp 0.32.6 a 0.33.5, el diff reporta: 'guanyat vs 0.32.6: exec: node-gyp rebuild --directory=src · obf: require()'. Això pot ser un canvi legítim (sharp va reestructurar la seva compilació nativa), però és exactament la mateixa línia que mostraria un atac real. Tenir aquesta informació en un comentari de PR abans d’aprovar l’actualització és una pràctica de seguretat que cap empresa hauria d’ignorar.
A Q2BSTUDIO, com a empresa de desenvolupament de programari i tecnologia, fa anys que integrem la ciberseguretat als nostres processos de desenvolupament. Quan treballem en projectes d’aplicacions a mida per als nostres clients, un dels primers passos és analitzar la cadena de subministrament de dependències. La nova política de npm v12 ens obliga a ser encara més meticulosos. Però no es tracta només de scripts d’instal·lació; també avaluem l’ús de serveis cloud com AWS o Azure, la implementació d’intel·ligència artificial i agents IA, i la integració de solucions de Business Intelligence com Power BI. Cadascun d’aquests components pot introduir riscos si no s’audita correctament. Per exemple, un paquet que descarrega binaris des d’una CDN podria estar compromès si el proveïdor de cloud pateix un atac. Per això combinem eines automatitzades amb revisions manuals, i recomanem als nostres clients adoptar un enfocament similar.
A més de la detecció estàtica de capacitats, és crucial comptar amb verificacions externes. Les eines modernes ja creuen cada paquet contra bases de dades com OSV.dev; si apareix un advisory MAL-*, es marca com a MALICIÓS CONEGUT i es bloqueja automàticament, independentment de l’anàlisi d’scripts. També gestionen ofuscació: eval, new Function, require construïts amb strings, i payloads en base64 o char-code són desxifrats i re-analitzats, de manera que l’informe mostra el que el codi ocult realment fa. Això és vital perquè els atacants solen amagar la seva càrrega útil.
Mantenir el bloc allowScripts actualitzat és un altre repte. Com que les entrades estan anclades a versions específiques, cada actualització de dependència invalida silenciosament les aprovacions anteriors. Per evitar que això es converteixi en una càrrega operativa, existeixen comandaments com npm-script-lens sync que verifiquen si el bloc ha quedat desactualitzat i permeten re-anclar-lo preservant decisions quan la nova versió no ha guanyat capacitats, o marcant-les quan sí. També hi ha modes interactius (approve) i accions de GitHub que publiquen informes com a comentaris en PRs. Tot això hauria de formar part del pipeline de CI/CD de qualsevol projecte que vulgui mantenir la seguretat sense sacrificar la productivitat.
Des d’una perspectiva empresarial, la decisió d’aprovar un script d’instal·lació no és binària. Un paquet com @prisma/engines pot tenir 15 milions de descàrregues setmanals i signatura de proveniència Sigstore, cosa que indica que és el Prisma legítim fent el que sempre ha fet. Però un paquet amb la mateixa popularitat sense signatura i amb un sol mantenedor hauria de generar sospites. L’eina dona evidència; l’equip pren la decisió. A Q2BSTUDIO, quan ajudem els nostres clients a adoptar serveis cloud AWS o Azure, també apliquem aquest nivell d’escrutini a les imatges de contenidor, les llibreries de runtime i les dependències d’infraestructura com a codi. La seguretat no és un afegit; és part del disseny.
Pel que fa a intel·ligència artificial, els agents IA estan començant a generar codi i a gestionar dependències de manera autònoma. Si un agent afegeix un paquet sense auditar els seus scripts d’instal·lació, el risc és enorme. Per això existeixen servidors MCP (Model Context Protocol) com el que ofereix npm-script-lens mcp, que permet als agents IA auditar un paquet abans d’incorporar-lo. A Q2BSTUDIO treballem amb agents IA per automatitzar processos de negoci, però sempre sota supervisió humana i amb controls de seguretat automatitzats. L’automatització no ha de ser una drecera per a la seguretat; al contrari, l’ha de reforçar.
En definitiva, npm v12 ha canviat les regles del joc. Ja no podem ignorar què passa durant la instal·lació de dependències. L’auditoria d’scripts de cicle de vida és una tasca que, ben feta, protegeix tot l’ecosistema del projecte. Eines com npm-script-lens (llicència MIT) faciliten aquesta labor, però la responsabilitat última recau en els equips de desenvolupament. A Q2BSTUDIO entenem que la tecnologia avança ràpid, i per això oferim serveis que van des del desenvolupament d’aplicacions a mida fins a la implantació de sistemes d’Business Intelligence amb Power BI, passant per solucions de ciberseguretat, cloud i automatització intel·ligent. Si el vostre equip està migrant a npm v12 o simplement vol reforçar la seguretat de les seves dependències, probablement necessiteu una visió externa i eines com les que aquí descrivim. L’evidència està disponible; només cal aprovar-la amb coneixement de causa.
