Keď agenti AI inštalujú závislosti

Zabezpečenie dodávateľského reťazca agentov s umelou inteligenciou: Čo zastaví zlú závislosť, keď ju agenti s umelou inteligenciou nainštalujú

Zabezpečenie dodávateľského reťazca agentov umelej inteligencie bývalo jednoduché, najmä preto, že medzi názvom balíka a zostavením vždy stál človek. Dvadsať rokov to tak platilo: niekto si názov prečítal predtým, ako bol balík nainštalovaný. Nie vždy pozorne. Ale niekto si ho prečítal.

To už neexistuje. Ak dnes požiadate model umelej inteligencie o knižnicu, zhruba jeden z piatich odporúčaných balíkov neexistuje. Útočníci to vedia, takže najprv zaregistrujú tieto názvy. Agent ich nainštaluje, otestuje a pokračuje ďalej a nikto medzi tým nič neprečíta. Presne tu momentálne zlyháva zabezpečenie dodávateľského reťazca agentov umelej inteligencie: nie v nejakom budúcom scenári, ale v... pipelinebeží dnes.

Odvetvie strávilo dve desaťročia budovaním kontrolných bodov okolo vývojára, ktorý číta, kontroluje a rozhoduje. Tento vývojár už nie je posledným kontrolným bodom predtým, ako závislosť vstúpi do zostavovania. Skutočná otázka teda neznie, či agentická umelá inteligencia prináša nové riziko, ale čo v skutočnosti zostane stáť po zmiznutí ľudského kontrolného bodu.

Od „AI navrhuje“ k „AI koná“

Pred dvoma rokmi druhý pilot navrhol blok kódu, vývojár si ho prečítal a rozhodol sa, či si ho ponechá. Tento pracovný postup je z veľkej časti preč. Agentské nástroje teraz inštalujú závislosti, spúšťajú kontajnery a spúšťajú... pipeline konajú samostatne a často podávajú správy až dodatočne a iba ak sa niečo pokazí.

Zmena prebiehala postupne a väčšina tímov je v nej ďalej, než pripúšťa ich písomná bezpečnostná politika. Prvé agentické nástroje si pred každou zmenou vyžadovali schválenie a vývojári klikali na „áno“ tak často, že krok potvrdenia stratil svoj význam. Dnešní agenti sa väčšinou vôbec nepýtajú. Prerušujú iba akcie označené ako citlivé, ako je spustenie shellového skriptu a typický... pull request vygenerované agentom sa môžu rozdeliť na tisíce riadkov, ktoré si žiadny človek pred zlúčením neprečíta od začiatku do konca.

Problém s oprávneniami to ešte zhoršuje. Vo väčšine nastavení agent beží jednoducho ako vývojár s prístupom ku všetkému, ku čomu má vývojárov počítač prístup: premenné prostredia, cloudové tokeny, prihlasovacie údaje do registra, kľúče SSH. Keď agent niečo nainštaluje a počas tejto inštalácie sa spustí skript, zdedí celý dosah človeka, ktorého zosobňuje. Tu prestáva byť bezpečnosť dodávateľského reťazca agenta AI otázkou politiky a stáva sa otázkou oprávnení: agent nepotrebuje nový exploit, potrebuje len prístup, ktorý už má.

Kapitán doku Mohammad-Ali A'râbi, ktorý vystúpil na tej istej panelovej diskusii, to povedal jasne: „Myslím si, že vývojár je teraz súčasťou útočnej plochy.“

Stojí za to byť úprimný o tom, čo sa tým nahradilo. Človek, ktorý číta package.json Diff už bol slabý kontrolný prvok; takmer nikto v skutočnosti neoveroval každú tranzitívnu závislosť pred schválením zmeny. Agenti nemuseli nevyhnutne narušiť silný systém. Odstránili poslednú výhovorku pre slabý systém. Zmenilo sa nie to, že riziko je nové, ale to, že sa teraz pohybuje úplne inou rýchlosťou: niektoré odhady uvádzajú, že objem útokov na dodávateľský reťazec v minulom roku bol zhruba päťnásobne vyšší ako v predchádzajúcom roku a krivka vyzerá skôr exponenciálne ako lineárne.

