Atacs de slopsquatting

Atacs de slopsquatting: com un error d'IA es va convertir en una nova manera d'entrar a la cadena de subministrament de programari

El problema en una frase

La propera vegada un L'assistent d'IA recomana un paquet per instal·lar, realment comprovaràs si aquest paquet existeix? La majoria dels desenvolupadors no ho han fet. Aquesta bretxa entre el suggeriment i la verificació és exactament on comencen els atacs de slopsquatting, i és per això que comprendre tant l'evolució de slopsquatting com la prevenció pràctica de slopsquatting s'ha convertit en una prioritat real per als equips d'AppSec i DevSecOps.

Què és un atac de slopsquatting?

Un atac de slopsquatting és una variant de mecanografia tipogràfica (la pràctica de registrar un nom de domini o paquet que imita un de legítim a través d'una errada ortogràfica comuna, com ara sol·licituds en lloc de peticions, esperant que l'error tipogràfic de l'usuari el porti directament allà), però amb una diferència important en l'origen de l'error. El typosquatting explota els errors tipogràfics humans. Un atac de slopsquatting explota els errors que cometen els grans models lingüístics: un LLM "al·lucina" un nom de paquet que sona perfectament legítim però no existeix en cap registre públic, i un atacant hi arriba primer registrant aquest nom exacte abans que ho faci qualsevol persona amb bones intencions. 

El mecanisme darrere d'un atac típic de slopsquatting és simple, i aquesta simplicitat és exactament el que el fa efectiu:

  • Un desenvolupador demana a un assistent d'IA que l'ajudi a resoldre un problema de codificació.
  • El model genera una solució que importa o recomana instal·lar un paquet que no ha existit mai.
  • Un atacant que ha notat que diversos models repeteixen constantment el mateix nom al·lucinat registra aquest paquet a npm, PyPI o un altre registre públic, amb codi maliciós a l'interior. Aquest és el moment en què l'al·lucinació es converteix en un veritable atac de slopsquatting.
  • El següent desenvolupador que rebi el mateix suggeriment i no el verifiqui, instal·la el paquet ara real, que és una porta del darrere al seu entorn.

El terme "slopsquatting" va ser encunyat per Seth Larson, desenvolupador de seguretat resident a la Python Software Foundation, i popularitzat per Andrew Nesbitt, per descriure exactament aquest patró: una "al·lucinació de paquets" convertida en un vector d'atac.

L'evolució de l'abandonament: com una curiositat de recerca es va convertir en una amenaça real

El que és notable de l'evolució de l'slopsquatting no és només el concepte; sinó la rapidesa amb què va passar d'una observació de recerca a una classe d'atac documentada i mesurable.

2023: El primer senyal d'alerta. Investigador de seguretat Bar Lanyado va notar que diversos LLM van recomanar repetidament un paquet anomenat huggingface-cli, que no existeix (el paquet real s'instal·la amb pip install -U “huggingface_hub[cli]”). Per demostrar el risc, va penjar una versió buida d'aquell paquet a un registre públic. En tres mesos, havia rebut més de 30,000 descàrregues, sense cap promoció. El nom al·lucinat fins i tot va aparèixer al fitxer README d'un repositori vinculat a una investigació d'Alibaba, mostrant des del principi com aquests noms "falsos" podien filtrar-se a la documentació real i preparar l'escenari per als atacs de slopsquatting que seguirien.

2024: El risc passa de ser una entrada de blog d'un investigador a la cobertura tecnològica generalitzada. Al març 2024, El Registre va informar sobre com els models d'IA inventaven amb confiança noms de paquets de programari que els desenvolupadors després descarregaven, alguns d'ells potencialment enverinats amb programari maliciós. Aquesta cobertura va importar menys pel que revelava tècnicament i més pel que assenyalava: el cas huggingface-cli ja no era una curiositat aïllada; era el primer signe d'un patró prou greu perquè la premsa tecnològica convencional el denunciés, abans de l'estudi acadèmic a gran escala que confirmaria l'abast un any després.

2025: La primera mesura rigorosa i a gran escala del problema. L'article “Tenim un paquet per a tu! Una anàlisi completa de les al·lucinacions de paquets mitjançant la generació de codi LLM” (Spracklen et al., presentat a la Simposi de seguretat USENIX) va provar 16 models de generació de codi, tant comercials (GPT-4, GPT-3.5) com de codi obert (CodeLlama, DeepSeek, WizardCoder, Mistral), en 576,000 exemples de codi Python i JavaScript. Les troballes marquen un punt clar en l'evolució de l'slopsquatting, passant d'anècdota a dades:

  • El 19.7% dels paquets recomanats pels models no existien.
  • Els models de codi obert van al·lucinar molt més sovint (21.7% de mitjana) que els models comercials (5.2%).
  • En tots els models provats, els investigadors van registrar més de 205,000 noms de paquets al·lucinats únics, un conjunt prou gran com per alimentar atacs sostinguts de slopsquatting en múltiples ecosistemes.

