El slopsquatting es un ataque a la cadena de suministro de software que consiste en registrar en un repositorio público el nombre de un paquete que no existe, pero que los modelos de lenguaje alucinan con frecuencia. Seth Larson acuñó el término en abril de 2025, combinando AI slop y typosquatting. Quien instala la dependencia sugerida instala el paquete del atacante.
La decisión difícil no es técnica. Es admitir que en tu equipo ya hay agentes escribiendo código y proponiendo dependencias, que eso lleva meses pasando y que nadie ha definido quién revisa lo que acaba dentro del build. Yo he estado a los dos lados de esa conversación, la del ingeniero que instala lo que le sugieren porque funciona y la del responsable que descubre seis semanas más tarde que la revisión que daba por hecha no existía en ningún sitio, y puedo decir que el problema nunca aparece donde se busca.
TL;DR. El slopsquatting explota una propiedad medible de los modelos de lenguaje: alucinan nombres de paquetes y lo hacen de forma repetible. El atacante registra esos nombres en PyPI o npm y espera. La mecánica es la vieja ocupación de nombres, pero cambia la escala, porque ya no hay que adivinar qué teclea mal un humano y basta con observar qué inventa un modelo. El control que lo contiene no es una herramienta más, es criterio de ingeniería sobre qué entra en el build y quién lo aprueba. Y ese criterio, en el mercado español, apenas se está contratando.
El ataque consiste en registrar lo que el modelo inventa
Un asistente de código propone fastapi-middleware o aws-helper-sdk. Suena a librería real, encaja con la convención de nombres del ecosistema y resuelve el problema que tenías delante. No existe. O peor: existe desde hace tres semanas, porque alguien la registró esperando exactamente esta situación.
El nombre plausible es toda la eficacia del ataque. No hay exploit, no hay vulnerabilidad que parchear y no hay CVE que rastrear, porque técnicamente nada se ha roto: el desarrollador ha pedido una dependencia, el registro se la ha servido y el gestor de paquetes ha hecho su trabajo con normalidad absoluta.
Cómo funciona el ataque, paso a paso
La cadena tiene cuatro eslabones y ninguno requiere una vulnerabilidad técnica:
- Alucinación. El modelo sugiere una dependencia que no está en ningún registro público.
- Registro. El atacante, que observa qué nombres se repiten en las salidas de los modelos, publica un paquete con ese nombre exacto en PyPI, npm o el registro que corresponda.
- Instalación. Alguien copia el comando sugerido. O no lo copia nadie: un agente autónomo ejecuta el build y resuelve las dependencias sin intervención humana.
- Ejecución. El script de post-install corre con los permisos del entorno y se lleva las credenciales que encuentre.
El eslabón que ha cambiado es el tercero. Cuando la instalación la hace una persona hay una oportunidad de duda, un segundo en el que alguien puede mirar el nombre y pensar que no le suena; cuando la ejecuta un pipeline configurado para resolver dependencias sin aprobación, esa oportunidad simplemente no existe y el paquete entra en el artefacto antes de que nadie sepa que se ha planteado la pregunta.
Por qué las alucinaciones son predecibles, y por eso explotables
Si los modelos inventaran nombres al azar, el ataque no escalaría: habría que registrar millones de combinaciones para acertar una. No es aleatorio.
El estudio de Spracklen y otros, aceptado en el USENIX Security Symposium 2025, cuantifica el fenómeno. El porcentaje medio de paquetes alucinados es de al menos el 5,2% en modelos comerciales y del 21,7% en modelos open source.
Esa diferencia importa más que el promedio. Un equipo que ejecuta modelos open source por razones de coste, de latencia o de soberanía del dato asume una superficie de exposición cuatro veces mayor que uno que consume API comerciales. Esto convierte una elección de infraestructura o presupuesto en una decisión de seguridad que casi nunca se discute en esos términos.
Qué dice el mercado español: 1.602 ofertas frente a 2
Aquí el problema deja de ser técnico y pasa a ser organizativo. Según el análisis de mercado de Shakers sobre 15.618 ofertas tech españolas con skills etiquetadas, de un total de 18.341 recogidas entre el 14 de junio y el 3 de agosto de 2026:
- 1.602 ofertas exigen alguna skill de IA generativa: LangChain 535, OpenAI 408, Anthropic 187, LlamaIndex 156, Vertex AI 152, Hugging Face 98 y Claude 66.
- 2 ofertas exigen Snyk.
- Cero exigen SBOM. Cero exigen DevSecOps como skill etiquetada.
Esto no significa que España no contrate seguridad: buscando a texto completo, ciberseguridad aparece en 813 ofertas y DevSecOps en 337, muy por encima de las cifras anteriores. Pero esos totales no son comparables con los de arriba, porque la mayoría corresponde a menciones en la descripción corporativa de la empresa y no a un requisito real del puesto, y basta abrir el primer resultado de ciberseguridad para encontrar un ingeniero de desarrollo cuyas skills etiquetadas son JavaScript, Linux y Python. La afirmación que sí se sostiene es más estrecha y bastante más incómoda: en la señal de demanda por skill concreta, los controles específicos de cadena de suministro no aparecen, mientras la herramienta que crea la exposición aparece en 1.602 puestos.
Es la cara menos comentada del implementation gap que documentó BCG en enero de 2025, cuando midió que el 75% de las empresas había probado IA y solo el 25% había visto resultados. La adopción va por delante de la capacidad. En seguridad, ir por delante se paga distinto que en producto.
Slopsquatting frente a typosquatting: no es lo mismo
El typosquatting apuesta a que un humano se equivoque al teclear y registra reqeusts esperando a quien quería escribir requests. El slopsquatting no espera un error humano, espera una invención del modelo.
La consecuencia práctica es de cobertura. Un detector de typosquatting compara nombres contra un catálogo de paquetes legítimos y mide distancia de edición, de modo que su eficacia depende por completo de que el nombre malicioso se parezca a uno real; un paquete alucinado no se parece a nada existente, porque es un nombre nuevo, coherente con la convención del ecosistema y sin vecino cercano en el catálogo. Pasa el filtro sin activarlo.
Por qué un SBOM no te salva de un paquete alucinado
Esta parte suele sorprender. Un SBOM inventaría lo que hay dentro de tu artefacto y sirve para responder qué versión de qué librería estás ejecutando cuando aparece una vulnerabilidad. Hace bien su trabajo.
Pero el paquete alucinado que el atacante registró existe. Tiene nombre, versión, autor y checksum, así que aparecerá en el SBOM como una dependencia legítima más, porque formalmente lo es. El SBOM responde qué tienes. No responde si deberías tenerlo.
El control que cubre esa pregunta es de procedencia: verificar de dónde viene un artefacto y quién lo construyó, que es el terreno de SLSA y la trazabilidad de la cadena de suministro. Con un añadido que ningún framework resuelve por sí solo, y es que alguien tiene que decidir qué dependencias están permitidas antes de que el build las resuelva.
Qué capacidad necesitas en el equipo
No es una herramienta, es un criterio, y el criterio necesita a alguien que lo sostenga.
En concreto, tres capacidades que conviene poder señalar en el organigrama antes de ampliar el uso de agentes en el ciclo de desarrollo:
- Gobierno de dependencias. Quién mantiene el allowlist, con qué criterio se aprueba una librería nueva y qué ocurre cuando un agente propone una que no está en la lista.
- Permisos del agente. Qué puede ejecutar por su cuenta dentro del pipeline y qué exige aprobación humana. La mayoría de configuraciones por defecto son más permisivas de lo que el equipo cree.
- Evaluación adversaria de sistemas de IA. Probar el comportamiento del modelo antes de confiar en su salida, en la línea del red teaming aplicado a IA.
Ninguna de las tres es un puesto que haya que inventar. Son skills concretas, verificables una por una, que hoy conviven mal con la velocidad a la que se está adoptando la generación de código dentro de los equipos. Cerrar ese hueco con talento certificado en skills de IA, en plantilla o en equipos blended, es una decisión de infraestructura de contratación antes que una compra de herramienta.
Habla con un experto Shakers si necesitas cubrir esa capacidad con perfiles verificados.
Preguntas frecuentes sobre slopsquatting
- ¿El slopsquatting es lo mismo que el typosquatting?
-
No. El typosquatting explota errores de tecleo humanos y registra nombres parecidos a paquetes reales. El slopsquatting registra nombres que no se parecen a nada existente, porque los ha inventado un modelo de lenguaje. Los detectores basados en distancia de edición cubren el primero y no el segundo.
- ¿SLSA previene el slopsquatting?
-
Parcialmente. SLSA aporta procedencia verificable, es decir de dónde viene un artefacto y quién lo construyó. No responde a si esa dependencia debería estar en tu proyecto, que es justo la pregunta que abre el slopsquatting. Hace falta además una política de dependencias permitidas.
- ¿Un SBOM lo detecta?
-
No por sí solo. El paquete malicioso existe realmente en el registro público, así que aparece en el SBOM como una dependencia legítima con su nombre, versión y checksum. El SBOM inventaría lo que tienes; no evalúa si deberías tenerlo.
- ¿Qué perfil se encarga de esto en un equipo?
-
Habitualmente un perfil de seguridad de aplicaciones o de plataforma con criterio sobre la cadena de suministro, no un analista de seguridad generalista. Las tres capacidades implicadas son gobierno de dependencias, configuración de permisos de agentes en el pipeline y evaluación adversaria de sistemas de IA.
- ¿Con qué frecuencia alucinan los modelos nombres de paquetes?
-
Según el estudio de Spracklen y otros aceptado en el USENIX Security Symposium 2025, el porcentaje medio de paquetes alucinados es de al menos el 5,2% en modelos comerciales y del 21,7% en modelos open source. La exposición depende por tanto del tipo de modelo que use el equipo.
El slopsquatting no compromete a quien no revisa su código. Compromete a quien no ha decidido quién lo revisa. Y esa diferencia, que no se resuelve eligiendo mejor herramienta sino nombrando a un responsable con criterio sobre lo que entra en el build, es la que separa a los equipos que van a tener un incidente de los que ya saben qué van a hacer cuando llegue.