Que é o slopsquatting?

Que é a slopsquatting? É un ataque no que os actores maliciosos rexistran os nomes exactos dos paquetes que os asistentes de codificación con IA alucinan, logo cargan eses paquetes con software malicioso e agardan a que un desenvolvedor os instale. Non se trata dun caso límite. Nunha investigación presentada en Seguridade USENIX 2025, O 19.7 % dos paquetes recomendados por modelos de codificación de IA en 576 000 mostras de código non existían, e os investigadores rexistraron máis de 205 000 nomes alucinados únicos nos modelos probados.

Entender o que é o *slopsquatting* (e o significado que ten na práctica) é importante porque non é só unha peculiaridade da IA. O *slopsquatting* é o sucesor da era da IA ​​de tipo-ocupación, cunha diferenza fundamental: a typosquatting depende dun erro de escritura dun humano, mentres que a slopsquatting depende dun erro do modelo, repetido de forma suficientemente predicible para que un atacante o poida explotar a escala. Esta guía explica que é a slopsquatting, por que se propaga máis rápido do que a revisión de paquetes pode detectala, que riscos crea e como as organizacións poden descubrila e previla antes de que chegue á produción.

Significado de Slopsquatting: Definición #

Significado de slopsquatting, formalmente: a práctica de rexistrar un nome de paquete que un modelo de linguaxe grande alucina, un nome inventado que soa plausible pero non existe en ningún rexistro público, e cargalo con código malicioso. antes de que un desenvolvedor real o instale baseándose na suxestión da IA.

O termo amplía o concepto de typosquatting (rexistro dun nome de paquete que imita un real a través dun erro ortográfico común) ao modo de fallo específico da IA ​​xerativa. Mentres que a typosquatting aproveita un erro tipográfico dun humano, a slopsquatting aproveita un Alucinacións dun modelo de IAnUn asistente de programación recomenda pip install ou npm install para un paquete que nunca existiu, e un atacante que detectou o mesmo nome inventado repetidamente en todas as solicitudes rexístrao primeiro.

O significado de "slopsquatting", en termos prácticos, é o seguinte: un ataque á cadea de subministración que converte un erro dun modelo nunha vulnerabilidade funcional, sen necesidade de erro humano máis alá de confiar na suxestión da IA. Non é teórico. Un único paquete alucinado, instalado como proba benigna en 2023, atraeu máis de 30,000 descargas en tres meses sen promoción e confirmou que as variantes maliciosas que explotan este patrón exacto están dispoñibles nos rexistros públicos hoxe en día.

Slopsquatting vs Typosquatting: Cal é a diferenza? #

O slopsquatting e o typosquatting comparten o mesmo resultado (un desenvolvedor instala un paquete malicioso crendo que é lexítimo), pero a orixe do erro é categoricamente diferente.

O typosquatting depende dun erro de escritura humano: un desenvolvedor pretende escribir solicitudes e, no seu lugar, escribe solicitudes, e un atacante que rexistrou ese nome mal escrito está á espera. O risco está ligado á pulsación de tecla dun desenvolvedor, a un momento de falta de atención.

A simulación de erros elimina por completo o erro humano e substitúeo por un erro do modelo, que se repite a escala en cada desenvolvedor que recibe unha solicitude similar. Unha análise de seguimento descubriu que, cando os investigadores reexectaban solicitudes idénticas dez veces cada unha, o 43 % dos nomes de paquetes alucinados aparecían en cada execución e o 58 % repetíanse máis dunha vez. Esa repetibilidade é o que fai que a simulación de erros sexa explotable: un atacante non necesita adiviñar un erro tipográfico. Só precisa observar que nome alucinado repite un modelo e rexistralo antes de que o faga un desenvolvedor real.

A maior diferenza é a escala. Un paquete con typosquat agarda un accidente de escritura. Un paquete con slopsquat agarda a que a mesma recomendación xerada por IA chegue ao seguinte desenvolvedor, e ao seguinte, e ao seguinte, en todas as organizacións que usan o mesmo modelo.

Por que se propagan as sentadillas de slopsquatting? #

A *slopsquatting* prolifera pola mesma razón pola que sempre prolifera a *typosquatting*: os atacantes explotan un patrón predicible no que os desenvolvedores confían por defecto. O novo é a escala de confianza.

O auxe da codificación asistida por IA, os axentes autónomos e os fluxos de traballo de "codificación por vibracións", onde os desenvolvedores revisan cada vez menos código antes de executalo, cambiaron a superficie de ataque do software de dúas maneiras concretas:

O punto de entrada xa non é só o desenvolvedor. Un ataque de typosquatting depende dun erro de escritura dunha persoa. O slopsquatting pode orixinarse dentro do propio modelo e propagarse a centos de desenvolvedores diferentes que fan preguntas similares e reciben a mesma recomendación alucinada, multiplicando o alcance dun só ataque.

A superficie de ataque ascendeu máis na cadea. Xa non abonda con revisar o código que escribe un humano. Os equipos tamén deben vixiar as dependencias que suxire un asistente de IA, os servidores MCP aos que se conecta e os axentes que instalan paquetes de forma autónoma sen revisión humana directa. AppSec tradicional, creada para revisar repositorios e recursos humanos commits, nunca foi deseñado para observar esta nova interacción entre o desenvolvedor, a IA e o rexistro de paquetes, que é exactamente onde se agocha o slopsquatting.