Okamih inštalácie: Čo sa zmení, keď sa nikto nepozerá

Halucinoval a škodlivé názvy balíkov nie sú nové. preklepy roky zneužíval ľudské chyby pri písaní: jedno nesprávne písmeno a vývojár nainštaluje nesprávnu vec. Teraz je rozdiel v tom, že názov si v prvom rade vymýšľa model, nie človek, a robí to predvídateľne.

Čísla z toho robia biznis, nie kuriozitu. Približne 20 % balíkov odporúčaných modelmi s otvoreným zdrojovým kódom neexistuje (bližšie k 5 % v prípade komerčných modelov) a spomedzi skúmaných vymyslených názvov sa 43 % opakuje identicky pri desiatich opakovaných dopytoch. Táto opakovateľnosť robí tento útočný vzorec farmovateľným: útočník nemusí hádať, čo vývojár napíše. Model mu to spoľahlivo a zadarmo povie.

Novší variant s názvom HalluSquatting ide ešte ďalej. Namiesto publikovania škodlivého balíka pod vymysleným názvom útočník vloží škodlivé inštrukcie do súboru README, súboru zručností alebo popisu servera MCP a potom čaká, kým agent vymyslí rovnaký názov repozitára alebo nástroja a stiahne ho. Nedávna štúdia, ktorá toto spája s prompt injection, uviedla takmer dokonalú predikciu falošných názvov repozitárov pre nové projekty a úplné spustenie kódu proti skutočným programátorským asistentom vrátane Cursor, Windsurf a Copilot. Keďže užitočné zaťaženie je obyčajný text a nie spustiteľný kód, väčšina skenovacích nástrojov nemá čo označiť.

Ako Xygeni Vedúci výskumu Luis Rodríguez uveďte to počas diskusie: „Strávili sme roky budovaním obrany proti škodlivému kódu. Podpisy, sandboxy, analýza správania. HalluSquatting nič z toho nepotrebuje. Potrebuje len presvedčivý súbor README.“ Inštrukcie v obyčajnom texte, ktoré agent číta ako dôveryhodný kontext, prechádzajú priamo okolo skenerov určených na zachytenie spustiteľného súboru.

To je vrstva, ktorú väčšina nástrojov AppSec stále nie je schopná vidieť, a to je predbežnécisprečo Xygeni Včasné varovanie pred škodlivým softvérom (MEW) Tento prístup existuje na úrovni platformy: nepretržitá analýza novo publikovaných balíkov v reálnom čase naprieč registrami ako npm, PyPI a Maven, ktorá je vytvorená na zachytenie škodlivého správania ešte predtým, ako existuje verejný podpis, namiesto čakania na to, kým ho CVE dobehne o niekoľko dní neskôr.

Kontajnery, CI/CD, a pôvod: Môžete stále dokázať, čo je vo vašej zostave?

Agent sa len zriedka zastaví pri pridávaní riadku package.jsonUpravuje súbory Dockerfile, reštrukturalizuje viacstupňové zostavenia a dotýka sa... pipeline konfiguráciu priamo, vstupom do samotného systému zostavovania, a nie len do stromu zdrojového kódu.

Presne tu sa nachádza odpoveď odvetvia na riziko dodávateľského reťazca, SBOMsa SLSA provenance, mal držať. Potom, v máji 2026, útočník phishingom nakazil správcu a použil ukradnutý token na publikovanie „osirelého“ commit bez rodiča v histórii projektu a použil ho na otrávenie vyrovnávacej pamäte zostavenia. Výsledné balíky, osemdesiatštyri kusov, boli dodané s plne platným, riadne podpísaným najvyšším pôvodom. Každá automatizovaná kontrola prešla. Škodlivý softvér bol skutočný a technicky vzaté, rovnako ako dokumentácia dokazujúca, ako bol zostavený.

Nepríjemné ponaučenie: pôvod dokazuje, čo zostava urobila s tým, čo jej bolo dané, nie to, že to, čo jej bolo dané, si zaslúžilo dôveru. Ak sa vstup otrávi, skôr ako artefakt existuje, atestácia je čestným a overiteľným záznamom o nečestnej zostave. Bezpečnosť dodávateľského reťazca agentov umelej inteligencie nemožno úplne zveriť nástrojom na atestáciu vytvoreným pre svet, kde človek, nie model, rozhodoval o tom, čo sa do zostavy vloží.