Un detall crític de l'estudi, i probablement la raó per la qual l'evolució de l'slopsquatting s'ha accelerat en lloc d'esvair-se, és que els noms al·lucinats no són aleatoris i no canvien en cada intent. Els mateixos models tendeixen a repetir els mateixos noms inventats quan se'ls donen indicacions similars, cosa que significa que un atacant no necessita endevinar-ho. Només cal observar el comportament del model, identificar els noms que es repeteixen i registrar-los abans que ho faci un desenvolupador real. L'anàlisi de seguiment d'aquesta repetibilitat va trobar que quan els investigadors van tornar a executar indicacions idèntiques deu vegades cadascuna, el 43% dels noms de paquets al·lucinats van aparèixer en cada execució, la qual cosa demostra que la majoria de les al·lucinacions són artefactes repetibles en lloc de sorolls puntuals. Aquesta repetibilitat és el que converteix una al·lucinació puntual en un atac de slopsquatting escalable.

2026: De paquets aïllats a agents autònoms. Des de paquets aïllats fins a agents autònoms. Aquest any s'ha produït l'evidència més clara fins ara que l'"slopsquatting" ja no es limita a un desenvolupador que copia i enganxa una ordre suggerida de pip install o npm install. El gener de 2026, l'investigador de seguretat Charlie Eriksen va descobrir que els agents de codificació d'IA ja havien difós instruccions que feien referència a un paquet npm al·lucinat, react-codeshift (un nom que plausiblement combina dues eines reals, jscodeshift i react-codemod), a través de 237 repositoris, amb agents que encara intentaven instal·lar-lo diàriament. Eriksen va registrar el nom ell mateix, defensivament, abans que un atacant pogués utilitzar-lo com a arma. Per separat, un paquet maliciós real anomenat unused-imports, al·lucinat en lloc del legítim eslint-plugin-unused-imports, encara registrava aproximadament 233 descàrregues setmanals a principis de 2026, tot i que npm el va posar sota una retenció de seguretat, un signe de quant de temps pot seguir atraient víctimes un atac de "slopsquatting" fins i tot després d'haver estat marcat. Més recentment, el juliol de 2026, uns investigadors van descriure una tècnica relacionada, anomenada "HalluSquatting", que encadena una al·lucinació d'IA amb una injecció ràpida de manera que un agent de codificació d'IA que obté un recurs al·lucinat en nom d'un usuari pot ser segrestat per executar codi proporcionat per l'atacant, estenent l'evolució de l'slopsquatting d'un risc d'instal·lació passiu a un vector actiu d'execució remota de codi dins dels fluxos de treball de desenvolupament agentiu.

Per què la "codificació de vibracions" va ampliar la superfície per als atacs de slopsquatting

Els atacs de slopsquatting no importarien gaire si el codi generat per IA fos una pràctica de nínxol. No ho és. L'auge dels assistents de codificació, els agents autònoms i els fluxos de treball de "codificació vibratòria", on els desenvolupadors revisen cada cop menys codi abans d'executar-lo, ha canviat la superfície d'atac del programari de dues maneres concretes, i ambdues estan accelerant l'evolució del slopsquatting:

  • El punt d'entrada ja no és només el desenvolupador. Un atac de typosquatting abans depenia d'una sola persona que cometia un error d'escriptura. Ara, l'error es pot originar dins del propi model i propagar-se a centenars de desenvolupadors diferents que fan preguntes similars i reben la mateixa recomanació al·lucinada, multiplicant l'abast d'un únic atac de slopsquatting.
  • La superfície d'atac s'ha desplaçat més amunt de la cadena. Ja no n'hi ha prou amb observar el codi que escriu un humà. Els equips també han de vigilar les dependències que suggereix un assistent d'IA, els servidors MCP als quals es connecta i els agents que instal·len paquets de forma autònoma sense revisió humana directa. L'AppSec tradicional, dissenyat per revisar repositoris i recursos humans commits, mai va ser dissenyat per observar aquesta nova interacció entre el desenvolupador, la IA i el registre de paquets, que és exactament on ara s'amaguen els atacs de slopsquatting.

Res d'això vol dir que la IA generativa sigui inherentment insegura. Vol dir que introdueix un nou tipus de risc a la cadena de subministrament que les eines de seguretat tradicionals no estaven dissenyades per detectar, i que requereix els mateixos principis de verificació que ja apliquem a qualsevol dependència externa: no confiar per defecte, verificar la font i automatitzar aquesta verificació en lloc de confiar en la memòria o la vigilància de tots els desenvolupadors. Aquesta automatització és la base de qualsevol estratègia real de prevenció de slopsquatting.

Prevenció de l'ocupacions desubicades: què poden fer els equips avui dia

