Bed en AI-assistent om kode, og den importerer af og til et bibliotek, der lyder helt rigtigt og aldrig har eksisteret. Installationen fejler, og du går videre. Det interessante er, hvad der sker, når den ikke fejler.
Pakke-hallucination: hvorfor de opfundne navne går igen
Det er den nyeste af de fem veje ind i en software-forsyningskæde — og den, der ikke fandtes for fem år siden.
Sprogmodeller producerer plausibel tekst, og et pakkenavn er tekst. Når en model skal bruge et bibliotek til at ændre størrelse på billeder, er et navn formet som et rigtigt billedbibliotek en meget sandsynlig fortsættelse — uanset om nogen nogensinde har udgivet det.
To egenskaber gør det fra en irritation til et angreb. For det første er de opfundne navne ikke tilfældige: spørger man mange modeller om den samme slags opgave, går de samme plausible navne igen, fordi de trækker på lignende træningsdata og lignende navnekonventioner. For det andet lader pakke-registries hvem som helst overtage et ubrugt navn med det samme.
Gentagelsen er blevet målt. Offentliggjort forskning i pakke-hallucination i LLM-genereret kode har fundet, at en betydelig andel af de anbefalede pakkereferencer peger på noget, der ikke findes — og, det afgørende, at mange af de opfundne navne dukker op igen ved gentagne kørsler af den samme prompt. Gentagelig er den egenskab, en angriber skal bruge: et navn, der optræder én gang, er en irritation, og et navn, der optræder pålideligt, er et mål, man kan registrere på forhånd.
Så en angriber samler de navne, modeller hallucinerer, registrerer dem og udgiver noget, der virker — plus et installationsscript. Den næste udvikler, hvis assistent foreslår det navn, får kode, der virker, og en last med. Teknikken hedder slopsquatting, efter den AI-slop, navnene stammer fra.
Hvorfor de tjek, du allerede har, ikke fanger det
Det er den del, der betyder noget, når man vurderer værktøjer, for to eksisterende forsvar ser ud, som om de burde dække — og gør det ikke.
Typosquat-detektion er blind over for det. Typosquatting virker ved at måle redigeringsafstand: reqeusts ligger én ombytning fra requests og bliver derfor markeret. Et hallucineret navn er ikke en stavefejl af noget som helst. Det er et velformet, fornuftigt navn på et bibliotek, der bare ikke findes. Der er ingenting i nærheden at sammenligne med.
Malware-feeds er reaktive. En advarsel, der udpeger en pakke som ondsindet, findes først, efter nogen har analyseret og indberettet den. Den dag, angriberen udgiver, nævner intet feed den. Netop det vindue — mellem udgivelse og opdagelse — er dér, hvor assistenten anbefaler den.
Begge forsvar er værd at have. Ingen af dem ser det her.
Det ene, en angriber ikke kan forfalske
En historie.
En pakke, der blev registreret i sidste uge for at fange hallucinerede imports, har nødvendigvis ligget på registryet i en uge. Den kan ikke have års udgivelser, en lang issue-historik eller en langsom ophobning af projekter, der afhænger af den, for det tager tid — og tid er det ene input, der ikke kan forfalskes.
Så signalet er alder, og det bør være den eneste udløser: en direkte afhængighed, der er udgivet første gang inden for cirka de sidste halvfems dage, fortjener et kig. Ikke fordi nye pakker er dårlige — det overvældende flertal er fuldstændig uskyldige — men fordi netop dette angreb ikke kan undgå egenskaben.
Alt andet mistænkeligt ved sådan en pakke bør behandles som en skærpende omstændighed på en ung pakke, aldrig som et fund i sig selv:
- Installationsscripts. Kode, der kører ved installation, før du selv har kørt noget. På en pakke udgivet i sidste uge er det det stærkeste enkeltsignal, der findes.
- Intet kildekode-repository. Ingenting at læse, ingenting at tjekke.
- En enkelt vedligeholderkonto, oprettet nogenlunde samtidig med pakken.
Anvendt på etablerede pakker ville hver af dem give konstant støj — masser af respektable biblioteker har installationsscripts og én vedligeholder. Anvendt på en pakke, der er ni dage gammel, er de forskellen på "sandsynligvis fint" og "kig på det her nu".
Følgeslutningen er, at fundet bør udløbe. Når pakken bliver ældre end vinduet, lukker advarslen sig selv, og de almindelige advarsels- og malwaretjek overtager vagten. En permanent advarsel om en pakke, der nu har eksisteret i et år, er støj.
Installerer din assistent selv pakker, er det her en af grundene til, at netop den rettighed er værd at tage stilling til.
Hvad man gør ved det i praksis
Den vane, der er værd at bygge, er lille: når en assistent foreslår en afhængighed, du ikke har hørt om, så slå den op før installation, ikke efter. Tjek registry-siden for udgivelsesdato, antal udgivelser og om der findes et kildekode-repository. Det tager tredive sekunder og fanger langt størstedelen af den her klasse.
Ud over vanen hjælper en lockfile mere, end man skulle tro. Den fastlåser præcis, hvad der blev installeret, så spørgsmålet "hvornår kom den her ind, og hvem tilføjede den?" har et svar i versionsstyringen frem for i nogens hukommelse.
Hvad er slopsquatting?
Slopsquatting er et angreb, der udnytter, at AI-kodeassistenter opfinder pakkenavne, som ikke findes. Fordi modeller hallucinerer de samme plausible navne igen og igen, kan en angriber registrere navnene på et offentligt registry og udgive kode, der virker, med en ondsindet last. Den næste udvikler, hvis assistent foreslår det navn, installerer angriberens pakke. Navnet kommer af den AI-slop, de opfundne navne stammer fra.
Hvorfor fanger typosquat-detektion ikke hallucinerede pakker?
Typosquat-detektion virker ved redigeringsafstand — den markerer et navn, der ligger et eller to tegn fra en populær pakke, for eksempel en ombytning eller et fordoblet bogstav. Et hallucineret pakkenavn er ikke en stavefejl af noget: det er et velformet, fornuftigt navn på et bibliotek, der bare aldrig har eksisteret, så der findes ingen rigtig pakke i nærheden at måle det mod. Tjekket har ingenting at sammenligne med.
Hvordan ser jeg, om en pakke foreslået af AI er ægte?
Slå pakken op på dens registry før installation, ikke efter, og tjek tre ting: hvornår den blev udgivet første gang, hvor mange udgivelser den har, og om den linker til et rigtigt kildekode-repository. En pakke oprettet inden for de seneste måneder, med én udgivelse og intet repository, fortjener skepsis — især hvis den kører et installationsscript. Det tjek tager omkring tredive sekunder og fanger hele denne klasse af angreb.
Er nye pakker altid farlige?
Nej. Nyudgivne pakker er ikke i sig selv farlige, og at behandle dem sådan ville gøre signalet ubrugeligt. Det overvældende flertal af nyudgivne pakker er fuldstændig uskyldige, og derfor bør alder alene udløse et kig og ikke en alarm — og derfor betyder skærpende omstændigheder som installationsscripts, manglende kildekode-repository eller en helt ny vedligeholderkonto kun noget i kombination med ung alder. Advarslen bør også udløbe, når pakken har eksisteret længe nok til at have en rigtig historie.
Hvor CodeControl passer ind
CodeControl tjekker oprettelsesdatoen i registryet for hver direkte afhængighed og rejser et omdømme-fund for alt, der er udgivet første gang inden for halvfems dage. Alder er den eneste udløser; installationsscripts, manglende kildekode-repository og en enlig vedligeholder meldes som skærpende omstændigheder på en ung pakke og ikke som fund mod en etableret. Fundet lukker sig selv, når pakken bliver gammel nok, hvorfra malware- og advarselstjekkene overtager vagten. Det ligger side om side med detektion af typosquatting og dependency confusion.