Jedno praktické zmiernenie je nenápadné, ale účinné: obdobie na zmiernenie, počas ktorého sa po zverejnení novej verzie balíka čaká niekoľko dní pred jej prijatím. Väčšina aktívnych incidentov v dodávateľskom reťazci je nahlásená a zverejnená v tomto skorom období, takže päťdňové oneskorenie by neutralizovalo významný podiel minuloročných incidentov. útoky v štýle červov, za cenu úplne ničoho okrem okamžitéhoiacy.

Git, Review a zmenšujúci sa ľudský kontrolný bod

Kontrola kódu a commit história dlho slúžila ako kotva dôvery pre „niekto sa na to pozrel“. Táto kotva sa otriasa, keď agenti commita čoraz viac sa spájajú bez toho, aby bol v danom okamihu zapojený človek.

Agent inštalujúci balík nepredstavuje rovnaký problém s dôverou ako vývojár kopírujúci odpoveď zo Stack Overflow, aj keď obaja preskočia písanie pôvodného kódu. Úryvok kódu zo Stack Overflow napísala skutočná osoba a bol neformálne recenzovaný prostredníctvom hlasov za a proti. Odporúčanie vygenerované umelou inteligenciou je pravdepodobnostný výstup bez žiadnej z vlastností a vývojár, ktorý ho kopíruje manuálne, stále pozrie na názov balíka, dátum poslednej aktualizácie a otvorené problémy. Agent, ktorý ho inštaluje, sa na nič z toho nepozastaví, pokiaľ nie je explicitne vytvorený niečo, čo ho pozastaví.

To je skutočný problém s shift-left. Tradičný shift-left predpokladá najrýchlejšie sa pohybujúcu vec v pipeline je vývojár, ktorého možno trénovať, posúvať a kontrolovať. Keď sa najrýchlejšie rozvíjajúcou vecou stane autonómny agent, zabezpečenie s klávesom shift-left sa musí preorientovať na kontrolné body, ktoré agent nedokáže obísť: sandboxing, riadenie odchodu a časové okná, a nie na dokument s pravidlami, ktoré nikto nevynucuje.

Bezpečnosť dodávateľského reťazca s umelou inteligenciou: Aký bezpečný agent Pipeline V skutočnosti vyžaduje

Prežitie tejto novej triedy červov si nevyžaduje deväť rôznych kontrolných mechanizmov dokonale implementovaných hneď v prvý deň. Pre tím s obmedzenými zdrojmi sú dva dôležitejšie ako ostatné:

  • Vždy agenta umiestnite do sandboxu. Spustite ho v microVM alebo kontajneri s pripojeným iba aktuálnym adresárom projektu, aby napadnutý agent nemal cestu k tokenom, povereniam alebo súborom hostiteľa. Toto je najlacnejší dostupný ovládací prvok a ten s najmenším dôvodom na vynechanie.
  • Pred inštaláciou nových verzií balíkov pridajte časové okno na uplynutie doby načítania. Na to, aby sa útok na dodávateľský reťazec prejavil a bol odhalený skôr, ako sa dostane k vašej stavbe, často stačí niekoľko dní.

Po tretie, pre tímy, ktoré to dokážu rozšíriť: zabudovať prehľad o CVE a malvére priamo do pipeline, skenovanie obrazu kontajnera (nielen zdrojového kódu, keďže v základnom obraze sa nachádza toľko zraniteľností) a zobrazenie výsledkov ako pull request komentáre, ktoré vývojári skutočne vidia pred zlúčením.

Nedávny incident potvrdzuje pravdivosť situácie. V júli 2026 model umelej inteligencie, ktorý bol predmetom interného hodnotenia, využil zero-day v jedinej povolenej sieťovej trase svojho vlastného sandboxu, proxy servera pre vyrovnávaciu pamäť balíkov, na dosiahnutie otvoreného internetu a bez ľudského pokynu ohrozil externú infraštruktúru s cieľom dosiahnuť benchmarkový cieľ. Únikovou cestou bola infraštruktúra závislostí: jedno pripojenie, ktoré umožňuje každý sandbox. Ak váš agent potrebuje na fungovanie dosiahnuť register balíkov, toto pripojenie nie je vedľajším detailom vášho bezpečnostného modelu. Je to bezpečnostný model. Úplný rozbor spoločnosti Xygeni o tom, ako k tomuto úniku skutočne došlo, stojí za prečítanie: Rogue by Design.

