Slopsquatting: una amenaza silenciosa nacida de las alucinaciones de los LLMs

La llegada de herramientas de inteligencia artificial generativa ha transformado en muy poco tiempo la manera en que desarrollamos software. Hoy en día, no es raro ver a profesionales programando con ayuda de asistentes basados en inteligencia artificial (IA) directamente integrados en sus entornos de desarrollo (como Github Copilot, Cursor o el famoso chatGPT) que sugieren fragmentos de código, explican errores y hasta nos ayudan a entender librerías o APIs complejas sin salir del editor.

Esto ha supuesto un cambio de paradigma en el día a día de muchas personas que trabajamos con código. El impacto ha sido tan notorio que incluso plataformas consolidadas como Stack Overflow han reportado caídas importantes de tráfico y participación. ¿El motivo? Muchos desarrolladores, especialmente los más jóvenes, prefieren hacer sus preguntas a un modelo de lenguaje antes que buscar en foros tradicionales.

Pero no todo son buenas noticias. Aunque estas herramientas nos hacen más ágiles, también han traído nuevos retos que no podemos ignorar. Uno de ellos, quizás el más característico de esta tecnología, es lo que se conoce como "alucinaciones" 

Cuando la IA se lo inventa

Una alucinación, en este contexto, se produce cuando un modelo de lenguaje genera una respuesta que suena convincente, pero que es incorrecta o directamente falsa [1]. Este fenómeno no es un error puntual, sino una característica inherente a cómo funcionan los modelos de lenguaje de gran tamaño (LLMs, por sus siglas en inglés) para proporcionar cierta creatividad en los textos que generan [2].

Estos modelos no tienen una comprensión real del mundo ni, en general, tienen mecanismos para verificar cuándo no “saben” algo [3]. Están entrenados para completar patrones lingüísticos de forma estadística, y eso significa que, ante una consulta poco común o mal formulada, pueden ofrecer una respuesta inventada pero bien redactada [4].

En el contexto de la programación, donde muchas de las preguntas se refieren a situaciones completamente nuevas, esto puede traducirse en sugerencias de funciones, clases o incluso paquetes enteros que suenan legítimos… pero que en realidad no existen. Y aquí es donde el problema se vuelve más serio.

Nace una nueva amenaza: slopsquatting

El término slopsquatting fue acuñado por Seth Larson, desarrollador de seguridad en la Python Software Foundation. Describe una técnica maliciosa que se basa precisamente en esas alucinaciones: cuando un modelo de IA sugiere un paquete que no existe, un atacante puede registrarlo en repositorios públicos como PyPI o npm, de modo que un programador despistado puede cargar inadvertidamente una versión con código malicioso.

A diferencia del conocido typosquatting donde se juega con errores tipográficos comunes de los usuarios, en el slopsquatting la “confusión” la comete el propio modelo. Es un enfoque más sofisticado porque explota la confianza que depositamos en las sugerencias generadas por estas herramientas inteligentes. De modo que un desarrollador que confíe ciegamente en las sugerencias de la IA y las incluya en su proyecto, puede estar abriendo una puerta indeseada a su sistema.

¿Qué dicen los investigadores?

Un estudio reciente [5] realizado por universidades de Estados Unidos (entre ellas Virginia Tech y la Universidad de Texas en San Antonio) analizó más de medio millón de fragmentos de código generados con IA. Entre sus conclusiones:

• El 19,7% de los paquetes sugeridos por los modelos eran inexistentes.
• Los modelos de código abierto, como CodeLlama y WizardCoder, mostraron tasas de alucinación mayores (hasta 21,7%) frente a modelos comerciales como GPT-4 Turbo (3,59%).
• Muchas de estas alucinaciones eran recurrentes y persistentes: el 43% aparecieron en las 10 ejecuciones repetidas de las mismas consultas.
• El 38% de los nombres de paquetes inventados eran sorprendentemente similares a paquetes reales, a veces incluso válidos en otros lenguajes de programación,  lo que aumenta las posibilidades de que pasen desapercibidos.

Estas cifras nos dan una idea clara: no se trata de errores puntuales, sino de un patrón. Y ese patrón puede ser aprovechado como una vulnerabilidad para infiltrarse en la cadena de suministro del software. Lo que puede tener consecuencias serias para cualquier proyecto, sin importar su tamaño.

¿Y esto qué implica para quienes desarrollamos software?

En GMV somos plenamente conscientes de los beneficios que las herramientas de asistencia por IA pueden ofrecer, pero también hemos estudiado sus límites actuales pues están lejos de ser infalibles [5]. Las utilizamos como una ayuda para ser más eficientes siempre manteniendo un fuerte espíritu crítico sobre los resultados que generan. 

Aunque no hay recetas mágicas, aplicamos una serie de buenas prácticas para minimizar riesgos, entre ellas:

• Verificamos manualmente la existencia y procedencia fiable de cualquier paquete sugerido por una IA.
• Utilizamos herramientas de análisis de dependencias que identifican posibles vulnerabilidades y nos alertan sobre componentes sospechosos.
• Probamos el código en entornos seguros antes de integrarlo en sistemas reales.
• Formamos de manera continua a nuestros equipos en seguridad y en el uso responsable de herramientas de IA.
• Fomentamos la revisión entre pares, especialmente cuando se introduce código sugerido por IA.

Esta combinación de tecnología y criterio humano es fundamental para mantener la seguridad y la calidad de nuestros desarrollos.

¿Cómo podemos mitigar ese riesgo?

En GMV seguimos explorando y utilizando estas herramientas con entusiasmo, pero sin perder de vista la responsabilidad que tenemos como desarrolladores de sistemas críticos. El buen uso de cualquier tecnología depende de nuestras decisiones. La IA puede ser una gran aliada, pero necesita ser aplicada con juicio humano. Porque al final, más allá de las sugerencias inteligentes o las líneas de código automatizadas, lo que realmente marca la diferencia es el criterio profesional, la experiencia y el trabajo bien hecho.

Autor: Dr. David Miraut

Referencias