L'informe OSSRA del 2026 va auditar 947 bases de codi de disset sectors i va deixar quatre números a la mateixa pàgina: els components open source per aplicació van pujar un 30% en un any, els fitxers un 74%, la mitjana de vulnerabilitats per base de codi un 107%, i els conflictes de llicència ja apareixen en dos terços de les auditories davant del 56% de l'any anterior — el salt interanual més gran des que existeix l'informe.
Cap dels quatre parla del codi que escriu el teu equip. Els quatre parlen del codi que el teu equip importa.
Aquesta peça va d'aquesta part. No de si l'assistent escriu bon codi —d'això en vam parlar en redissenyar la revisió—, sinó de les decisions que pren a més d'escriure'l: quina llibreria fa servir, en quina versió, amb quina llicència i amb quina cadena de mantenidors al darrere. Són decisions amb vida d'anys, es prenen en un segon i arriben a la pull request disfressades d'una línia.
La línia que ningú discuteix
Un diff és democràtic d'una manera que perjudica: totes les línies ocupen el mateix. Canviar el nom d'una variable ocupa una línia. Afegir una dependència ocupa una línia. La primera es discuteix a la revisió; la segona entra sense comentaris, i és la que porta amb ella un arbre de codi que no ha obert cap dels dos.
Les proporcions estan mesurades des de fa anys i gairebé ningú les té presents en aprovar. A l'anàlisi de dependències d'Endor Labs, el 95% de les vulnerabilitats detectades viu en dependències transitives —les que no vas triar tu, sinó la que sí que vas triar—; en aplicacions Java, el 71% del codi que acaba a l'aplicació ve de components open source i, de tot aquest codi importat, se'n fa servir al voltant del 12%.
Amb codi generat, aquesta línia apareix moltes més vegades. No perquè el model sigui temerari, sinó perquè el seu objectiu és resoldre el problema que té al davant, i endur-se una llibreria és gairebé sempre la manera més curta de resoldre'l. El resultat no és una fallada espectacular: és volum. I el volum s'escola per on el procés no mira.
Tres modes de fallada, ordenats al revés de com s'expliquen
Convé separar-los abans de decidir on invertir, perquè tenen freqüències molt diferents i cap no s'arregla amb el control de l'altre. Els ordeno de més sorollós a més freqüent, que resulta ser l'ordre invers al que ocupen en la conversa pública.
| Mode | Què passa | Quant passa |
|---|---|---|
| 1 · El paquet que no existeix | El model recomana un nom inventat. Si algú el registra abans que tu l'instal·lis, executa codi al teu equip i al teu pipeline | Entre el 4,6% i el 6,1% de les referències en els models frontera del 2026. Cap atac maliciós públic documentat encara |
| 2 · El paquet que existeix, en la versió equivocada | La llibreria és real i la versió que proposa arrossega vulnerabilitats ja publicades. El codi funciona i les proves passen | Entre el 36,7% i el 55,7% de les tasques acaben amb almenys un CVE conegut a la versió especificada |
| 3 · El paquet correcte que no hi hauria de ser | Llicència incompatible, duplicat d'una cosa que ja teníeu, o sense ningú a casa que en respongui d'aquí a un any | Dos terços de les bases de codi auditades tenen conflictes de llicència. La resta gairebé mai no es mesura |
El primer és el que surt a la premsa; el tercer és el que us passarà aquesta setmana
1 · El paquet que no existeix
El treball de referència és de Joseph Spracklen i el seu equip, presentat a USENIX Security 2025. Van generar 576.000 mostres de codi amb setze models i dos conjunts de prompts, i van comprovar cada paquet referenciat contra els índexs reals de PyPI i npm: 440.445 referències, el 19,7%, apuntaven a paquets que no existeixen, amb 205.474 noms únics diferents. La taxa anava del 5,2% en models comercials al 21,7% en models oberts.
El titular és la taxa. El que converteix això en un problema de seguretat, i no en una molèstia, són dues altres troballes del mateix estudi, molt menys citades.
La primera és la repetició. Un 43% dels noms al·lucinats tornava a aparèixer en les deu consultes repetides; un 39% no es repetia cap vegada. Aquesta bimodalitat és tota la diferència: una al·lucinació que no es repeteix és soroll, i una que es repeteix sempre és una adreça postal. L'atacant no ha d'endevinar què s'inventarà el model amb el teu company d'equip — n'hi ha prou de preguntar deu vegades i quedar-se amb el que és estable.
La segona és que no som davant d'un typosquatting. Només el 13,4% dels noms inventats és a distància d'edició 1 o 2 d'un paquet real. No són errades d'un nom legítim: són noms nous, plausibles, del tipus que un desenvolupador amb pressa dona per bo perquè sona exactament al que necessitava. Les defenses clàssiques dels registres, pensades per detectar noms gairebé idèntics a un de popular, estan mirant una altra cosa.
El 2026 s'ha replicat l'estudi sobre cinc models frontera publicats entre l'octubre del 2025 i el març del 2026, amb 199.845 prompts aparellats de Python i JavaScript. La bona notícia és que la forquilla es comprimeix un ordre de magnitud: tots els models avaluats queden entre el 4,62% i el 6,10%. La dolenta arriba després de la taxa: hi ha 127 noms de paquet que els cinc models s'inventen de manera idèntica i, després de la divulgació coordinada amb l'equip de seguretat de PyPI i amb Socket, 53 continuaven disponibles per registrar —41 a PyPI i 12 a npm— malgrat les defenses que ja apliquen els registres. Un únic registre maliciós arribaria alhora a usuaris de cinc proveïdors diferents.
És un preprint d'un investigador independent i no ha passat revisió per parells; el cito perquè la seva metodologia replica la de l'estudi d'USENIX i perquè la part que més pesa —els 53 noms lliures— la va validar Socket contra el registre, descartant sis falsos positius que eren importacions vàlides de frameworks. I convé repetir el que ells mateixos escriuen, perquè gairebé cap article ho recull: això és superfície d'atac, no un atac. No hi ha constància pública que cap d'aquests noms s'hagi registrat amb finalitats malicioses.
El cas documentat que la cadena es tanca de debò continua sent un experiment. El desembre del 2023, Bar Lanyado, investigador de Lasso Security, va registrar a PyPI un paquet anomenat huggingface-cli —inofensiu— després de veure que els models el recomanaven una vegada i una altra, quan l'eina real s'instal·la d'una altra manera. El febrer del 2024, el README d'instal·lació d'un repositori d'Alibaba demanava instal·lar el seu. En tres mesos va acumular més de 15.000 descàrregues reals. Ningú no el va atacar: simplement, tot el mecanisme va funcionar.
2 · El paquet que existeix, en la versió equivocada
Aquest mode no dona titulars i és deu vegades més freqüent. La llibreria és real, coneguda i perfectament raonable. El que arriba malament és la versió.
Endor Labs ho va mesurar sobre més de 10.000 repositoris de GitHub i agents de codi a PyPI, npm, Maven i NuGet: només una de cada cinc versions de dependència recomanades per un assistent era segura, entenent per segura que ni el paquet és inventat ni la versió arrossega vulnerabilitats conegudes. Entre el 44% i el 49% de les dependències que els agents importaven tenien vulnerabilitats ja publicades.
L'estudi que millor explica per què és del 2026, sobre deu models i mil tasques de programació reals: entre el 36,70% i el 55,70% de les tasques acaben amb almenys un CVE conegut a la versió de llibreria que el model especifica, i entre el 62,75% i el 74,51% d'aquests CVE són de severitat crítica o alta. A més, tots els models convergeixen en les mateixes versions problemàtiques, cosa que descarta l'accident i apunta a alguna cosa estructural.
La dada que ordena la conversa és aquesta: entre el 72,27% i el 91,37% d'aquests CVE s'havien publicat abans del tall de coneixement del model mateix. No és que el model no ho pogués saber. És que res de la tasca que li vas donar li demanava mirar-ho. El títol del treball ho resumeix millor que qualsevol paràfrasi: codi correcte, dependències vulnerables.
La inversió que descol·loca els equips
El control de moda d'enguany és el cooldown: no instal·lar una versió fins que porti publicada uns dies. Té al darrere un argument sòlid. El novembre del 2025, William Woodruff va revisar deu atacs de cadena de subministrament del 2024 i el 2025 —des de la porta del darrere de xz-utils fins als incidents d'ultralytics, chalk, Nx o web3.js— i va mesurar la finestra entre la publicació del paquet compromès i la seva detecció: en vuit dels deu va ser de menys d'una setmana. Amb set dies d'espera se n'haurien evitat gairebé tots; amb catorze, tots menys un.
L'ecosistema sencer ho ha implementat en nou mesos. pnpm ho porta des de la 10.16 del setembre del 2025, Yarn des de la 4.10, Bun des de la 1.3 de l'octubre i npm des de la 11.10.0 del febrer del 2026; en Python, uv des de la 0.9.17 i pip des de la 26.0; i també Poetry, Bundler i el costat de registre de Cargo. És probablement el canvi d'higiene més ràpid que ha adoptat l'ecosistema en una dècada.
3 · El paquet correcte que no hi hauria de ser
El tercer mode no és de seguretat, no té CVE i és el que apareixerà al vostre repositori aquesta setmana. Són dependències reals, mantingudes i sense vulnerabilitats que, tot i així, no hi haurien d'haver entrat.
Per llicència. És la troballa més contundent de l'OSSRA del 2026 i la que menys es comenta: els conflictes de llicència van passar del 56% a dos terços de les bases auditades en un sol any. L'explicació que dona l'informe té dues meitats — més components per aplicació, i fragments generats a partir de fonts amb copyleft que arriben sense arrossegar la seva llicència. El desajust de procés està mesurat a la mateixa enquesta: el 76% de les organitzacions revisa el codi generat buscant riscos de seguretat, el 54% mira propietat intel·lectual i llicències, i només el 24% revisa les quatre dimensions —seguretat, llicència, propietat intel·lectual i qualitat—. La revisió de propietat intel·lectual es va dissenyar per a un món en què el codi entrava a ritme humà.
Per duplicació. Un generador resol el problema que té al davant; no sap que tres carpetes més enllà ja hi ha una llibreria per a això, aprovada fa dos anys. És la mateixa ceguesa estructural que fa que el codi generat dupliqui en comptes de reutilitzar, només que aplicada al catàleg de proveïdors en comptes del codi propi. I on una funció duplicada és deute, dues llibreries que fan el mateix són dues superfícies per pedaçar i dos criteris d'actualització.
Per orfandat. La pregunta que rarament es fa en una pull request: d'aquí a un any, quan aquesta llibreria publiqui un canvi incompatible o deixi de mantenir-se, qui de nosaltres respon? Si la resposta és «ningú», la dependència entra igualment, però l'equip ha assumit una obligació que no ha registrat enlloc.
Per què la revisió no ho detectarà
Val la pena dir per què això no s'arregla demanant més rigor en la revisió, que és la resposta reflexa. Són tres raons i cap no depèn de la professionalitat de ningú.
El cost de llegir no distingeix. El revisor inverteix els mateixos segons en una línia trivial i en una decisió de cinc anys, perquè al diff ocupen el mateix i arriben barrejades. Quan el cabal de canvis es multiplica, el primer que es perd és allò la pèrdua del qual no es nota.
El que entra no és a la pull request. El 95% de les vulnerabilitats viu a les dependències transitives, i d'aquestes no hi ha ni una línia al diff. S'aprova una entrada al fitxer de bloqueig i arriba un arbre sencer.
No hi ha criteri escrit. Quan algú pregunta «de debò necessitem aquesta llibreria?», està aplicant el seu gust personal, i per això la pregunta es fa poc: incomoda i no té suport. En gairebé cap equip existeix un document que digui què es pot importar, amb quines llicències, des de quina versió mínima i amb quin procés d'alta. Sense això, la revisió de dependències és una opinió davant d'un company amb pressa, i aquesta discussió la guanya sempre la pressa.
Sis controls, i què talla cadascun
Cap no és nou ni car. El que sol fallar no és l'elecció d'eina, sinó instal·lar-ne dues i donar per cobert el que no cobreixen. La columna que importa és la segona.
| Control | Quin mode talla | Què costa de debò |
|---|---|---|
| Mirall del registre amb llista de permesos | Mode 1, a l'arrel | Muntar-lo són dies. El cost és a la cua d'altes: si triga més de 48 hores, l'equip la volta i el control deixa d'existir |
| Fitxer de bloqueig amb hashes i instal·lació reproduïble | Substitució posterior | Gairebé res, i sol estar a mitges: el fitxer existeix, però el pipeline instal·la resolent de nou en comptes d'instal·lar exactament el que està bloquejat |
| Instal·lació sense executar scripts | Execució en el moment d'instal·lar | Una tarda d'arreglar les tres dependències que sí que necessiten compilar, i documentar-les com a excepció |
| Edat mínima de versió (7-14 dies) | Compromís recent del mantenidor | Una línia de configuració, més la llista d'excepcions per a pedaços urgents. No cobreix el mode 2 |
| Política de versió mínima aplicada en resoldre | Mode 2 | És el canvi amb més fricció real: trenca builds el primer mes. A canvi, la versió vulnerable deixa d'instal·lar-se en comptes de reportar-se després |
| Llicència i propietari exigits en l'alta | Mode 3 | Zero euros i tota la resistència cultural: obliga que algú posi el seu nom al costat de cada dependència nova |
Els tres primers són configuració; els tres últims són decisions d'equip, i per això són els que falten
El que sí que canvia el que proposa l'assistent
Hi ha una dada a l'informe d'Endor Labs que es llegeix com una nota tècnica i és, en realitat, l'argument central: quan l'agent té connectades eines de seguretat que pot consultar mentre decideix, la proporció de recomanacions de dependència segures passa d'al voltant del 20% al 57%. Gairebé el triple, sense canviar de model i sense demanar a ningú que s'esforci més.
Val la pena llegir-ho a poc a poc, perquè desmunta la reacció habitual. L'assistent no està incomplint la vostra política de dependències: no l'ha vist mai. Quan proposa una llibreria i una versió, està reproduint el que era raonable al corpus amb què es va entrenar, que és una mitjana d'internet de fa dos anys. La llista del que ja feu servir, les versions mínimes acceptables, les llicències admeses i el «per a això ja tenim una cosa» no són disciplina que calgui exigir: són context que cal donar-li.
És exactament el mateix moviment que en la seguretat dels agents: es deixa de discutir amb el model i es canvia el que el model pot veure i fer. En Spec-Driven Development aquest artefacte té nom i lloc — la constitució del projecte, el document de regles immutables que l'agent llegeix abans de proposar res. Una política de dependències que viu al cap del tech lead serveix per renyar; escrita a la constitució, canvia la primera proposta.
Amb un advertiment que també és a la dada: el 57% no és el 100%. Donar context a l'assistent redueix el volum del que cal aturar aigües avall, no substitueix els sis controls. La seqüència sensata és la contrària a l'habitual: primer el mirall del registre i la instal·lació reproduïble, que no depenen que ningú se'n recordi; després el context, que redueix el cabal; i només llavors les converses de procés, que ja arriben amb molts menys casos.
L'inventari d'un dimarts
No cal un programa per començar, ni comprar res. Cal el fitxer de bloqueig, que ja teniu versionat, i quaranta minuts.
Se'n treu l'historial dels últims noranta dies —el package-lock.json, l'uv.lock, el poetry.lock, el pom.xml, el que us toqui— i es llista quines dependències noves van entrar en aquest període. A cadascuna, tres preguntes: qui la va demanar, en quina pull request es va discutir i si avui es fa servir.
L'interessant gairebé mai no és trobar una dependència perillosa. És veure quantes files tenen les tres caselles buides. Aquest número —la proporció de proveïdors que van entrar al vostre producte sense que ningú decidís res— és el que converteix això d'una intuïció del tech lead en una xifra que es pot baixar el trimestre següent. I a diferència de gairebé tot el que es mesura en un equip de desenvolupament, se'n treu aquesta mateixa tarda i no admet discussió sobre la metodologia.
Preguntes freqüents
El paquet al·lucinat és un risc real o màrqueting de seguretat?
És superfície d'atac demostrada i, fins avui, sense cap incident maliciós públic que l'aprofiti. Convé dir-ho en aquest ordre. Spracklen i el seu equip van mesurar 440.445 referències a paquets inexistents sobre 576.000 mostres de codi, i el treball del 2026 sobre models frontera troba 127 noms que els cinc models avaluats s'inventen igual, dels quals 53 continuaven lliures per registrar després de les defenses de PyPI i npm. Socket, que va participar en la divulgació, deixa escrit que no hi ha constància que cap s'hagi registrat amb finalitats malicioses. L'únic cas documentat que això arriba al món real continua sent l'experiment de Bar Lanyado: va registrar huggingface-cli el desembre del 2023, el febrer del 2024 el README d'un repositori d'Alibaba demanava instal·lar-lo, i va acumular més de 15.000 descàrregues reals en tres mesos amb un paquet inofensiu.
Com es talla el paquet que no existeix sense frenar l'equip?
Amb un mirall del registre i una llista de noms permesos. És l'únic control que ataca aquest mode de fallada a l'arrel, perquè un nom inventat no és al mirall i la instal·lació falla al primer intent, en local, abans d'arribar a ningú. El cost real no és tècnic —muntar un proxy d'artefactes és qüestió de dies— sinó de procés: algú ha d'aprovar altes, i si aquesta cua triga una setmana l'equip la volta. La regla que ho sosté és que l'alta tingui un termini curt i un responsable amb nom, no que la llista sigui llarga.
Si la IA proposa una versió amb CVE conegut, no ho detecta l'escàner que ja tenim?
Ho detecta tard i amb soroll, que a la pràctica és no detectar-ho. L'escàner avisa després del merge, sobre un repositori sencer i barrejat amb troballes de dependències transitives que ningú tocarà aquesta setmana. La troballa de Wang i el seu equip sobre deu models i mil tasques és que entre el 36,70% i el 55,70% de les tasques acaben amb almenys un CVE conegut a la versió especificada, i que entre el 72,27% i el 91,37% d'aquests CVE s'havien publicat abans del tall de coneixement del model mateix. El control que canvia alguna cosa és una política de versió mínima aplicada en la resolució de dependències: la versió vulnerable no s'instal·la, en comptes d'instal·lar-se i reportar-se.
Els cooldowns no endarrereixen les actualitzacions de seguretat?
Endarrereixen les actualitzacions, sí, i per això es configuren amb excepcions. L'argument a favor el va posar William Woodruff el novembre del 2025 revisant deu atacs de cadena de subministrament del 2024 i el 2025: en vuit dels deu, la finestra entre publicar el paquet compromès i detectar-lo va ser de menys d'una setmana; amb set dies d'espera se n'eviten gairebé tots i amb catorze, tots menys un. La contrapartida es gestiona amb una llista d'exclusió per a pedaços urgents, que pnpm porta des del principi i npm encara discuteix. El que no cal esperar del cooldown és que cobreixi l'altre mode de fallada: protegeix del paquet massa nou, no del massa vell.
Què passa amb la llicència del codi i les dependències que porta la IA?
És la part que menys es mira i la que pitjor envelleix. L'informe OSSRA del 2026, sobre 947 bases de codi auditades, hi troba conflictes de llicència en dos terços d'elles davant del 56% de l'any anterior: el salt interanual més gran de la seva història. L'explicació que dona és doble: més components per aplicació —un 30% més en un any— i fragments generats a partir de fonts amb copyleft que arriben sense la seva llicència al darrere. El desajust organitzatiu apareix a la mateixa enquesta: el 76% de les empreses revisa el codi generat buscant riscos de seguretat, només el 54% mira propietat intel·lectual i llicències, i tot just el 24% revisa les quatre dimensions.
Per on començo aquesta setmana sense muntar un programa?
Per un inventari de quaranta minuts sobre el fitxer de bloqueig, que ja teniu versionat. Se'n treuen les dependències que van entrar els últims noranta dies amb l'historial d'aquest fitxer, i a cadascuna se li fan tres preguntes: qui la va demanar, en quina pull request es va discutir i si avui es fa servir. El que sol aparèixer no és una dependència perillosa, sinó que la majoria no té resposta per a cap de les tres. Aquesta llista, amb les caselles buides a la vista, és una conversa diferent de la de demanar pressupost per a una eina: converteix una intuïció en un número que es pot reduir el trimestre següent.
Fonts citades
- Spracklen, J., Wijewickrama, R., Sakib, A. H. M. N., Maiti, A., Viswanath, B. i Jadliwala, M. — We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs (USENIX Security 2025; 576.000 mostres i 16 models; 19,7% de referències al·lucinades, 205.474 noms únics, 43% repetits en les deu consultes, 13,4% a distància d'edició 1-2)
- Churilov, A. — The Range Shrinks, the Threat Remains: Re-evaluating LLM Package Hallucinations on the 2026 Frontier-Model Cohort (preprint no revisat per parells; 199.845 prompts i cinc models frontera; 4,62%-6,10%, 127 noms compartits, 53 registrables)
- Socket — New Study Identifies 53 Slopsquatting Targets Across 5 Frontier LLMs (22 de juliol del 2026; validació dels noms contra el registre i l'aclariment que no hi ha constància de registre maliciós)
- Claburn, T. — AI bots hallucinate software packages and devs download them (The Register, 28 de març del 2024; l'experiment de Bar Lanyado amb
huggingface-cli, el README d'Alibaba i les més de 15.000 descàrregues) - Endor Labs — 2025 State of Dependency Management (4 de novembre del 2025; més de 10.000 repositoris; una de cada cinc versions recomanades segura, 44-49% amb vulnerabilitats conegudes, del 20% al 57% amb eines de seguretat connectades)
- Wang, C., Wu, J., Ling, X., Luo, T. i Zhao, C. — Correct Code, Vulnerable Dependencies: A Large Scale Measurement Study of LLM-Specified Library Versions (maig del 2026; 10 models i 1.000 tasques; 36,70%-55,70% de tasques amb CVE conegut i 72,27%-91,37% d'aquests CVE anteriors al tall de coneixement)
- Black Duck — 2026 Open Source Security and Risk Analysis (OSSRA) (25 de febrer del 2026; 947 bases de codi i 17 sectors; components +30%, fitxers +74%, vulnerabilitats mitjanes +107%, conflictes de llicència en dos terços davant del 56%)
- Woodruff, W. — We should all be using dependency cooldowns (21 de novembre del 2025; deu atacs del 2024-2025, vuit amb finestra inferior a una setmana)
- Nesbitt, A. — Package Managers Need to Cool Down (4 de març del 2026; l'inventari de versions i opcions d'espera a npm, pnpm, Yarn, Bun, uv, pip, Poetry, Bundler i Cargo)
- Endor Labs — State of Dependency Management 2023 (95% de les vulnerabilitats en dependències transitives; 71% del codi d'una aplicació Java procedent d'open source, del qual se'n fa servir al voltant del 12%)
Jordi García és Tech Lead a onext. Treballa a portar la IA a producció governada en equips de desenvolupament i de producte —amb Spec-Driven Development, enginyeria de context i verificació humana a cada pas— i signa els insights tècnics d'onext sobre mètode, qualitat i cost de la IA aplicada.
LinkedIn →