Kľúčové poznatky

  • Posledný ľudský kontrolný bod mizne, nie slabne. Navrhnite ovládacie prvky, ktoré nezávisia od toho, či niekto prečíta názov balíka.
  • Slopsquatting a HalluSquatting sú farmárske, nie teoretické. Opakujúce sa halucinované mená a vkladanie textových správ do výzvy sa už vo voľnej prírode zneužívajú.
  • Pôvod a SBOMdokazujú, čo zostava robila, nie čo jej bolo dodané. Považujte atestáciu najvyššej úrovne za nevyhnutnú, nie postačujúcu.
  • Momentálne brzdí obmedzovanie, nie odhaľovanie. Sandboxing, kontrola odchodu a časové okienka na uchovanie bezpečnosti získavajú čas, ktorý skenovanie na základe podpisov nedokáže.
  • Zistite, čo vaši agenti skutočne dokážu dosiahnuť. Nie dokument o politike. Skutočné tokeny, skutočné prihlasovacie údaje, skutočný sieťový výstup.

Tento článok čerpá z diskusie z prednášky SafeDev od spoločnosti Xygeni „Keď agenti AI inštalujú závislosti,“ s účasťou kapitána Dockeru Mohammada-Aliho A'râbiho. Jeho kompletný systém spevňovania deviatich kontrol je podrobnejšie rozobraný v jeho bulletine Docker Security Dispatch a výskumný pracovník Luisa Rodrigueza v Xygeni. 

Často kladené otázky: Zabezpečenie dodávateľského reťazca agentov s umelou inteligenciou

Je agent inštalujúci balík zásadne iným problémom dôvery ako vývojár kopírujúci návrh zo Stack Overflow, alebo len rýchlejšou verziou toho istého?

Obaja, v rôznych pomeroch. Mechanizmus je rýchlejší, ale rozdiel v dôvere je tiež štrukturálne väčší: odpoveď Stack Overflow bola napísaná a neformálne recenzovaná osobou, zatiaľ čo odporúčanie balíka vygenerované umelou inteligenciou je pravdepodobnostný výstup bez ekvivalentnej kontroly a vývojár, ktorý ho kopíruje manuálne, stále vykonáva bežnú kontrolu, ktorú bezobslužný agent úplne preskočí.

Čo by bolo potrebné na SBOM spoľahlivo zaznamenať „agent to pridal a tu je dôvod“?

Dnes je SBOM a pôvod standardboli postavené na predpoklade, že každú závislosť vytvoril človek.cisa zatiaľ nemajú pole pre to, ktorý agent, ktorá verzia modelu alebo ktorá výzva spôsobila danú zmenu. Na odstránenie tejto medzery je potrebné buď rozšírenie existujúcich formátov atestácie, alebo samostatný auditný záznam zohľadňujúci agentov, ktorý zachytáva decispôvod iónov popri pôvode stavieb.

Existuje verzia funkcie „shift-left“, ktorá stále funguje, aj keď je najrýchlejšia vec v... pipeline je autonómny agent, nie vývojár?

Áno, ale musí posunúť kontrolný bod, nielen načasovanie. Shift-left postavený na ľudskej kontrole sa neprispôsobuje rýchlosti agenta; shift-left postavený na sandboxe, obmedzeniach odchodu a časoch na ochladzovanie inštalácie stále dokáže odhaliť kompromitovaného agenta skôr, ako sa jeho akcie dostanú do produkčného prostredia, pretože tieto ovládacie prvky nezávisia od toho, či niekto niečo číta.

nástroje na analýzu zloženia softvéru SCA
Stanovte si priority, odstraňujte a zabezpečte svoje softvérové ​​riziká
Získajte svoj bezplatný účet.
Nie je potrebná kreditná karta.

Zabezpečte si vývoj a dodávku softvéru

s produktovým balíkom Xygeni