I et kontrolleret studie præsenteret kl. USENIX Sikkerhed 2025, bad forskere 16 store sprogmodeller om at generere 576,000 kodeeksempler. Næsten hver femte af de open source-pakker, som disse modeller anbefalede, eksisterede ikke: 205,474 unikke falske pakkenavne, opfundet ud af ingenting. Det ville være en kuriositet, hvis det var tilfældigt. Det er det ikke. 43 procent af de hallucinerede navne dukkede op igen og igen på tværs af gentagne prompts. Angribere behøver ikke at gætte, hvad en kodeassistent vil opfinde. De kan se, vente og registrere navnet først.
Det er kerneproblemet ved AI-forsyningskædesikkerhed i ét eksperiment: den samme AI, der accelererer softwareudvikling, er blevet et forudsigeligt og udnytteligt indgangspunkt til den. Spørgsmålet for sikkerhedsteams er ikke længere, om AI berører softwareforsyningskæden. Det handler om, om man kan se, hvad den gør på begge sider af kampen: AI'en skriver din kode, AI'en forsvarer din pipeline, og den AI, som en angriber peger på begge.
Hvad er AI-forsyningskædesikkerhed?
AI-forsyningskædesikkerhed er praksissen med at beskytte softwareforsyningskæden mod risici introduceret eller forstærket af kunstig intelligens, og med at bruge AI til at forsvare den samme forsyningskæde. Det befinder sig i krydsfeltet mellem to tendenser, som de fleste sikkerhedsprogrammer stadig behandler separat: AI-genereret kode, der kommer ind i kodebasen, og AI-drevne angreb, der er rettet mod afhængigheder, opbygning pipelines og de udviklerværktøjer, der omgiver det.
Traditionel applikationssikkerhed spørger, om der findes en kendt sårbarhed i en kendt komponent. AI-forsyningskædesikkerhed stiller sværere og hurtigere spørgsmål: Eksisterer denne afhængighed, som en AI-agent lige har installeret, faktisk, eller var den hallucineret? Opfører denne nyligt udgivne pakke sig ondsindet, selvom der endnu ikke findes nogen signatur til den? Hvilke AI-modeller, agenter og forbindelser kører på tværs af softwareudviklingslivscyklussen, og hvad kan de nå?
At besvare disse spørgsmål med den hastighed, koden der faktisk sender, er hele disciplinen.
Hvordan AI blev en angrebsflade i forsyningskæden
Angribere stoppede med at eksperimentere med AI for et stykke tid siden. De indbygger det nu i operationer, der er direkte rettet mod kode og dens afhængigheder, ikke kun indbakker og login sider.
Slopsquatting: At bevæbne det, AI opfinder
Teknikken har nu et navn: slopsquatting, opfundet i april 2025 af Seth Larson, sikkerhedsudvikler hos Python Software Foundation. Mekanikken er enkel og brutal. AI-kodningsassistenter foreslår rutinemæssigt pakkenavne, der ikke findes. Fordi disse hallucinationer gentager sig, kan en angriber registrere det opfundne navn som en ægte, ondsindet pakke og vente på, at den næste udvikler (eller den næste autonome agent) installerer den.
Præcedensen er allerede dokumenteret. I 2023, sikkerhedsforsker Bar Lanyado udgav en tom pladsholderpakke under et navn, der viser, at modeller ofte hallucinerede, huggingface-cliInden for tre måneder var den blevet downloadet mere end 30,000 gange, og den hallucinerede installationskommando dukkede endda op i et offentligt README-arkiv fra en stor teknologivirksomhed. Det var en godartet test. Den samme playbook med en reel nyttelast er nu en gentagelig forretningsmodel for angribere.
Autonome kodeagenter forværrer dette ved at fjerne det sidste menneskelige kontrolpunkt. En agent, der installerer afhængigheder uden gennemgang, eliminerer det ene øjeblik, hvor en udvikler måske har bemærket, at pakken så forkert ud.
Ondsindede pakker i industriel skala
Slopsquatting er én taktik inden for et meget større skift. I 2025, kampagner med store mængder ondsindede pakker blev den grundlæggende driftsmodel for angreb i forsyningskæden, da Xygenis Nye AppSec-angrebstendenser i 2026 dokumenter. Angribere har taget spam-økonomi til sig: udgiver tusindvis af ondsindede pakker, accepterer hurtig fjernelse og stoler på sandsynlighed snarere end vedholdenhed. Offentlige registre indeholder nu hundredtusindvis af nye ondsindede pakker om året, og selv et kort eksponeringsvindue forurener downstream-builds.
MCP: et nyt, stort set usikret forbindelseslag
Model Context Protocol (MCP) giver AI-agenter mulighed for at oprette forbindelse til værktøjer og datakilder. Det skaber også en frisk angrebsflade, som de fleste scannere aldrig inspicerer. En ondsindet MCP-server kan sidde usynligt ved siden af legitime servere og være tilgængelig for enhver agent med adgang. OWASP offentliggjorde en MCP Top 10 i 2025 at katalogisere disse risici, fra hurtig injektion og værktøjsforgiftning til uautoriserede servere, som enhver agent på netværket kan nå.
Hemmeligheder lækker gennem AI-genereret kode
Ifølge Check Point External Risk Management (tidligere Cyberint), delvist drevet af AI-forbedret phishing og malware til informationstyveri. I softwaremiljøer knyttes det direkte til hardcodede nøgler og tokens i AI-genereret kode. En kodningsassistent, der har indtaget en .env filen i sin kontekst kan reproducere en hemmelighed i et forslag, og angribere scanner efter præcis det mønster.
Den menneskelige dimension er heller ikke forsvundet. IBMs rapport om omkostningerne ved et databrud fra 2025 viste, at blandt databrud, der involverede AI, brugte 37 % AI-genereret phishing, og 35 % brugte deepfake-efterligning, teknikker der i stigende grad er rettet mod udviklere gennem falsk rekrutteringskontakt og efterlignede vedligeholdelseskonti.
Hvordan AI beskytter forsyningskæden
De egenskaber, der gør AI farlig, er præcis det, der gør den nyttig for forsvarere. I forsyningskæden er denne afvejning mest konkret fire steder.
Malware-detektion før signaturen
Dette er den definerende funktion. Traditionel scanning venter på en kendt dårlig signatur, før den kan markere en pakke, hvilket strukturelt er for langsomt til angreb, der genererer tusindvis af downloads inden for få timer efter offentliggørelse. Adfærdsbaseret detektion scorer i stedet en nyligt offentliggjort pakke i det øjeblik, den vises: dens installationshandlinger, netværkskald, obfuskationsmønstre og metadata-anomalier. Det lukker vinduet, som slopsquatting- og typosquatting-kampagner er afhængige af. Shai-Hulud- og GlassWorm npm-kampagnerne fra slutningen af 2025, som signaturbaserede detektorer fuldstændigt overså, er præ...cisely casen er adfærdsanalyse bygget til at fange.
Prioritering efter udnyttelsesgrad, ikke volumen
AI's mest praktiske bidrag til moderne AppSec er ikke at finde flere problemer; det reducerer støjen fra det, der allerede er fundet. Tilgængelighedsanalyse bestemmer, om en sårbar kodesti rent faktisk udføres. Udnyttelsesscoring vejer angrebsdata fra den virkelige verden mod et råt CVSS-tal. Sammen lader de teams fokusere på den del af fund, der repræsenterer en reel, udnyttelig risiko, i stedet for at prioritere tusindvis af lavsignalalarmer manuelt.
Anomalidetektion ved pipeline niveau
In Darktraces undersøgelse af tilstanden af AI-cybersikkerhed i 2026nævnte sikkerhedsledere trusselsdetektering og anomaliespotting (72 %) som det område, hvor AI har den største effekt, foran automatiseret respons (48 %) og sårbarhedsstyring (47 %). Anvendt på CI/CD, dette betyder at markere et installationsscript, der opfører sig ulig noget, der er set før i det pipelineeller en afhængighedsopdatering, der introducerer et uventet netværksopkald.
Automatiseret, gennemgåelig afhjælpning
Ud over at finde og rangere risici genererer AI nu løsningen: en sikker, framework-specifik kodeændring, der indsendes som en pull request snarere end en billet, der rådner op i en efterslæbning. IBM fandt ud af, at organisationer, der bruger AI og automatisering i vid udstrækning på tværs af sikkerhedsoperationer, reducerede deres samlede livscyklus for brud til 204 dage, mod 284 for dem, der ikke gjorde det (ca. 80 dage hurtigere), samtidig med at de sparede i gennemsnit 1.9 millioner dollars pr. brud. At detektere en risiko uden at lukke den flytter blot efterslæbet; at kombinere AI-triage med AI-genererede rettelser lukker kredsløbet.
Det ledelseskløft, som de fleste teams ikke har lukket
Her er den ubehagelige del. Darktraces undersøgelse fra 2026 viste, at 77 % af organisationer nu bruger generativ AI i deres sikkerhedsstak, men kun 37 % har en formel politik for sikker brug af AI. Dette tal faldt faktisk fra 45 % året før. Implementeringen overgår governance, og angribere udnytter hullet.
For softwareteams viser det sig konkret: AI-kodningsassistenter, agenter og MCP-forbindelser kører allerede på tværs af SDLC, ofte uden centraliseret indsigt i, hvad de tilgår, eller hvad de har introduceret. De fleste organisationer kan navngive deres cloududbydere. Meget få kan navngive alle AI-modeller, agenter og MCP-servere, der kan nås fra en udviklers maskine. Denne opgørelse, en AI Bill of Materials (AI-BOM), er fundamentet for resten af AI-forsyningskædens sikkerhed. Du kan ikke sikre det, du ikke har opgjort.
Hvad AppSec-teams bør gøre nu
gennemsnitligt databrud kostede 4.44 millioner dollars i 2025 (IBM), og forsyningskæden er i stigende grad et af indgangspunkterne. Det praktiske svar er ikke "adopter AI" i abstrakt forstand. Det er en kort, konkret liste:
- Lav en oversigt over, hvilken AI der kører i din SDLC. Modeller, agenter, MCP-servere og AI-kodningsværktøjer er aktiver. Byg AI-BOM'en først.
- Behandl AI-genereret kode som menneskeskrevet kode. Kode, der kompilerer, er ikke automatisk sikker, og dens afhængigheder fortjener den samme gennemgang som alt andet.
- Opdag malware ud fra adfærd, ikke signaturer. Signaturbaseret scanning er strukturelt for langsom til pakkekampagner med stort volumen og kort levetid.
- Prioritér efter udnyttelsesevne, ikke alarmvolumen. Den defensive værdi af AI ligger i at adskille reel risiko fra støj, ikke i at generere mere af den.
- Automatiser afhjælpning, ikke kun detektion. Detektion uden en løsning flytter blot efterslæbet et andet sted hen.
Hvor AI-forsyningskædesikkerheden bevæger sig hen
To mønstre vil definere de næste par år. For det første bliver angrebene forudsigelige i stor skala snarere end tilfældige: slopsquatting fungerer forud forcisfordi AI-hallucinationer er konsistente, hvilket betyder, at forsvaret skal skifte fra engangssignaturer til mønstergenkendelse, der skalerer for at matche. For det andet bevæger forsvaret sig fra at "advare et menneske" til at "identificere, score og reagere, før en ticket findes". De organisationer, der vinder frem, er dem, der fanger en ondsindet pakkes adfærd på udgivelsestidspunktet og ikke venter på, at en CVE bliver skrevet.
AI er din nyeste risiko og dit bedste forsvar, ofte i det samme system
AI trækker i to retninger på én gang. Den giver angribere skalerbare, automatiserede værktøjer, og den giver forsvarere evnen til at opdage og reagere i et omfang, som manuel gennemgang aldrig ville have kunnet. Denne dualitet er præcis grunden til, at AI-forsyningskædesikkerhed ikke kan tilføjes som en eftertanke eller forbydes direkte.
Dette er hullet Xygeni blev bygget for at lukke. Tidlig advarsel om malware (MEW) overvåger løbende offentlige og private registre og registrerer ondsindede pakker i det øjeblik, de offentliggøres, før der findes nogen signatur, ved hjælp af AI-vurderinger valideret af et menneskeligt forskerteam. Xygeni Shield sætter denne intelligens i arbejde ved udviklerens slutpunkt: den blokerer ondsindede pakker på installationstidspunktet, før deres scripts kører, og laver en oversigt over AI-værktøjer, agenter og MCP-servere på hver maskine. Sammen er de specialbygget til de trusler, som denne artikel beskriver: slopsquatting, typosquatting, afhængighedsforvirring og vedligeholderkompromittering, herunder Shai Hulud og GlassWorm-angrebsklasser, signaturbaserede værktøjer, der er gået glip af. Kombineret med tilgængelighedsbaseret prioritering, en AI-BOM på tværs af din SDLCog automatiseret pull-request-afhjælpning, AI-genereret kode og AI-drevne angreb få den samme granskning, uden at bremse udviklerne.
Start gratis. Xygenis udviklerplan koster €0: 10 arkiver, 200 scanninger om måneden, op til 5 bidragydere, intet kreditkort. Sign up with GitHub, GitLab eller Google, og kør din første scanning på under 10 minutter; Shield Endpoint-beskyttelse kommer snart til udviklerabonnementet.
Ofte stillede spørgsmål
Hvad er AI-forsyningskædesikkerhed?
AI-forsyningskædesikkerhed beskytter softwareforsyningskæden mod risici, som AI introducerer eller forstærker, såsom hallucinerede afhængigheder, AI-genereret kode, der indeholder sårbarheder, og ondsindede MCP-forbindelser, samtidig med at AI bruger den til at forsvare den gennem adfærdsbaseret malwaredetektion, prioritering af udnyttelsesmuligheder og automatiseret afhjælpning.
Hvordan bruges AI til at forsvare softwareforsyningskæden?
AI muliggør forsvar, som signaturbaserede værktøjer ikke kan matche: scorer en nyligt udgivet pakkes adfærd i det øjeblik, den vises, bestemmer, om en sårbar kodesti rent faktisk er tilgængelig, markerer anomale fejl pipeline aktivitet og generering af framework-specifikke rettelser som pull requests i stedet for efterslæbssager.
Hvorfor kan traditionelle scannere ikke fange AI-drevne angreb i forsyningskæden?
Traditionelle værktøjer er afhængige af kendte signaturer og offentliggjorte CVE'er, så de markerer kun en pakke, når den allerede er blevet identificeret som skadelig. Pakkekampagner med stort volumen og kort levetid genererer downloads inden for få timer efter offentliggørelsen (længe før en signatur findes), hvilket er grunden til, at adfærdsbaseret detektion før signatur er påkrævet.
Hvad er en AI-BOM, og hvorfor er det vigtigt?
En AI Bill of Materials (AI-BOM) er en oversigt over alle AI-modeller, agenter og MCP-forbindelser, der kører på tværs af softwareudviklingslivscyklussen. Det er vigtigt, fordi du ikke kan sikre det, du ikke har opført, og de fleste organisationer har ingen centraliseret indsigt i, hvilken AI der er tilgængelig fra en udviklers maskine.
