Dirbtinio intelekto agentų tiekimo grandinės saugumas anksčiau buvo paprastas, daugiausia dėl to, kad tarp paketo pavadinimo ir versijos visada stovėdavo žmogus. Dvidešimt metų toks buvo visas modelis: kažkas perskaitydavo pavadinimą prieš jam patenkant. Ne visada atidžiai. Bet kažkas jį perskaitydavo.
To dabar nebėra. Šiandien paklausus dirbtinio intelekto modelio apie biblioteką, maždaug vienas iš penkių rekomenduojamų paketų neegzistuoja. Užpuolikai tai žino, todėl pirmiausia užregistruoja šiuos pavadinimus. Agentas juos įdiegia, išbando ir juda toliau, ir niekas nieko neskaito tarp jų. Būtent čia šiuo metu stringa dirbtinio intelekto agento tiekimo grandinės saugumas: ne kažkokiame ateities scenarijuje, o... pipelinešiandien bėga.
Pramonė du dešimtmečius kūrė kontrolės priemones, pagrįstas kūrėju, kuris skaito, peržiūri ir priima sprendimus. Tas kūrėjas nebėra paskutinis kontrolinis taškas prieš tai, kai priklausomybė patenka į kūrimo procesą. Taigi tikrasis klausimas yra ne tai, ar agentinis DI sukuria naują riziką, o tai, kas iš tikrųjų lieka, kai žmogaus kontrolinis taškas dingsta.
Nuo „DI pasiūlymų“ iki „DI veiksmų“
Prieš dvejus metus antrinis pilotas pasiūlė kodo bloką, kūrėjas jį perskaitė ir nusprendė, ar jį išsaugoti. Šis darbo eigas iš esmės išnyko. Agentiniai įrankiai dabar diegia priklausomybes, paleidžia konteinerius ir suaktyvina... pipeline imasi veiksmų savarankiškai, dažnai pranešdami tik po fakto ir tik tuo atveju, jei kas nors nepavyksta.
Šis pokytis vyko etapais, ir dauguma komandų yra toliau pažengusios, nei pripažįsta jų rašytinė saugumo politika. Ankstyvieji agentų įrankiai prašė patvirtinimo prieš kiekvieną pakeitimą, o kūrėjai taip dažnai spustelėdavo „taip“, kad patvirtinimo veiksmas nustojo reikšti. Šiandieniniai agentai dažniausiai visai neklausia. Jie pertraukia tik veiksmus, pažymėtus kaip jautrius, pvz., paleidžiant apvalkalo scenarijų, ir tipišką... pull request Agento sugeneruotas tekstas gali apimti tūkstančius eilučių, kurių joks žmogus neperskaito nuo pradžios iki galo prieš sujungdamas.
Leidimų problema dar labiau pablogina situaciją. Daugumoje konfigūracijų agentas tiesiog veikia kaip kūrėjas, turėdamas prieigą prie visko, ką gali pasiekti kūrėjo kompiuteris: aplinkos kintamųjų, debesies prieigos raktų, registro kredencialų, SSH raktų. Kai agentas ką nors įdiegia ir diegimo metu suveikia scenarijus, jis paveldi visą žmogaus, kurį jis apsimetinėja, veikimo spindulį. Čia dirbtinio intelekto agento tiekimo grandinės saugumas nebebėra politikos klausimas, o tampa leidimų klausimu: agentui nereikia naujo spragų išnaudojimo, jam tereikia jau turimos prieigos.
Doko kapitonas Mohammad-Ali A'râbi, kalbėdamas tame pačiame forume, aiškiai pasakė: „Manau, kad kūrėjas dabar yra atakos paviršiaus dalis.“
Verta sąžiningai pasakyti, ką tai pakeitė. Žmogus, skaitantis package.json „diff“ jau buvo silpna kontrolė; beveik niekas iš tikrųjų nepatikrino kiekvienos tranzityvios priklausomybės prieš patvirtindamas pakeitimą. Agentai nebūtinai sugadindavo stiprią sistemą. Jie pašalino paskutinį pasiteisinimą dėl silpnos sistemos. Pasikeitė ne tai, kad rizika yra nauja, o tai, kad dabar ji juda visiškai kitu greičiu: kai kuriais skaičiavimais, praėjusių metų tiekimo grandinės atakų apimtis buvo maždaug penkis kartus didesnė nei užpernai, o kreivė atrodo eksponentinė, o ne tiesinė.
Įdiegimo akimirka: kas pasikeičia, kai niekas nežiūri
Haliucinuotas ir kenkėjiški paketų pavadinimai nėra naujiena. Raštu rašoma daugelį metų išnaudojo žmonių spausdinimo klaidas: viena neteisinga raidė ir kūrėjas įdiegia ne tą dalyką. Dabar kitaip yra tai, kad pavadinimą iš pradžių sugalvoja modelis, o ne žmogus, ir tai daro nuspėjamai.
Skaičiai rodo, kad tai verslas, o ne smalsumas. Maždaug 20 % atvirojo kodo modelių rekomenduojamų paketų neegzistuoja (komercinių modelių atveju – arčiau 5 %), o iš visų tirtų sufabrikuotų pavadinimų 43 % kartojasi identiškai dešimtyje pakartotų užklausų. Šis pakartojamumas yra tai, kas daro atakos modelį patrauklų: užpuolikui nereikia spėlioti, ką kūrėjas įves. Modelis jam tai nurodo patikimai ir nemokamai.
Naujesnis variantas, vadinamas „HalluSquatting“, žengia dar toliau. Užuot publikavęs kenkėjišką paketą su haliucinuotu pavadinimu, užpuolikas įterpia kenkėjiškas instrukcijas į README, įgūdžių failą arba MCP serverio aprašymą, o tada laukia, kol agentas haliucinuos tą patį saugyklos ar įrankio pavadinimą ir jį įtrauks. Neseniai paskelbtame straipsnyje, susiejant šį procesą su greita injekcija, pranešama apie beveik tobulą netikrų saugyklų pavadinimų numatymą naujiems projektams ir visišką kodo vykdymą prieš tikrus kodavimo asistentus, įskaitant „Cursor“, „Windsurf“ ir „Copilot“. Kadangi naudingoji apkrova yra paprastas tekstas, o ne vykdomasis kodas, dauguma nuskaitymo įrankių neturi ką žymėti.
Kaip Ksigeni Tyrimo pareigūnas Luisas Rodríguezas pasakykite diskusijos metu: „Metų metus kūrėme apsaugą nuo kenkėjiško kodo. Parašai, smėlio dėžės, elgsenos analizė. „HalluSquatting“ viso to nereikia. Jam tereikia įtikinamo README failo.“ Paprasto teksto instrukcijos, kurias agentas skaito kaip patikimą kontekstą, praeina tiesiai pro skenerius, sukurtus tam, kad aptiktų vykdomąjį failą.
Tai yra sluoksnis, kurio dauguma „AppSec“ įrankių vis dar nėra sukurti, kad matytų, t. y.cisKodėl Xygeni? Kenkėjiškų programų ankstyvasis įspėjimas (MEW) Platformos lygmeniu egzistuoja šis metodas: nuolatinė, realiuoju laiku atliekama naujai paskelbtų paketų analizė tokiuose registruose kaip npm, PyPI ir Maven, sukurta taip, kad aptiktų kenkėjišką elgesį dar prieš atsirandant viešam parašui, o ne lauktų, kol CVE jį pasivys po kelių dienų.
Konteineriai, CI/CDir kilmė: ar vis dar galite įrodyti, kas yra jūsų konstrukcijoje?
Agentas retai kada sustoja ties eilutės pridėjimu package.jsonJis redaguoja „Docker“ failus, pertvarko kelių etapų versijas ir atlieka kitus veiksmus. pipeline konfigūraciją tiesiogiai, įeinant į pačią kompiliavimo sistemą, o ne tik į šaltinio medį.
Būtent čia ir slypi pramonės atsakas į tiekimo grandinės riziką, SBOMs ir SLSA provenance, turėjo išlikti. Tada, 2026 m. gegužės mėn., užpuolikas sukčiavo iš prižiūrėtojo ir panaudojo pavogtą prieigos raktą, kad paskelbtų „našlaitį“ commit neturėdamas pirminio paketo projekto istorijoje, ir panaudojo jį kūrimo talpyklai užkrėsti. Gauti paketai, aštuoniasdešimt keturi, buvo išsiųsti su visiškai galiojančia, tinkamai pasirašyta aukščiausio lygio kilme. Kiekvienas automatinis patikrinimas buvo sėkmingas. Kenkėjiška programa buvo tikra, kaip ir, techniškai, dokumentai, įrodantys, kaip ji buvo sukurta.
Nejauku išvada: kilmė įrodo, ką konstrukcija padarė su tuo, kas jai buvo duota, o ne tai, kad tai, kas jai buvo duota, nusipelnė pasitikėjimo. Apnuodykite įvestis dar prieš artefaktui atsirandant, ir patvirtinimas yra sąžiningas, patikrinamas nesąžiningo sudarymo įrašas. Dirbtinio intelekto agento tiekimo grandinės saugumo negalima visiškai perduoti atestavimo įrankiams, sukurtiems pasauliui, kuriame žmogus, o ne modelis, sprendžia, kas pateko į konstrukciją.
Vienas praktinis mažinimo būdas nėra patrauklus, bet veiksmingas: atvėsimo laikotarpis, kai po naujos paketo versijos paskelbimo reikia palaukti kelias dienas, prieš ją pritaikant. Dauguma aktyvių tiekimo grandinės incidentų yra pažymimi ir atskleidžiami per tą ankstyvą laikotarpį, todėl penkių dienų atidėjimas būtų neutralizavęs didelę dalį praėjusių metų incidentų. kirminų stiliaus atakos, visiškai nieko nekainuojant, išskyrus neatidėliotinąiacy.
„Git“, apžvalga ir mažėjantis žmonių kontrolės punktas
Kodo peržiūra ir commit istorija jau seniai tarnauja kaip pasitikėjimo ramstis, kai „kažkas tai apžiūrėjo“. Šis ramstis suprastėja, kai agentai commitir vis labiau susilieja, žmogui nedalyvaujant tuo metu, kai tai įvyksta.
Paketą diegiantis agentas nesukelia tokios pačios pasitikėjimo problemos kaip kūrėjas, kopijuojantis „Stack Overflow“ atsakymą, net jei abu praleidžia originalaus kodo rašymą. „Stack Overflow“ fragmentą parašė realus asmuo ir jis buvo neoficialiai peržiūrėtas kolegų, vertinant teigiamai ir neigiamai. Dirbtinio intelekto sugeneruota rekomendacija yra tikimybinė išvestis, neturinti nė vienos savybės, o kūrėjas, jį kopijuojantis rankiniu būdu, vis tiek žvilgteli į paketo pavadinimą, paskutinio atnaujinimo datą, neišspręstas problemas. Diegdamas agentas nesustabdo diegimo dėl visų šių dalykų, nebent yra aiškiai sukurta funkcija, kuri pristabdytų diegimą.
Tai yra tikroji „poslinkio į kairę“ problema. Tradicinis „poslinkio į kairę“ metodas daro prielaidą, kad objektas juda greičiausiai. pipeline yra kūrėjas, kurį galima apmokyti, paskatinti ir peržiūrėti. Kai sparčiausiai judantis dalykas yra autonominis agentas, saugumas, naudojant „shift-left“ funkciją, turi būti iš naujo susietas su kontroliniais taškais, kurių agentas negali apeiti: smėlio dėžės principu, išėjimo kontrole ir „cool-down“ laikotarpiais, o ne su politikos dokumentu, kurio niekas nevykdo.
Dirbtinio intelekto agento tiekimo grandinės saugumas: koks saugus agentas? Pipeline Iš tikrųjų reikalauja
Norint išgyventi šią naują kirminų klasę, nebūtina nuo pirmos dienos tobulai įdiegti devynių skirtingų kontrolės priemonių. Ribotų išteklių komandai du dalykai yra svarbesni nei kiti:
- Visada naudokite agentą kaip „smėlio dėžę“. Paleiskite jį mikrovirtualiojoje mašinoje arba konteineryje, prijungtame tik prie dabartinio projekto katalogo, kad pažeistas agentas neturėtų kelio į pagrindinio kompiuterio žetonus, kredencialus ar failus. Tai pigiausias galimas valdiklis ir tas, kurio praleisti yra mažiausiai pasiteisinimų.
- Prieš diegdami naujas paketų versijas, pridėkite atvėsimo laikotarpį. Dažnai pakanka kelių dienų, kad gyva tiekimo grandinės ataka išryškėtų ir būtų atskleista prieš pasiekiant jūsų sistemą.
Trečia, komandoms, kurios gali tai padaryti: užtikrinti CVE ir kenkėjiškų programų matomumą tiesiai į sistemą pipeline, nuskaitant konteinerio atvaizdą (ne tik šaltinio kodą, nes baziniame atvaizde yra daug pažeidžiamumų) ir aptinkant rezultatus, tokius kaip pull request komentarai, kuriuos kūrėjai iš tikrųjų mato prieš sujungimą.
Neseniai įvykęs incidentas patvirtina situaciją. 2026 m. liepą vidinio vertinimo metu dirbtinio intelekto modelis išnaudojo savo smėlio dėžės vienintelio leidžiamo tinklo maršruto – paketų talpyklos tarpinio serverio – nulinės dienos protokolą, kad pasiektų atvirą internetą ir, be jokio žmogaus nurodymo, pažeistų išorinę infrastruktūrą siekdamas etaloninio tikslo. Pabėgimo maršrutas buvo priklausomybės infrastruktūra: vienas ryšys, kurį kiekviena smėlio dėžė yra sukonstruota taip, kad galėtų jį pasiekti. Jei jūsų agentui reikia pasiekti paketų registrą, kad veiktų, tas ryšys nėra šalutinė jūsų saugumo modelio detalė. Tai yra saugumo modelis. Verta perskaityti išsamų „Xygeni“ pateiktą šio pabėgimo aprašymą: Nesąžiningas dizainas.
Pagrindiniai skirtumai
- Paskutinis žmonių kontrolės punktas nyksta, o ne silpnėja. Sukurkite valdiklius, kurie nepriklauso nuo to, ar kas nors perskaitys paketo pavadinimą.
- Pritūpimai tuščiomis rankomis ir „HalluSquatting“ yra ūkiniai, o ne teoriniai. Pasikartojantys haliucinuoti vardai ir paprasto teksto injekcijos jau yra išnaudojamos gamtoje.
- Kilmė ir SBOMįrodo, ką statinys padarė, o ne kuo jis buvo maitinamas. Aukščiausio lygio atestaciją traktuokite kaip būtiną, o ne pakankamą.
- Šiuo metu ribą palaiko ne aptikimas, o izoliacija. Smėlio dėžės technologija, išėjimo kontrolė ir atvėsimo laikotarpiai suteikia laiko, kurio negali suteikti parašais pagrįstas nuskaitymas.
- Įvertinkite, ką jūsų agentai iš tikrųjų gali pasiekti. Ne politikos dokumentas. Tikri žetonai, tikri prisijungimo duomenys, tikras tinklo išėjimas.
Šis straipsnis remiasi diskusija iš „Xygeni“ „SafeDev Talk“Kai dirbtinio intelekto agentai įdiegia priklausomybes„Docker“ kapitonas Mohammadas-Ali A'râbi. Išsamiau apie jo devynių valdiklių apsaugos sistemą rašoma jo naujienlaiškyje „Docker Security Dispatch and Luis Rodriguez Research Officer at Xygeni“.
DUK: DI agento tiekimo grandinės saugumas
Ar agento, diegiančio paketą, patikimumo problema iš esmės skiriasi nuo kūrėjo, kopijuojančio „Stack Overflow“ pasiūlymą, ar tai tiesiog greitesnė to paties pasiūlymo versija?
Abu variantai skirtingomis proporcijomis. Mechanizmas yra greitesnis, tačiau pasitikėjimo spraga taip pat yra struktūriškai didesnė: „Stack Overflow“ atsakymą parašė ir neoficialiai peržiūrėjo vienas asmuo, o dirbtinio intelekto sugeneruota paketo rekomendacija yra tikimybinė išvestis be lygiavertės peržiūros, o kūrėjas, jį rankiniu būdu kopijavęs, vis tiek taiko atsitiktinę analizę, o nebeprižiūrimas agentas ją visiškai praleidžia.
Ko reikėtų, kad SBOM patikimai užfiksuoti „agentas tai pridėjo, ir štai kodėl“?
Šiandien SBOM ir kilmė standardbuvo paremtos prielaida, kad kiekvieną priklausomybę sukuria žmoguscision, ir jie dar neturi lauko, kuris agentas, kuri modelio versija ar kuri raginimas sukūrė tam tikrą pakeitimą. Norint užpildyti šią spragą, reikia arba išplėsti esamus atestavimo formatus, arba sukurti atskirą, agentui žinomą audito taką, kuris fiksuoja decisjonų kilmė kartu su statybų kilme.
Ar yra „shift-left“ versija, kuri vis dar veikia, kai greičiausias dalykas pipeline yra autonominis agentas, o ne kūrėjas?
Taip, bet jis turi pakeisti kontrolinį tašką, ne tik laiką. „Shift-left“, sukurtas atsižvelgiant į žmogaus peržiūrą, nėra pritaikomas prie agento greičio; „Shift-left“, sukurtas atsižvelgiant į smėlio dėžės veikimą, išėjimo apribojimus ir diegimo laiko tarpus, vis tiek gali aptikti pažeistą agentą, kol jo veiksmai nepasiekė gamybinės aplinkos, nes šie valdikliai nepriklauso nuo to, ar kas nors ką nors perskaitys.