La bona notícia és que la prevenció de l'slopsquatting no requereix eines exòtiques. Requereix l'aplicació sistemàtica de pràctiques d'higiene de dependències que ja existeixen, però que molts equips es relaxen en el moment en què una IA en què confien "suggereix" el codi. Un enfocament eficaç de prevenció de l'slopsquatting sol combinar el següent:

  • Verifica manualment qualsevol paquet nou abans d'instal·lar-lo, sobretot quan prové del suggeriment d'un assistent d'IA. Confirma que existeix al registre oficial, qui el manté, quan es va publicar i si els seus números de descàrrega semblen reals. Aquest hàbit per si sol és la forma més barata de prevenció de l'slopsquatting disponible per a qualsevol equip.
  • Mai assumeixis que el codi generat per IA és segur per defecte. Un fragment de codi que "funciona" no vol dir que les seves dependències siguin legítimes. La revisió de dependències hauria de formar part de la revisió de codi, no una excepció.
  • Utilitza fitxers de bloqueig i verificació hash per fixar versions exactes i evitar que una actualització silenciosa s'intercanviï en un paquet diferent del que es va auditar originalment.
  • Implementa l'escaneig de dependències que marca patrons de risc més enllà de les CVE conegudes: paquets anòmals, noms sospitosament similars als existents, nous mantenidors sense historial o instal·lació de scripts amb un comportament inusual. Un paquet recentment publicat gairebé sense historial que imita de prop el nom d'alguna cosa "gairebé" familiar és exactament el patró que hi ha darrere de la majoria d'atacs de slopsquatting documentats fins ara.
  • Tracteu els registres públics amb el mateix escèpticcism com qualsevol altra font externa no verificada. El fet que instal·lació de pip or npm instal·lar no genera un error no és prova de legitimitat.
  • Formar equips de desenvolupament sobre el fet que la codificació assistida per IA no elimina la responsabilitat de verificar què s'instal·la; només afegeix un pas que s'ha d'integrar al flux de treball com a part de qualsevol pla seriós de prevenció de la desocupació.

Cap d'aquestes mesures és nova per si sola. El que ha canviat és l'escala: quan un suggeriment de dependència ja no prové de Stack Overflow o d'un col·lega, sinó d'un model que pot repetir el mateix error al·lucinat a milers de desenvolupadors diferents, la verificació manual, tot i que encara és necessària, deixa de ser suficient per si sola. És per això que més equips automatitzen aquesta capa de prevenció de slopsquatting dins dels seus... Anàlisi de la composició del programari (SCA) utillatges, en lloc de deixar-ho a la disciplina de cada desenvolupador.

Això és previcisEly, per què? ASPM plataformes M'agrada Xígeni integrar la detecció de dependències sospitoses, que cobreixi l'abusi tipogràfic, la confusió de dependències i els paquets maliciosos coneguts, en la mateixa anàlisi de codi obert i de dependències d'IA pipeline, de manera que la prevenció de l'slopsquatting no depèn que tots els desenvolupadors recordin comprovar-ho cada vegada que un assistent d'IA suggereixi una nova dependència.

FAQ

És el mateix un atac de slopsquatting que un atac de typosquatting?

No exactament. Tots dos impliquen registrar un nom de paquet fals per enganyar qui l'instal·li, però l'origen de l'error és diferent. El typosquatting explota els errors d'escriptura humans. Un atac de slopsquatting explota noms de paquets inventats (al·lucinats) per models d'IA, que un atacant registra abans que existeixin legítimament.

Pot un gestor de paquets prevenir automàticament aquest tipus d'atac?

No completament, i és precisament per això que la prevenció de slopsquatting no es pot aturar al nivell del gestor de paquets. Si un atacant registra el paquet al·lucinat abans que un desenvolupador intenti instal·lar-lo, la instal·lació es completarà sense cap error perquè el paquet existeix realment, tot i que és maliciós. Una prevenció eficaç necessita una verificació addicional de l'origen i el comportament del paquet.

Això només afecta els models de codi obert?

No. L'estudi de Spracklen et al. va trobar al·lucinacions en tots els models provats, inclosos els comercials, tot i que a una taxa significativament menor (5.2% enfront del 21.7% dels models de codi obert avaluats). Cap model està completament lliure del problema, i això explica en part per què l'evolució de l'slopsquatting va al ritme del creixement de la codificació assistida per IA en general.

És aquest un risc teòric o ja s'ha explotat?

L' huggingface-cli En aquest cas, un paquet buit carregat per un investigador que es va descarregar més de 30,000 vegades en tres mesos sense promoció, demostra que el risc no és només teòric: un nom al·lucinat només ha de ser prou coherent en diferents indicacions perquè algú el converteixi en un veritable atac de slopsquatting.

sca-tools-software-composition-analyse-tools
Prioritzar, solucionar i protegir els riscos del programari
Obtén el teu compte gratuït.
No es requereix cap targeta de crèdit.

Assegura el desenvolupament i el lliurament del teu programari

amb el paquet de productes Xygeni