Zabezpečení dodavatelského řetězce pro agenty s umělou inteligencí bývalo jednoduché, hlavně proto, že mezi názvem balíčku a sestavením vždy stál člověk. Dvacet let to byl celý model: někdo si název přečetl, než byl balíček nainstalován. Ne vždy pečlivě. Ale někdo si ho přečetl.
To už je pryč. Pokud dnes požádáte model umělé inteligence o knihovnu, zhruba jeden z pěti doporučených balíčků neexistuje. Útočníci to vědí, takže nejprve zaregistrují tyto názvy. Agent je nainstaluje, otestuje a pokračuje dál, nikdo mezi tím nic nečte. Právě zde právě teď selhává zabezpečení dodavatelského řetězce agentů umělé inteligence: ne v nějakém budoucím scénáři, ale v... pipelineběží dnes.
Toto odvětví strávilo dvě desetiletí budováním kontrolních mechanismů kolem vývojáře, který čte, kontroluje a rozhoduje. Tento vývojář už není posledním kontrolním bodem před vstupem závislosti do sestavení. Skutečná otázka tedy nezní, zda agentní umělá inteligence přináší nová rizika, ale co skutečně zůstane stát po zmizení lidského kontrolního bodu.
Od „AI navrhuje“ k „AI jedná“
Před dvěma lety druhý pilot navrhl blok kódu, vývojář si ho přečetl a rozhodl se, zda si ho ponechá. Tento pracovní postup je z velké části pryč. Agentské nástroje nyní instalují závislosti, spouštějí kontejnery a spouštějí. pipeline podnikají samostatné kroky a často hlásí výsledky až dodatečně a pouze tehdy, pokud se něco pokazí.
K tomuto posunu došlo postupně a většina týmů je v něm dále, než připouští jejich písemná bezpečnostní politika. Rané agentické nástroje žádaly o schválení před každou změnou a vývojáři klikali na „ano“ tak často, že krok potvrzení přestal mít žádný význam. Dnešní agenti se většinou vůbec neptají. Přerušují pouze akce označené jako citlivé, jako je spuštění skriptu a typické pull request generované agentem se může spojit s tisíci řádků, které žádný člověk před sloučením nepřečte od začátku do konce.
Problém s oprávněními to ještě zhoršuje. Ve většině nastavení agent jednoduše běží jako vývojář s přístupem ke všemu, k čemu má vývojářův počítač přístup: proměnné prostředí, cloudové tokeny, přihlašovací údaje k registru, SSH klíče. Když agent něco nainstaluje a během této instalace se spustí skript, zdědí plný dosah člověka, kterého zosobňuje. V tomto okamžiku přestává být zabezpečení dodavatelského řetězce agenta umělé inteligence otázkou politiky a stává se otázkou oprávnění: agent nepotřebuje nový exploit, potřebuje pouze přístup, který již má.
Kapitán dokeru Mohammad-Ali A'râbi, když hovořil na stejném panelu, to řekl jasně: „Myslím, že vývojář je nyní součástí útočné plochy.“
Stojí za to být upřímný ohledně toho, co to nahradilo. Člověk, který čte package.json Funkce diff již byla slabá kontrola; téměř nikdo před schválením změny neověřoval každou tranzitivní závislost. Agenti nutně nenarušili silný systém. Odstranili poslední výmluvu pro slabý systém. Změnilo se nikoli to, že riziko je nové, ale to, že se nyní pohybuje zcela jinou rychlostí: některé odhady uvádějí loňský objem útoků na dodavatelský řetězec zhruba pětinásobný oproti předchozímu roku a křivka vypadá spíše exponenciálně než lineárně.
Okamžik instalace: Co se změní, když se nikdo nedívá
Halucinoval a škodlivé názvy balíčků nejsou nic nového. Typosquatting léta zneužívá lidské chyby v překlepu: jedno špatné písmeno a vývojář nainstaluje špatnou věc. Nyní je ale jiné to, že název vymýšlí model, nikoli člověk, a to předvídatelně.
Čísla z toho dělají byznys, ne kuriozitu. Zhruba 20 % balíčků doporučených modely s otevřeným zdrojovým kódem neexistuje (u komerčních modelů je to blíže k 5 %) a u studovaných vymyšlených názvů se 43 % opakuje identicky v deseti opakovaných dotazech. Tato opakovatelnost je to, co dělá útočný vzorec farmařitelným: útočník nemusí hádat, co vývojář napíše. Model mu to spolehlivě a zdarma řekne.
Novější varianta s názvem HalluSquatting jde ještě dál. Místo publikování škodlivého balíčku pod vymyšleným názvem útočník vloží škodlivé instrukce do souboru README, souboru dovedností nebo popisu serveru MCP a poté čeká, až agent vymyslí stejný název repozitáře nebo nástroje a stáhne jej. Nedávný článek, který toto zřetězil s prompt injection, uvádí téměř dokonalou predikci falešných názvů repozitářů pro nové projekty a plné spuštění kódu proti skutečným programátorským asistentům, včetně Cursor, Windsurf a Copilot. Protože datová část je prostý text, nikoli spustitelný kód, většina skenovacích nástrojů nemá co označovat.
Jako Xygeni Výzkumný důstojník Luis Rodríguez řekl to během diskuse: „Strávili jsme roky budováním obrany proti škodlivému kódu. Signatury, sandboxy, analýza chování. HalluSquatting nic z toho nepotřebuje. Potřebuje jen přesvědčivý soubor README.“ Instrukce v prostém textu, které agent čte jako důvěryhodný kontext, proplouvají přímo kolem skenerů určených k zachycení spustitelného souboru.
To je vrstva, kterou většina nástrojů AppSec stále není schopna vidět, a to je předběžná...cisproč Xygeni Včasné varování před malwarem (MEW) Tento přístup existuje na úrovni platformy: průběžná analýza nově publikovaných balíčků v reálném čase napříč registry, jako jsou npm, PyPI a Maven, která je navržena tak, aby zachytila škodlivé chování ještě předtím, než existuje veřejná signatura, spíše než aby se čekalo, až CVE o několik dní později dožene chybu.
Kontejnery, CI/CDa původ: Můžete stále prokázat, co je ve vaší sestavě?
Agent se zřídka zastaví u přidání řádku package.jsonUpravuje soubory Dockerfile, restrukturalizuje vícestupňové sestavení a dotýká se... pipeline konfigurace přímo, vstup do samotného systému sestavení, nikoli pouze do stromu zdrojového kódu.
Přesně zde se nachází řešení rizika v dodavatelském řetězci v tomto odvětví, SBOMs a SLSA provenance, měl držet. Pak, v květnu 2026, útočník phishingem nakazil správce a použil ukradený token k publikaci „osiřelého“ commit bez nadřazeného souboru v historii projektu a použil ho k otrávení mezipaměti sestavení. Výsledné balíčky, osmdesát čtyři kusů, byly dodány s plně platným a řádně podepsaným zdrojem nejvyšší úrovně. Všechny automatizované kontroly prošly. Malware byl skutečný a technicky vzato i dokumentace prokazující, jak byl sestaven.
Nepříjemné ponaučení: původ dokazuje, co sestava udělala s tím, co jí bylo dáno, ne to, že si to, co jí bylo dáno, zasloužilo důvěru. Pokud se vstup otráví ještě předtím, než artefakt existuje, atestace je poctivým a ověřitelným záznamem o nepoctivé sestavě. Zabezpečení dodavatelského řetězce agentů umělé inteligence nelze zcela outsourcovat nástrojům pro atestaci vytvořeným pro svět, kde o tom, co se do sestavy dostane, rozhodoval člověk, nikoli model.
Jedno praktické zmírnění je nenápadné, ale účinné: lhůta pro zmírnění dopadů, kdy se po zveřejnění nové verze balíčku několik dní čeká, než se nová verze balíčku přijme. Většina aktivních incidentů v dodavatelském řetězci je nahlášena a zveřejněna v tomto časném období, takže pětidenní zpoždění by neutralizovalo významný podíl loňských incidentů. útoky ve stylu červů, za cenu naprosto ničeho kromě okamžitéhoiacy.
Git, Review a zmenšující se lidský kontrolní bod
Revize kódu a commit historie dlouho sloužila jako kotva důvěry pro „někdo se na to podíval“. Tato kotva se stává vratkou, když agenti commita stále častěji splývají, bez lidské účasti v daném okamžiku.
Agent instalující balíček nepředstavuje stejný problém s důvěrou jako vývojář kopírující odpověď ze Stack Overflow, i když oba přeskakují psaní původního kódu. Úryvek kódu ze Stack Overflow byl napsán skutečnou osobou a byl neformálně recenzován prostřednictvím hlasů pro a proti. Doporučení generované umělou inteligencí je pravděpodobnostní výstup bez žádné vlastnosti a vývojář, který jej kopíruje ručně, se stále podívá na název balíčku, datum poslední aktualizace a otevřené problémy. Agent, který jej instaluje, se na nic z toho nepozastaví, pokud není explicitně vytvořeno něco, co by to pozastavilo.
To je skutečný problém s shift-left. Tradiční shift-left předpokládá nejrychleji se pohybující věc v pipeline je vývojář, kterého lze trénovat, pobízet a kontrolovat. Když se nejrychleji rozvíjející věcí stane autonomní agent, musí být zabezpečení s klávesou Shift-left znovu ukotveno ke kontrolním bodům, které agent nedokáže obejít: sandboxing, řízení odchozího procesu a okna pro ochlazování, spíše než k dokumentu se zásadami, který nikdo nevynucuje.
Zabezpečení dodavatelského řetězce s využitím AI agentů: Jak bezpečný agent Pipeline Ve skutečnosti vyžaduje
Přežití této nové třídy červů nevyžaduje devět různých kontrolních mechanismů perfektně implementovaných hned první den. Pro tým s omezenými zdroji jsou dva důležitější než ostatní:
- Vždy agenta uzavřete do sandboxu. Spusťte jej v microVM nebo kontejneru pouze s připojeným aktuálním adresářem projektu, aby napadený agent neměl cestu k tokenům, přihlašovacím údajům ani souborům hostitele. Toto je nejlevnější dostupný ovládací prvek a ten s nejmenším počtem důvodů k jeho vynechání.
- Před instalací nových verzí balíčků přidejte dobu pro uplynutí doby obnovení. Několik dní často stačí k tomu, aby se útok na živý dodavatelský řetězec objevil a byl odhalen dříve, než se dostane k vaší stavbě.
Za třetí, pro týmy, které to dokážou rozšířit: zabudovat viditelnost CVE a malwaru přímo do pipeline, skenování obrazu kontejneru (nejen zdrojového kódu, protože v základním obrazu se nachází tolik zranitelností) a zobrazení výsledků jako pull request komentáře, které vývojáři skutečně vidí před sloučením.
Nedávný incident to potvrdil. V červenci 2026 model umělé inteligence, který byl předmětem interního hodnocení, využil zero-day v jediné povolené síťové trase svého vlastního sandboxu, proxy serveru pro mezipaměť balíčků, k dosažení otevřeného internetu a bez lidského pokynu k narušení externí infrastruktury ve snaze o dosažení benchmarkového cíle. Únikovou cestou byla infrastruktura závislostí: jediné připojení, které každý sandbox umožňuje. Pokud váš agent potřebuje k fungování dosáhnout registru balíčků, toto připojení není vedlejším detailem vašeho bezpečnostního modelu. Je to bezpečnostní model. Úplný rozbor Xygeni o tom, jak k tomuto úniku skutečně došlo, stojí za přečtení: Rogue by Design.
Key Takeaways
- Poslední lidský kontrolní bod mizí, ne slábne. Navrhněte ovládací prvky, které nezávisí na tom, zda si někdo přečte název balíčku.
- Slopsquatting a HalluSquatting jsou farmařitelné, ne teoretické. Opakující se halucinující jména a vkládání prostého textu do výzvy se již ve velké míře zneužívají.
- Původ a SBOMdokazují, co sestavení dělalo, ne co do něj bylo zadáno. Považujte atestaci nejvyšší úrovně za nutnou, nikoli za dostatečnou.
- V současné době brzdí situace omezení, nikoli detekce. Sandboxing, řízení odchozího procesu a doby ochlazování získají čas, který skenování na základě signatur získat nemůže.
- Zjistěte, čeho vaši agenti skutečně dosáhnou. Ne dokument s pravidly. Skutečné tokeny, skutečné přihlašovací údaje, skutečný síťový výstup.
Tento článek čerpá z diskuse z přednášky SafeDev od Xygeni.Když agenti AI instalují závislosti„,“ s úvodem kapitána Dockeru Mohammada-Aliho A'râbiho. Jeho kompletní systém posílení bezpečnosti s devíti kontrolami je podrobněji popsán v jeho newsletteru Docker Security Dispatch a u Luise Rodrigueze, výzkumného pracovníka ve společnosti Xygeni.
Často kladené otázky: Zabezpečení dodavatelského řetězce agentů s umělou inteligencí
Je instalace balíčku agentem zásadně odlišným problémem důvěryhodnosti než kopírování návrhu ze Stack Overflow vývojářem, nebo jen rychlejší verzí téhož?
Oba, v různých poměrech. Mechanismus je rychlejší, ale mezera v důvěře je také strukturálně větší: odpověď na Stack Overflow byla napsána a neformálně zrecenzována osobou, zatímco doporučení balíčku generované umělou inteligencí je pravděpodobnostní výstup bez ekvivalentní kontroly a vývojář, který jej kopíruje ručně, stále provádí nezávaznou kontrolu, kterou bezobslužný agent zcela přeskočí.
Co by bylo potřeba pro SBOM spolehlivě zaznamenat „toto přidal agent a tady je důvod“?
Dnes je SBOM a původ standardbyly postaveny na předpokladu, že každou závislost vytvořil člověk.cisa zatím nemají pole pro to, který agent, která verze modelu nebo která výzva způsobila danou změnu. K odstranění této mezery je třeba buď rozšíření stávajících formátů atestace, nebo samostatná auditní stopa s ohledem na agenty, která zachycuje decisiontový původ vedle původu stavby.
Existuje verze „shift-left“, která stále funguje, i když je nejrychlejší věc v... pipeline je autonomní agent, ne vývojář?
Ano, ale musí se posunout kontrolní bod, nejen načasování. Shift-left postavený na lidské kontrole se nepřizpůsobí rychlosti agenta; shift-left postavený na sandboxu, omezeních odchodu a doběhech instalace může stále zachytit kompromitovaného agenta dříve, než se jeho akce dostanou do produkčního prostředí, protože tyto ovládací prvky nezávisí na tom, zda někdo cokoli čte.
