Slopsquatting: una amenaça silenciosa nascuda de les al·lucionacions dels LLM

L’arribada d’eines d’intel·ligència artificial generativa ha transformat en molt poc temps la manera en què desenvolupem programari. Avui dia, no és estrany veure professionals programar amb ajuda d’assistents basats en intel·ligència artificial (IA) directament integrats en els seus entorns de desenvolupament (com Github Copilot, Cursor o el famós ChatGPT) que suggereixen fragments de codi, expliquen errors i fins i tot ens ajuden a entendre llibreries o API complexes sense sortir de l’editor.

Això ha suposat un canvi de paradigma en el dia a dia de moltes persones que treballem amb codi. L’impacte ha estat tan notori que fins i tot plataformes consolidades com Stack Overflow han informat de caigudes importants de trànsit i participació. El motiu? Molts desenvolupadors, especialment els més joves, prefereixen fer les preguntes a un model de llenguatge abans de buscar en fòrums tradicionals.

Però no tot són bones notícies. Tot i que aquestes eines ens fan més àgils, també han portat nous reptes que no podem ignorar. Un d’aquests —potser el més característic d’aquesta tecnologia— és el que es coneix com "al·lucinacions".

Quan la IA s’ho inventa

Una al·lucinació, en aquest context, es produeix quan un model de llenguatge genera una resposta que sona convincent, però que és incorrecta o directament falsa [1]. Aquest fenomen no és un error puntual, sinó una característica inherent a com funcionen els models de llenguatge de grans dimensions (LLM, per les seves sigles en anglès) per proporcionar certa creativitat en els textos que generen [2].

Aquests models no tenen una comprensió real del món ni, en general, tenen mecanismes per verificar quan no “saben” alguna cosa [3]. Estan entrenats per completar patrons lingüístics de forma estadística, i això significa que, davant d’una consulta poc comuna o mal formulada, poden oferir una resposta inventada però ben redactada [4].

En el context de la programació, on moltes de les preguntes es refereixen a situacions completament noves, això pot traduir-se en suggeriments de funcions, classes o fins i tot paquets sencers que sonen legítims… però que en realitat no existeixen. I aquí és on el problema es torna més seriós.

Neix una nova amenaça: slopsquatting

El terme slopsquatting va ser encunyat per Seth Larson, desenvolupador de seguretat a la Python Software Foundation. Descriu una tècnica maliciosa que es basa precisament en aquestes al·lucinacions: quan un model d’IA suggereix un paquet que no existeix, un atacant pot registrar-lo en repositoris públics com ara PyPI o npm, de manera que un programador despistat pot carregar inadvertidament una versió amb codi maliciós.

A diferència del conegut typosquatting, on es juga amb errors tipogràfics comuns dels usuaris, en l’slopsquatting la "confusió" la comet el model mateix. És un enfocament més sofisticat perquè explota la confiança que dipositem en els suggeriments generats per aquestes eines intel·ligents. De manera que un desenvolupador que confiï cegament en els suggeriments de la IA i les inclogui en el seu projecte pot estar obrint una porta indesitjada al seu sistema.

Què en diuen els investigadors?

Un estudi recent [5] elaborat per universitats dels Estats Units (entre elles Virginia Tech i la Universitat de Texas a San Antonio) va analitzar més de mig milió de fragments de codi generats amb IA. Entre les seves conclusions:

• El 19,7% dels paquets suggerits pels models eren inexistents.
• Els models de codi obert, com CodeLlama i WizardCoder, van mostrar taxes d’al·lucinació majors (fins a un 21,7%) enfront de models comercials com GPT-4 Turbo (3,59%).
• Moltes d’aquestes al·lucinacions eren recurrents i persistents: el 43% van aparèixer en les 10 execucions repetides de les mateixes consultes.
• El 38% dels noms de paquets inventats eren sorprenentment similars a paquets reals, de vegades fins i tot vàlids en altres llenguatges de programació, fet que augmenta les possibilitats que passin desapercebuts.

Aquestes xifres ens donen una idea clara: no es tracta d’errors puntuals, sinó d’un patró. I aquest patró es pot aprofitar com una vulnerabilitat per infiltrar-se en la cadena de subministrament del programari. I això pot tenir conseqüències serioses per a qualsevol projecte, sense importar la seva grandària.

I això què implica per als qui desenvolupem programari?

A GMV som plenament conscients dels beneficis que les eines d’assistència per IA poden oferir, però també n’hem estudiat els límits actuals, ja que es troben lluny de ser infal·libles [5]. Les utilitzem com una ajuda per ser més eficients sempre mantenint un fort esperit crític sobre els resultats que generen. 

Encara que no hi ha receptes màgiques, apliquem una sèrie de bones pràctiques per minimitzar riscos, entre les quals:

• Verifiquem manualment l’existència i procedència fiable de qualsevol paquet suggerit per una IA.
• Utilitzem eines d’anàlisi de dependències que identifiquen possibles vulnerabilitats i ens alerten sobre components sospitosos.
• Provem el codi en entorns segurs abans d’integrar-lo en sistemes reals.
• Formem de manera contínua els nostres equips en seguretat i en l’ús responsable d’eines d’IA.
• Fomentem la revisió entre parells, especialment quan s’introdueix codi suggerit per IA.

Aquesta combinació de tecnologia i criteri humà és fonamental per mantenir la seguretat i la qualitat dels nostres desenvolupaments.

Com podem mitigar aquest risc?

A GMV seguim explorant i utilitzant aquestes eines amb entusiasme, però sense perdre de vista la responsabilitat que tenim com a desenvolupadors de sistemes crítics. El bon ús de qualsevol tecnologia depèn de les nostres decisions. La IA pot ser una gran aliada, però necessita ser aplicada amb judici humà. Perquè al final, més enllà dels suggeriments intel·ligents o de les línies de codi automatitzades, el que realment marca la diferència és el criteri professional, l’experiència i la feina ben feta.

Autor: Dr. David Miraut

REFERÈNCIES:

[1] R. Tenajas-Cobo and D. Miraut-Andrés, ‘Riesgos en el uso de Grandes Modelos de Lenguaje para la revisión bibliográfica en Medicina’, Investig. En Educ. Médica, vol. 13, no. 49, Art. no. 49, Jan. 2024, doi: 10.22201/fm.20075057e.2024.49.23560.

[2] R. Tenajas and D. Miraut, ‘The 24 Big Challenges of Artificial Inteligence Adoption in Healthcare: Review Article’, Acta Medica Ruha, vol. 1, no. 3, Art. no. 3, Sep. 2023, doi: 10.5281/zenodo.8340188.

[3] R. Tenajas and D. Miraut, ‘The Risks of Artificial Intelligence in Academic Medical Writing’, Ann. Fam. Med., no. 2023, p. eLetter, Feb. 2024.

[4] R. Tenajas, D. Miraut, R. Tenajas, and D. Miraut, ‘El pulso de la Inteligencia Artificial y la alfabetización digital en Medicina: Nuevas herramientas, viejos desafíos’, Rev. Medica Hered., vol. 34, no. 4, pp. 232–233, Oct. 2023, doi: 10.20453/rmh.v34i4.5153.

[5] J. Spracklen, R. Wijewickrama, A. H. M. N. Sakib, A. Maiti, B. Viswanath, and M. Jadliwala, ‘We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs’, Mar. 02, 2025, arXiv: arXiv:2406.10279. doi: 10.48550/arXiv.2406.10279.