Entelgy Security América analiza cómo la IA puede convertir una librería inexistente en una puerta de entrada para los atacantes. El fenómeno del slopsquatting aprovecha una debilidad cada vez más habitual en el desarrollo asistido por IA: paquetes que el modelo inventa, pero que un atacante puede registrar y utilizar para introducir código malicioso en una organización.
Un desarrollador le pide ayuda al asistente de IA. Recibe un fragmento de código funcional que importa una librería con nombre plausible. Ejecuta el comando de instalación. Funciona. El código entra al repositorio, pasa por el pipeline y llega a producción.
El detalle es que esa librería nunca existió. El modelo la inventó. Y alguien, sabiendo que el modelo inventa ese nombre con frecuencia, registró el paquete en el repositorio público antes, con código malicioso adentro.
El ataque tiene nombre: slopsquatting, término acuñado por Seth Larson, de la Python Software Foundation. Es primo del typosquatting, pero más difícil de frenar: el nombre no es un error de tipeo, es completamente nuevo, no hay heurística de similitud que lo detecte.
El tamaño de la superficie de ataque
Un estudio de investigadores de University of Texas at San Antonio, Virginia Tech y University of Oklahoma analizó 576 mil fragmentos de código generados por 16 modelos en Python y JavaScript. El 19,7% de los paquetes recomendados no existía en ningún repositorio público, más de 205 mil nombres ficticios distintos.
El número que le interesa al atacante es otro: el 43% de esos nombres alucinados se repitió en las diez ejecuciones del mismo prompt. La alucinación no es ruido aleatorio: es comportamiento predecible. Basta con ejecutar prompts comunes, anotar los nombres que aparecen siempre, registrarlos y esperar.
Los modelos comerciales alucinan menos, cerca del 5%, frente a más del 20% en modelos abiertos, pero el 5% de miles de sugerencias diarias sigue siendo volumen relevante. Y ya hay caso confirmado: el paquete malicioso unused-imports ejecutaba un script de posinstalación para robar credenciales y claves de API.
El tamaño de la superficie de ataque
La dependencia inventada es el vector más espectacular, pero no el más común. El Future of Application Security Report 2026 de Checkmarx, realizado por Censuswide con 2.350 CISOs, gerentes de AppSec y desarrolladores en 14 países, mide la distancia entre conciencia y práctica:
- El 96% de los desarrolladores ya tiene herramientas de IA dentro del IDE y casi todos las consideran eficaces, pero solo el 18% aplica seguridad de forma continua mientras escribe el código.
- Las organizaciones donde el 81% al 100% del código de producción es generado por IA tienen casi tres veces más probabilidad de publicar software con vulnerabilidades conocidas que aquellas donde la IA genera del 1% al 20% (47% contra 14%).
- El 75% de las organizaciones admite publicar código que ya sabe vulnerable, presionadas por plazos y complejidad. Y el 70% de los desarrolladores cree que el código generado por IA tiene más fallas, el 30% lo entrega igual.
Es decir: la IA no introdujo un tipo nuevo de vulnerabilidad. Multiplicó la velocidad de producción de todos los tipos antiguos, mientras la capacidad de revisión siguió siendo humana.
Y la ventana se achicó. Según la misma investigación, el tiempo promedio hasta la explotación de una vulnerabilidad cayó de unos 840 días en 2018 a menos de dos días en 2026. El backlog de corrección dejó de ser un problema de proceso y pasó a ser un problema de aritmética.
Siete controles, del más barato al más estructurante
- Archivo de lock obligatorio en todo proyecto. package-lock.json, poetry.lock, go.sum. Sin él, cada build es una nueva oportunidad de resolver una dependencia distinta de la revisada.
- Verificación de existencia y madurez del paquete en el pipeline. Un paquete creado hace seis días, con un mantenedor y sin historial merece bloqueo automático y revisión humana.
- Repositorio interno como único camino. Proxy corporativo con lista de paquetes aprobados. El desarrollador no instala directo del repositorio público, instala del espejo curado.
- Bloqueo de scripts de posinstalación por defecto. Es donde ejecuta el payload de la mayoría de los paquetes maliciosos.
- SCA y SBOM. SCA (Software Composition Analysis) identifica los componentes de terceros y sus vulnerabilidades; SBOM (Software Bill of Materials, la lista de ingredientes del software) documenta qué hay dentro de cada entrega. Sin ambos, responder “¿en cuáles de nuestros sistemas está ese paquete?” toma una semana.
- Revisión humana obligatoria para dependencias nuevas. Sobre todo las sugeridas por agentes de codificación, que instalan sin que nadie lea el comando.
- Política escrita para desarrollo asistido por IA. Qué se puede generar, qué requiere revisión, qué nunca entra sin pruebas. Sin política, cada desarrollador crea la suya.
Qué decirle al directorio
La IA para código no debe prohibirse, la ganancia de productividad es real. Lo que debe cambiar es la proporción. Si el 96% de los desarrolladores ya genera código con IA y solo el 18% verifica seguridad mientras escribe, el cuello de botella no es la conciencia: es la ejecución. Velocidad sin verificación no es productividad, es deuda de seguridad con plazo de explotación de dos días.