Riscos da ocupación ilegal #

A ocupación ilegal crea risco en todas as dimensións que se agravan entre si, e a tendencia está a acelerar en lugar de esvaecerse.

• Explotación repetible. Dado que os nomes alucinados non son aleatorios, o mesmo nome falso reaparece de forma predicible en sesións e modelos. Os atacantes non precisan adiviñar; só precisan observar o comportamento do modelo e rexistrar os nomes que se repiten, convertendo unha alucinación puntual nun ataque escalable e repetible.
• Propagación axente. O *slopsquatting* xa non se limita a que un desenvolvedor copie e pegue un comando de instalación suxerido. En xaneiro de 2026, os investigadores descubriron que os axentes de codificación de IA xa espallaran instrucións que facían referencia a un paquete npm alucinado en 237 repositorios, con axentes que aínda intentaban instalalo a diario, sen ningún humano no bucle para detectar o erro.
• Evasión da semellanza de nomes. Aproximadamente o 38 % dos nomes alucinados parécense moito a paquetes reais, o que reduce as probabilidades de que un desenvolvedor detecte a substitución dunha ollada. Un paquete malicioso que se atopa a un carácter de distancia dunha dependencia de confianza non parece sospeitoso; semella un erro tipográfico que cometerías ti mesmo.
• Exposición persistente despois da detección. Un paquete alucinado que substituíu un complemento lexítimo de ESLint seguía rexistrando descargas semanais mesmo despois de que o rexistro o colocase baixo unha retención de seguridade, proba de que marcar un paquete desaloxado non impide inmediatamente a súa instalación.

Onde se agocha o agachamento desleixado #

A parte máis difícil de detectar do slopsquatting é que non parece un ataque no momento en que ocorre; parece unha instalación normal de pip ou npm que se completa correctamente, porque o paquete existe realmente unha vez que un atacante o rexistrou.

O slopsquatting normalmente entra a través de:

• Asistentes e copilotos de codificación por IA. A suxestión inicial, un nome de paquete inventado presentado xunto a código lexítimo e funcional, é onde se orixina a vulnerabilidade. Nada no código circundante parece incorrecto, porque normalmente non o é; só a dependencia é falsa.
• Axentes de codificación autónomos. Os fluxos de traballo axentes que instalan dependencias sen revisión humana eliminan o único punto de control, un desenvolvedor que fai unha pausa para verificar un nome, que doutro xeito detectaría un paquete alucinado antes de que chegue a un proxecto.
• Xestores de paquetes sen paso de verificación. Nin a instalación de pip nin a de npm non producen erros cando o paquete de destino existe e é malicioso. A instalación complétase normalmente porque, desde a perspectiva do xestor de paquetes, non hai nada incorrecto.

Como descubrir e previr o slopsquatting #

Previr a desocupación ilegal non require ferramentas exóticas. Require aplicar prácticas de hixiene de dependencias que xa existen, sistematicamente, en lugar de relaxalas no momento en que unha IA "suxire" o código.

Verifica calquera paquete novo antes de instalalo, especialmente un suxerido por un asistente de IA. Confirma que existe no rexistro oficial, quen o mantén, cando se publicou e se os seus números de descarga parecen xenuínos.

Nunca supoñas que o código xerado por IA é seguro por defectoQue o código «funcione» non significa que as súas dependencias sexan lexítimas. A revisión das dependencias debería formar parte da revisión do código, non unha excepción a ela.

Implementar unha análise de dependencias que marque patróns de risco máis alá dos CVE coñecidos: paquetes anómalos, nomes sospeitosamente similares aos existentes, novos mantenedores sen historial ou scripts instalados con comportamento inusual.

Aplicar AI-SPM como capa de gobernanza. A xestión da postura de seguridade da IA ​​é a práctica deseñada para detectar exactamente este tipo de risco introducido pola IA a escala, descubrindo continuamente as dependencias suxeridas pola IA e puntuándoas antes de que un humano teña que lembrarse de comprobalo manualmente.

Protección contra a slopsquatting con Xygeni #

A ocupación ilegal de dependencias non se pode evitar unicamente coa vixilancia dos desenvolvedores. Unha política que di "verificar todos os paquetes suxeridos pola IA" non se aplica a toda unha organización onde as suxestións de dependencias chegan máis rápido do que pode seguir calquera proceso de revisión humano.

Xygeni's enfoque trata isto como un problema de detección continua: inventario de IA e Lista de materiais de IA superficie cada introdución de IA dependencia en todo o SDLC, dándolles aos equipos un rexistro dinámico do que un asistente de IA suxeriu e instalou realmente. Xygeni Shield, con tecnoloxía de MEW (Alerta temperá de software malicioso), detecta e bloquea paquetes maliciosos, incluídos os descoñecidos, antes de que exista unha sinatura, pechando exactamente o oco que deixan aberto os escáneres baseados en sinaturas.

Se os teus equipos empregan asistentes de codificación con IA, o problema do slopsquatting xa está presente. A pregunta é se o seguinte nome alucinado se detecta antes de que se instale.

FAQ #