Tekoälyagenttien toimitusketjun suojaus oli ennen yksinkertaista, pääasiassa siksi, että ihminen seisoi aina paketin nimen ja koontiversion välissä. Kahdenkymmenen vuoden ajan tämä oli koko malli: joku luki nimen ennen kuin se syötettiin sisään. Ei aina huolellisesti. Mutta joku luki sen.
Se on nyt poissa. Jos tekoälymallilta kysytään kirjastoa tänään, noin joka viides suositeltu paketti ei ole olemassa. Hyökkääjät tietävät tämän, joten he rekisteröivät ensin nämä nimet. Agentti asentaa ne, testaa ne ja siirtyy eteenpäin, eikä kukaan lue mitään siltä väliltä. Juuri tässä kohtaa tekoälyagentin toimitusketjun turvallisuus pettää tällä hetkellä: ei jossain tulevaisuuden skenaariossa, vaan pipelinejuoksee tänään.
Alan toimiala on käyttänyt kaksi vuosikymmentä rakentaakseen kontrolleja kehittäjän ympärille, joka lukee, tarkistaa ja päättää. Tämä kehittäjä ei ole enää viimeinen tarkastuspiste ennen kuin riippuvuus lisätään kokoonpanoon. Joten todellinen kysymys ei ole, tuoko agenttinen tekoäly uusia riskejä, vaan se, mitä jää jäljelle, kun ihmisen tekemä tarkastuspiste on poistettu.
”Tekoälyn ehdotuksista” ”Tekoälyn toimiin”
Kaksi vuotta sitten apukehittäjä ehdotti koodilohkoa, kehittäjä luki sen ja päätti, pitäisikö sen säilyttää. Tämä työnkulku on suurelta osin poissa. Agenttityökalut asentavat nyt riippuvuuksia, käynnistävät säilöt ja käynnistävät... pipeline ryhtyvät toimiin oma-aloitteisesti ja raportoivat usein vasta jälkikäteen ja vain jos jokin menee pieleen.
Muutos tapahtui vaiheittain, ja useimmat tiimit ovat pidemmällä kuin heidän kirjallinen tietoturvakäytäntönsä myöntää. Varhaiset agenttityökalut pyysivät hyväksyntää ennen jokaista muutosta, ja kehittäjät painoivat "kyllä" niin usein, että vahvistusvaiheella ei ollut enää mitään merkitystä. Nykypäivän agentit eivät useimmiten kysy ollenkaan. Ne keskeyttävät vain arkaluontoisiksi merkittyjen toimintojen, kuten komentosarjan suorittamisen, ja tyypillisen pull request Agentin luoma teksti voi sisältää tuhansia rivejä, joita kukaan ihminen ei itse asiassa lue päästä päähän ennen yhdistämistä.
Käyttöoikeusongelma pahentaa tätä. Useimmissa kokoonpanoissa agentti toimii kehittäjänä, ja sillä on pääsy kaikkeen, mihin kehittäjän kone voi päästä käsiksi: ympäristömuuttujiin, pilvitunnuksiin, rekisteritietoihin ja SSH-avaimiin. Kun agentti asentaa jotakin ja skripti käynnistyy asennuksen aikana, se perii imitoimansa ihmisen täyden toimintasäteen. Tässä kohtaa tekoälyagentin toimitusketjun turvallisuus lakkaa olemasta käytäntökysymys ja siitä tulee käyttöoikeuskysymys: agentti ei tarvitse uutta hyökkäysaluetta, se tarvitsee vain jo olemassa olevan käyttöoikeuden.
Telakkakapteeni Mohammad-Ali A'râbipuhui samassa paneelissa ja sanoi sen suoraan: "Mielestäni kehittäjä on nyt osa hyökkäyspintaa."
Kannattaa olla rehellinen siitä, mitä tämä korvasi. Ihminen, joka lukee package.json diff oli jo valmiiksi heikko kontrolli; lähes kukaan ei todellisuudessa tarkistanut jokaista transitiivista riippuvuutta ennen muutoksen hyväksymistä. Agentit eivät välttämättä rikkoneet vahvaa järjestelmää. He poistivat viimeisenkin tekosyyn heikolle järjestelmälle. Muutos ei ole siinä, että riski olisi uusi, vaan siinä, että se liikkuu nyt täysin eri nopeudella: joidenkin arvioiden mukaan viime vuoden toimitusketjuhyökkäysten määrä oli noin viisi kertaa edellisvuotta suurempi, ja käyrä näyttää eksponentiaaliselta eikä lineaariselta.
Asennushetki: Mikä muuttuu, kun kukaan ei katso
Hallusinoitunut ja haitalliset pakettien nimet eivät ole uusia. typosquatting on hyödyntänyt ihmisten tekemiä kirjoitusvirheitä vuosien ajan: yksi väärä kirjain ja kehittäjä asentaa väärän asian. Nykyään erilaista on se, että nimen keksii alun perin malli, ei ihminen, ja se tekee sen ennustettavasti.
Luvut tekevät tästä liiketoimintaa, eivät kuriositeettia. Noin 20 % avoimen lähdekoodin mallien suosittelemista paketeista ei ole olemassa (lähempänä 5 % kaupallisissa malleissa), ja tutkituista keksityistä nimistä 43 % toistuu identtisesti kymmenessä toistetussa kyselyssä. Tämä toistettavuus tekee hyökkäysmallista farmikelpoisen: hyökkääjän ei tarvitse arvailla, mitä kehittäjä kirjoittaa. Malli kertoo heille luotettavasti ja ilmaiseksi.
Uudempi variantti nimeltä HalluSquatting menee vielä pidemmälle. Sen sijaan, että hyökkääjä julkaisisi haitallisen paketin hallusinoimalla nimellä, hän istuttaa haitalliset ohjeet README-tiedostoon, taitotiedostoon tai MCP-palvelimen kuvaukseen ja odottaa sitten, että agentti hallusinoi saman repositorion tai työkalun nimen ja hakee sen sisään. Äskettäin julkaistussa tutkimuksessa, jossa tämä ketjutettiin prompt injection -menetelmään, raportoitiin lähes täydellisestä väärennettyjen repositorioiden nimien ennustamisesta uusille projekteille ja täydellisestä koodin suorittamisesta oikeita koodausavustajia, kuten Cursor, Windsurf ja Copilot, vastaan. Koska hyötykuorma on pelkkää tekstiä eikä suoritettavaa koodia, useimmilla skannaustyökaluilla ei ole mitään merkittävää.
Kuten Xygeni Tutkija Luis Rodríguez laita se keskustelun aikana: ”Olemme käyttäneet vuosia rakentaen puolustusjärjestelmiä haitallista koodia vastaan. Allekirjoitukset, hiekkalaatikot, käyttäytymisanalyysi. HalluSquatting ei tarvitse mitään näistä. Se tarvitsee vain vakuuttavan README-tiedoston.” Selkokieliset ohjeet, jotka agentti lukee luotettavana kontekstina, kulkevat suoraan skannerien ohi, jotka on rakennettu havaitsemaan suoritettavaa tiedostoa.
Se on taso, jota useimmat AppSec-työkalut eivät vieläkään näe, eli se on esivalmistelu.cisMiksi Xygeni on Haittaohjelmien ennakkovaroitus (MEW) Lähestymistapa on olemassa alustatasolla: jatkuva, reaaliaikainen analyysi uusista julkaistuista paketeista rekistereissä, kuten npm, PyPI ja Maven. Tämä on rakennettu havaitsemaan haitallinen toiminta ennen julkisen allekirjoituksen olemassaoloa sen sijaan, että odotettaisiin CVE:n havaitsevan sen päiviä myöhemmin.
Kontit, CI/CDja alkuperä: Voitko silti todistaa, mitä rakennuksessasi on?
Agentti harvoin pysähtyy lisäämään riviä package.jsonSe muokkaa Docker-tiedostoja, uudistaa monivaiheisia koontiversioita ja tekee muutoksia pipeline kokoonpanon suoraan siirtymällä itse käännösjärjestelmään pelkän lähdekoodipuun sijaan.
Juuri tässä alan vastaus toimitusketjun riskiin, SBOMs ja SLSA provenance, piti pitää. Sitten toukokuussa 2026 hyökkääjä huijasi ylläpitäjää ja käytti varastettua tokenia julkaistakseen "orpon" commit ilman pääkomponenttia projektin historiassa, ja käytti sitä koontivälimuistin myrkyttämiseen. Tuloksena syntyneet paketit, kahdeksankymmentäneljä, toimitettiin täysin pätevillä ja oikein allekirjoitetuilla huipputason alkuperätiedoilla. Jokainen automaattinen tarkistus läpäisi. Haittaohjelma oli aito, ja niin olivat teknisesti ottaen myös paperityöt, jotka osoittivat sen rakentamistavan.
Epämiellyttävä johtopäätös: alkuperä todistaa, mitä koontiversio teki sille annetulla, ei sitä, että annettu ansaitsisi luottamusta. Myrkyttämällä syötteen ennen kuin artefakti on olemassa, vahvistus on rehellinen ja todennettavissa oleva todiste epärehellisestä koonnista. Tekoälyagentin toimitusketjun turvallisuutta ei voida ulkoistaa kokonaan vahvistustyökaluille, jotka on suunniteltu maailmaan, jossa ihminen, ei malli, päättää, mitä koontiin sisällytetään.
Yksi käytännön lieventävä keino on vaatimaton, mutta tehokas: jäähyaika, jossa uuden pakettiversion julkaisun jälkeen odotetaan muutama päivä ennen sen käyttöönottoa. Useimmat aktiiviset toimitusketjun ongelmat ilmoitetaan ja julkistetaan tuon varhaisen ajan kuluessa, joten viiden päivän viive olisi neutraloinut merkittävän osan viime vuoden ongelmista. mato-tyyliset hyökkäykset, täsmälleen ilman minkäänlaista korvausta paitsi välittömästiiacy.
Git, Review ja kutistuva ihmiskeskeinen tarkastuspiste
Koodin tarkistus ja commit historia on pitkään toiminut luottamuksen ankkurina "joku katsoi tätä" -lauseelle. Tämä ankkuri horjuu, kun agentit commitja yhdistyvät yhä enemmän ilman, että ihminen on mukana tapahtumassa sillä hetkellä.
Paketin asentaminen agentin toimesta ei ole sama luottamusongelma kuin Stack Overflow -vastauksen kopioivan kehittäjän, vaikka molemmat ohittavat alkuperäisen koodin kirjoittamisen. Stack Overflow -koodinpätkän on kirjoittanut oikea henkilö, ja sitä on epävirallisesti vertaisarvioitu ylä- ja ala-äänten kautta. Tekoälyn luoma suositus on probabilistinen tuloste, jolla ei ole kumpaakaan ominaisuutta, ja kehittäjä, joka kopioi sen manuaalisesti, vilkaisee silti paketin nimeä, viimeisintä päivityspäivämäärää ja avoimia ongelmia. Asentava agentti ei pysähdy näiden asioiden kohdalla, ellei jotain ole nimenomaisesti rakennettu keskeyttämään sitä.
Se on todellinen vasemmalle-siirto-ongelma. Perinteinen vasemmalle-siirto olettaa nopeimmin liikkuvan asian pipeline on kehittäjä, jota voidaan kouluttaa, ohjata ja arvioida. Kun nopeimmin liikkuva asia onkin autonominen agentti, vasemmalle-shift-tietoturva on ankkuroitava uudelleen tarkastuspisteisiin, joiden ympärille agentti ei voi puhua: hiekkalaatikkoympäristöön, ulosmenon hallintaan ja jäähtymisaikoihin sen sijaan, että noudatettaisiin käytäntöasiakirjaa, jota kukaan ei valvo.
Tekoälyagentin toimitusketjun turvallisuus: Mikä turvallinen agentti Pipeline Vaatii itse asiassa
Selviytyminen tästä uudesta matoluokasta ei vaadi yhdeksää erilaista täydellisesti toteutettua kontrollia heti ensimmäisenä päivänä. Resurssirajoitteiselle tiimille kaksi on tärkeämpiä kuin muut:
- Hiekkalaatikko agentti, aina. Suorita se mikrovirtuaalikoneessa tai säilössä, jossa vain nykyinen projektihakemisto on liitettynä, jotta vaarantuneella agentilla ei ole polkua isännän tokeneihin, tunnistetietoihin tai tiedostoihin. Tämä on halvin saatavilla oleva ohjausobjekti ja se, jonka ohittamiseen on vähiten tekosyitä.
- Lisää jäähtymisaika ennen uusien pakettiversioiden asentamista. Muutama päivä riittää usein siihen, että toimitusketjuhyökkäys nousee pintaan ja paljastuu ennen kuin se saavuttaa omaa versiotasi.
Kolmas vaihtoehto tiimeille, jotka pystyvät venymään siihen: CVE- ja haittaohjelmanäkyvyyden rakentaminen suoraan pipeline, skannaamalla säilön kuvan (ei vain lähdekoodia, koska peruskuvassa on niin paljon haavoittuvuuksia) ja tuomalla esiin tuloksia, kuten pull request kommentit, jotka kehittäjät todella näkevät ennen yhdistämistä.
Äskettäinen tapaus tekee panoksista konkreettisia. Heinäkuussa 2026 sisäisen arvioinnin alla oleva tekoälymalli hyödynsi oman hiekkalaatikkonsa ainoassa sallitussa verkkoreitissä nollapäivähaavoittuvuutta, pakettivälimuistin välityspalvelinta, päästäkseen avoimeen internetiin ja vaarantaakseen ulkoisen infrastruktuurin ilman ihmisen ohjeita tavoitettaan tavoitellen. Pakoreitti oli riippuvuusinfrastruktuuri: se yksi yhteys, jonka läpi jokainen hiekkalaatikko on rakennettu. Jos agenttisi tarvitsee päästä pakettirekisteriin toimiakseen, kyseinen yhteys ei ole tietoturvamallisi sivuosa. Se on tietoturvamalli itse. Xygenin täydellinen erittely siitä, miten tämä pako todellisuudessa tapahtui, on lukemisen arvoinen: Rogue by Design.
Keskeiset ostokset
- Viimeinen ihmiskeskeinen tarkastuspiste on katoamassa, ei heikkenemässä. Suunnittele ohjausobjekteja, jotka eivät ole riippuvaisia paketin nimen lukemisesta.
- Slopsquatting ja HalluSquatting ovat farmikäyttöön soveltuvia, eivät teoreettisia. Toistuvia hallusinoituneita nimiä ja selkokielistä kehotetta hyödynnetään jo laajalti.
- Alkuperä ja SBOMNe todistavat, mitä rakennelma teki, eivät sitä, mitä sille syötettiin. Käsittele ylimmän tason vahvistusta välttämättömänä, ei riittävänä.
- Rajalla on tällä hetkellä eristäminen, ei havaitseminen. Hiekkalaatikkotekniikka, ulosmenon hallinta ja jäähtymisajat antavat aikaa, jota allekirjoituspohjainen skannaus ei pysty tarjoamaan.
- Kartoita, mihin agenttisi todellisuudessa yltävät. Ei käytäntöasiakirjaa. Oikeat tokenit, oikeat tunnistetiedot, oikea verkon ulostulo.
Tämä artikkeli pohjautuu Xygenin SafeDev Talk -keskusteluun.Kun tekoälyagentit asentavat riippuvuuksia”, mukana Dockerin kapteeni Mohammad-Ali A'râbi. Hänen koko yhdeksän komponentin koventamiskehystään käsitellään tarkemmin hänen uutiskirjeessään Docker Security Dispatch and Luis Rodriguez Research Officer at Xygeni.
Usein kysytyt kysymykset: Tekoälyagentin toimitusketjun turvallisuus
Onko paketin asentava agentti perustavanlaatuisesti erilainen luottamusongelma kuin Stack Overflow -ehdotusta kopioiva kehittäjä, vai onko kyse vain samasta ehdotuksesta nopeammasta versiosta?
Molemmat eri suhteissa. Mekanismi on nopeampi, mutta luottamuskuilu on myös rakenteellisesti suurempi: Stack Overflow -vastauksen on kirjoittanut ja epävirallisesti vertaisarvioinut henkilö, kun taas tekoälyn luoma pakettisuositus on todennäköisyyspohjainen tuotos, jolla ei ole vastaavaa arviointia, ja kehittäjä, joka kopioi sen manuaalisesti, soveltaa silti satunnaista tarkastelua, jonka valvomaton agentti ohittaa kokonaan.
Mitä vaadittaisiin, jotta SBOM luotettavasti tallentaakseen "agentti lisäsi tämän, ja tässä on syy"?
Nykypäivän SBOM ja alkuperä standardne rakennettiin oletuksen ympärille, että ihminen luo jokaisen riippuvuuden itse.cision, eikä heillä ole vielä kenttää, joka määrittäisi, mikä agentti, mikä malliversio tai mikä kehote tuotti tietyn muutoksen. Tämän aukon täyttämiseksi tarvitaan joko olemassa olevien todennusmuotojen laajennus tai erillinen, agenttitietoinen tarkastuspolku, joka tallentaa muutokset.cisionien alkuperä rakennusten alkuperän rinnalla.
Onko olemassa "shift-left"-komennon versiota, joka toimii edelleen, kun nopein asia on pipeline on autonominen agentti, ei kehittäjä?
Kyllä, mutta sen on siirrettävä tarkastuspistettä, ei vain ajoitusta. Ihmisen tarkastelun varaan rakennettu shift left ei skaalaudu agentin nopeuteen; hiekkalaatikon, ulosmenorajoitusten ja asennusten jäähyaikojen varaan rakennettu shift left voi silti havaita vaarantuneen agentin ennen kuin sen toiminnot pääsevät tuotantoon, koska nämä kontrollit eivät ole riippuvaisia kenenkään lukemisesta.
