I en kontrollert studie presentert kl. USENIX Sikkerhet 2025, ba forskere 16 store språkmodeller om å generere 576 000 kodeeksempler. Nesten én av fem av pakkene med åpen kildekode som disse modellene anbefalte eksisterte ikke: 205 474 unike falske pakkenavn, oppfunnet fra ingenting. Det ville vært en kuriositet hvis det var tilfeldig. Det er det ikke. 43 prosent av de hallusinerte navnene dukket opp igjen og igjen på gjentatte spørsmål. Angripere trenger ikke å gjette hva en kodeassistent vil finne opp. De kan se, vente og registrere navnet først.
Det er kjerneproblemet med AI-forsyningskjedesikkerhet i ett eksperiment: den samme AI-en som akselererer programvareutvikling har blitt et forutsigbart og utnyttbart inngangspunkt. Spørsmålet for sikkerhetsteam er ikke lenger om AI berører programvarens forsyningskjede. Det handler om hvorvidt du kan se hva den gjør på begge sider av kampen: AI-en som skriver koden din, AI-en som forsvarer koden din pipeline, og AI-en en angriper peker mot begge.
Hva er sikkerhet i forsyningskjeden for kunstig intelligens?
AI-forsyningskjedesikkerhet er praksisen med å beskytte programvareforsyningskjeden mot risikoer introdusert eller forsterket av kunstig intelligens, og å bruke AI til å forsvare den samme forsyningskjeden. Det befinner seg i skjæringspunktet mellom to trender som de fleste sikkerhetsprogrammer fortsatt behandler separat: AI-generert kode som kommer inn i kodebasen, og AI-drevne angrep som retter seg mot avhengigheter, bygge ... pipelines og utviklerverktøyene som omgir det.
Tradisjonell applikasjonssikkerhet spør om det finnes en kjent sårbarhet i en kjent komponent. AI-forsyningskjedesikkerhet stiller vanskeligere og raskere spørsmål: Eksisterer denne avhengigheten en AI-agent nettopp installerte faktisk, eller var den hallusinert? Oppfører denne nylig publiserte pakken seg ondsinnet, selv om det ikke finnes noen signatur for den ennå? Hvilke AI-modeller, agenter og tilkoblinger kjører på tvers av programvareutviklingslivssyklusen, og hva kan de nå?
Å svare på disse spørsmålene med den fartskoden som faktisk sender er hele disiplinen.
Hvordan AI ble en angrepsflate i forsyningskjeden
Angripere sluttet å eksperimentere med AI for en stund siden. De bygger det nå inn i operasjoner som er direkte rettet mot kode og dens avhengigheter, ikke bare innbokser og login sider.
Slopsquatting: å bevåpene det AI finner opp
Teknikken har nå fått et navn: hukebukk, skapt i april 2025 av Seth Larson, sikkerhetsutvikler ved Python Software Foundation. Mekanikken er enkel og brutal. AI-kodingsassistenter foreslår rutinemessig pakkenavn som ikke eksisterer. Fordi disse hallusinasjonene gjentar seg, kan en angriper registrere det oppfunnede navnet som en ekte, ondsinnet pakke og vente på at den neste utvikleren (eller den neste autonome agenten) skal installere den.
Presedensen er allerede dokumentert. I 2023, sikkerhetsforsker Bar Lanyado publiserte en tom plassholderpakke under et navn som modeller ofte hallusinerte, klemmeansikt-kliI løpet av tre måneder hadde den blitt lastet ned mer enn 30 000 ganger, og den hallusinerte installasjonskommandoen dukket til og med opp i et offentlig arkiv, README, fra et stort teknologiselskap. Det var en godartet test. Den samme strategiboken med en ekte nyttelast er nå en repeterbar forretningsmodell for angripere.
Autonome kodeagenter forverrer dette ved å fjerne det siste menneskelige kontrollpunktet. En agent som installerer avhengigheter uten gjennomgang eliminerer det ene øyeblikket der en utvikler kan ha lagt merke til at pakken så feil ut.
Ondsinnede pakker i industriell skala
Slopsquatting er én taktikk innenfor et mye større skifte. I 2025, kampanjer med store mengder ondsinnede pakker ble den grunnleggende driftsmodellen for angrep i forsyningskjeden, ettersom Xygenis Nye AppSec-angrepstrender for 2026 dokumenter. Angripere har tatt i bruk spamøkonomi: publiser tusenvis av skadelige pakker, godtar rask fjerning og stoler på sannsynlighet snarere enn vedvarende data. Offentlige registre inneholder nå hundretusenvis av nye skadelige pakker i året, og selv et kort eksponeringsvindu forurenser nedstrømsbygg.
MCP: et nytt, stort sett usikret tilkoblingslag
Model Context Protocol (MCP) lar AI-agenter koble seg til verktøy og datakilder. Den skaper også en ny angrepsflate som de fleste skannere aldri inspiserer. En ondsinnet MCP-server kan sitte usynlig ved siden av legitime servere, og kan nås av enhver agent med tilgang. OWASP publiserte en MCP Topp 10-liste i 2025 å katalogisere disse risikoene, fra rask injeksjon og verktøyforgiftning til uautoriserte servere som enhver agent på nettverket kan nå.
Hemmeligheter lekker gjennom AI-generert kode
Kompromitterte legitimasjonsopplysninger økte med omtrent 160 % i 2025 sammenlignet med 2024, ifølge Check Point External Risk Management (tidligere Cyberint), delvis drevet av AI-forbedret phishing og malware for informasjonstyveri. I programvaremiljøer er dette direkte knyttet til hardkodede nøkler og tokener i AI-generert kode. En kodeassistent som har inntatt en .og V filen i konteksten kan reprodusere en hemmelighet i et forslag, og angripere skanner etter akkurat det mønsteret.
Den menneskelige dimensjonen har heller ikke forsvunnet. IBMs rapport om kostnaden for et datainnbrudd i 2025 fant at blant datainnbrudd som involverte AI, brukte 37 % AI-generert phishing og 35 % brukte deepfake-etterligning, teknikker som i økende grad er rettet mot utviklere gjennom falsk rekrutteringskontakt og etterlignede vedlikeholdskontoer.
Hvordan AI beskytter forsyningskjeden
Det er nettopp de egenskapene som gjør AI farlig som gjør den nyttig for forsvarere. I forsyningskjeden er denne avveiningen mest konkret på fire steder.
Deteksjon av skadelig programvare før signaturen
Dette er den definerende egenskapen. Tradisjonell skanning venter på en kjent dårlig signatur før den kan flagge en pakke, noe som strukturelt er for tregt for angrep som samler tusenvis av nedlastinger innen timer etter publisering. Atferdsbasert deteksjon scorer i stedet en nylig publisert pakke i det øyeblikket den dukker opp: dens installasjonshandlinger, nettverkskall, obfuskasjonsmønstre og metadataavvik. Det lukker vinduet slopsquatting- og typosquatting-kampanjer er avhengige av. Shai-Hulud- og GlassWorm npm-kampanjene fra slutten av 2025, som signaturbaserte detektorer gikk fullstendig glipp av, er forhåndsdefinerte.cisely er case-atferdsanalysen bygget for å fange opp.
Prioritering etter utnyttbarhet, ikke volum
AIs mest praktiske bidrag til moderne AppSec er ikke å finne flere problemer; det kutter støyen fra det som allerede er funnet. Reachability-analyse avgjør om en sårbar kodebane faktisk kjøres. Utnyttelsespoeng veier reelle angrepsdata mot et rått CVSS-tall. Sammen lar de team fokusere på den andelen funnene som representerer ekte, utnyttbar risiko i stedet for å prioritere tusenvis av lavsignalvarsler manuelt.
Anomalideteksjon ved pipeline nivå
In Darktraces undersøkelse om tilstanden til AI-nettsikkerhet i 2026, sikkerhetsledere nevnte trusseldeteksjon og avvikssporing (72 %) som området der AI har størst effekt, foran automatisert respons (48 %) og sårbarhetshåndtering (47 %). Anvendt på CI/CD, dette betyr å flagge et installasjonsskript som oppfører seg ulikt noe som er sett før i det pipeline, eller en avhengighetsoppdatering som introduserer et uventet nettverkskall.
Automatisert, gjennomgåbar utbedring
Utover å finne og rangere risiko, genererer AI nå løsningen: en sikker, rammeverkspesifikk kodeendring sendt inn som en pull request snarere enn en billett som råtner i et etterslep. IBM fant at organisasjoner som bruker AI og automatisering i stor grad på tvers av sikkerhetsoperasjoner, reduserte den totale livssyklusen for sikkerhetsbrudd til 204 dager, mot 284 for de som ikke gjorde det (omtrent 80 dager raskere), samtidig som de sparte et gjennomsnitt på 1.9 millioner dollar per sikkerhetsbrudd. Å oppdage en risiko uten å lukke den flytter bare etterslepet; å kombinere AI-sortering med AI-genererte rettelser lukker sløyfen.
Styringsgapet de fleste teamene ikke har lukket
Her kommer den ubehagelige delen. Darktraces undersøkelse fra 2026 fant at 77 % av organisasjoner nå bruker generativ AI i sikkerhetsstakken sin, men bare 37 % har en formell policy for sikker bruk av AI. Dette tallet falt faktisk fra 45 % året før. Adopsjonen overgår styring, og angripere utnytter gapet.
For programvareteam viser det seg konkret: AI-kodingsassistenter, agenter og MCP-tilkoblinger kjører allerede på tvers av SDLC, ofte uten sentralisert innsikt i hva de har tilgang til eller hva de har introdusert. De fleste organisasjoner kan navngi sine skyleverandører. Svært få kan navngi alle AI-modeller, agenter og MCP-servere som er tilgjengelige fra en utviklers maskin. Denne inventarlisten, en AI Bill of Materials (AI-BOM), er grunnlaget som resten av AI-forsyningskjedesikkerheten er bygget på. Du kan ikke sikre det du ikke har inventarisert.
Hva AppSec-team bør gjøre nå
Ocuco gjennomsnittlig datainnbrudd kostet 4.44 millioner dollar i 2025 (IBM), og forsyningskjeden er i økende grad et av inngangspunktene. Den praktiske responsen er ikke å «adoptere AI» i det abstrakte. Det er en kort, konkret liste:
- Lag en oversikt over hvilken AI som kjører i din SDLC. Modeller, agenter, MCP-servere og AI-kodingsverktøy er ressurser. Bygg AI-BOM først.
- Behandle AI-generert kode som menneskeskrevet kode. Kode som kompileres er ikke automatisk sikker, og avhengighetene fortjener samme vurdering som alt annet.
- Oppdag skadelig programvare etter oppførsel, ikke signaturer. Signaturbasert skanning er strukturelt for treg for pakkekampanjer med stort volum og kort levetid.
- Prioriter etter utnyttbarhet, ikke varslingsvolum. Den defensive verdien av AI er å skille reell risiko fra støy, ikke å generere mer av den.
- Automatiser utbedring, ikke bare deteksjon. Deteksjon uten en løsning flytter bare etterslepet et annet sted.
Hvor AI-forsyningskjedesikkerheten er på vei
To mønstre vil definere de neste årene. For det første blir angrep forutsigbare i stor skala snarere enn tilfeldige: slopquatting fungerer førcisfordi AI-hallusinasjoner er konsistente, noe som betyr at forsvaret må gå fra engangssignaturer til mønstergjenkjenning som skaleres for å matche. For det andre går forsvaret fra å «varsle et menneske» til å «identifisere, score og svare før en sak finnes». Organisasjonene som vinner terreng er de som fanger opp en ondsinnet pakkes oppførsel ved publiseringstidspunktet, ikke venter på at en CVE skal skrives.
AI er din nyeste risiko og ditt beste forsvar, ofte i samme system
AI trekker i to retninger samtidig. Den gir angripere skalerbare, automatiserte verktøy, og den gir forsvarere muligheten til å oppdage og reagere i en skala manuell gjennomgang aldri kunne ha gjort. Denne dualiteten er nettopp grunnen til at AI-forsyningskjedesikkerhet ikke kan legges til som en ettertanke eller forbys direkte.
Dette er gapet Xygeni ble bygget for å lukke. Tidlig varsling om skadelig programvare (MEW) overvåker kontinuerlig offentlige og private registre og oppdager skadelige pakker i det øyeblikket de publiseres, før det finnes noen signatur, ved hjelp av AI-vurderinger validert av et menneskelig forskerteam. Xygeni Shield setter denne intelligensen i arbeid ved utviklerens endepunkt: den blokkerer skadelige pakker ved installasjon før skriptene deres kjører, og lager en oversikt over AI-verktøy, agenter og MCP-servere på hver maskin. Sammen er de spesialbygd for truslene denne artikkelen beskriver: slopsquatting, typosquatting, avhengighetsforvirring og vedlikeholderkompromittering, inkludert Shai Hulud og GlassWorm-angrepsklasser signaturbaserte verktøy som er oversett. Kombinert med tilgjengelighetsbasert prioritering, en AI-BOM på tvers av din SDLC, og automatisert pull-request-utbedring, AI-generert kode og AI-drevne angrep få den samme granskingen, uten å bremse utviklerne.
Start gratis. Xygenis utviklerplan koster €0: 10 arkiver, 200 skanninger i måneden, opptil 5 bidragsytere, ingen kredittkort. Sign up with GitHub, GitLab eller Google, og kjør din første skanning på under 10 minutter; Shield Endepunktbeskyttelse kommer snart til utviklerabonnementet.
FAQ
Hva er sikkerhet i forsyningskjeden for kunstig intelligens?
AI-forsyningskjedesikkerhet beskytter programvareforsyningskjeden mot risikoer som AI introduserer eller forsterker, for eksempel hallusinerte avhengigheter, AI-generert kode som inneholder sårbarheter og ondsinnede MCP-tilkoblinger, samtidig som AI brukes til å forsvare den gjennom atferdsbasert skadelig programvaredeteksjon, prioritering av utnyttbarhet og automatisert utbedring.
Hvordan brukes AI til å forsvare programvareforsyningskjeden?
AI muliggjør forsvar som signaturbaserte verktøy ikke kan matche: poengsetting av en nylig publisert pakkes oppførsel i det øyeblikket den vises, avgjørelse av om en sårbar kodebane faktisk er tilgjengelig, flagging av avvik pipeline aktivitet, og generere rammeverkspesifikke rettelser som pull requests i stedet for etterslepsbilletter.
Hvorfor kan ikke tradisjonelle skannere fange opp AI-drevne angrep i forsyningskjeden?
Tradisjonelle verktøy er avhengige av kjente signaturer og publiserte CVE-er, så de flagger bare en pakke etter at den allerede er identifisert som skadelig. Pakkekampanjer med stort volum og kort levetid samler opp nedlastinger innen timer etter publisering (lenge før en signatur finnes), og det er derfor atferdsbasert deteksjon før signatur er nødvendig.
Hva er en AI-BOM, og hvorfor er det viktig?
En AI-materialeliste (AI-BOM) er en oversikt over alle AI-modeller, agenter og MCP-tilkoblinger som kjører gjennom programvareutviklingssyklusen. Dette er viktig fordi du ikke kan sikre det du ikke har oversikt over, og de fleste organisasjoner har ingen sentralisert innsikt i hvilken AI som er tilgjengelig fra en utviklers maskin.
