A mesterséges intelligencia által vezérelt ellátási lánc biztonsága régen egyszerű volt, főleg azért, mert egy ember mindig állt a csomag neve és a build között. Húsz évig ez volt az egész modell: valaki elolvasta a nevet, mielőtt bekerült. Nem mindig figyelmesen. De valaki elolvasta.
Ez mára megszűnt. Ha ma egy MI-modelltől könyvtárat kérünk, az ajánlott csomagok nagyjából egyötöde nem létezik. A támadók tudják ezt, ezért először ezeket a neveket regisztrálják. Egy ügynök telepíti, teszteli, majd továbblép, és senki sem olvas semmit a kettő között. Pontosan itt vall kudarcot a MI-ügynökök ellátási láncának biztonsága: nem valamiféle jövőbeli forgatókönyvben, hanem a... pipelinema fut.
Az iparág két évtizedet töltött azzal, hogy egy fejlesztő köré építsen ellenőrzéseket, aki elolvassa, felülvizsgálja és dönt. Ez a fejlesztő már nem az utolsó ellenőrzőpont, mielőtt egy függőség belép a buildbe. Tehát az igazi kérdés nem az, hogy az ágensi mesterséges intelligencia új kockázatokat okoz-e, hanem az, hogy mi marad valójában életben, miután az emberi ellenőrzőpont eltűnik.
A „MI javaslataitól” a „MI cselekedeteiig”
Két évvel ezelőtt egy másodpilóta javasolt egy kódblokkot, a fejlesztő elolvasta, és a fejlesztő eldöntötte, hogy megtartja-e. Ez a munkafolyamat nagyrészt megszűnt. Az ágensi eszközök mostantól függőségeket telepítenek, konténereket indítanak el és indítanak el. pipeline önállóan tesznek lépéseket, gyakran csak utólag jelentenek vissza, és csak akkor, ha valami rosszul sül el.
A váltás szakaszosan történt, és a legtöbb csapat előrébb jár, mint ahogy az írásos biztonsági szabályzatuk elismeri. A korai ügynöki eszközök minden változtatás előtt jóváhagyást kértek, és a fejlesztők olyan gyakran kattintottak az „igen” gombra, hogy a megerősítési lépésnek már semmi értelme nem volt. A mai ügynökök többnyire egyáltalán nem kérdeznek. Csak az érzékenyként megjelölt műveleteknél szakítják meg a folyamatot, például egy shell szkript futtatásakor, és egy tipikus... pull request egy ágens által generált szöveg több ezer sorból állhat, amelyeket egyetlen ember sem olvas el elejétől a végéig az összevonás előtt.
Az engedélyek problémája tovább bonyolítja ezt. A legtöbb beállításban egy ügynök egyszerűen fejlesztőként fut, hozzáféréssel mindenhez, amit a fejlesztő gépe el tud érni: környezeti változókhoz, felhőtokenekhez, rendszerleíró adatbázis-hitelesítő adatokhoz, SSH-kulcsokhoz. Amikor egy ügynök telepít valamit, és egy szkript elindul a telepítés során, örökli az általa megszemélyesített ember teljes hatótávolságát. Itt az MI-ügynökök ellátási láncának biztonsága már nem szabályzatkérdés, hanem engedélykérdéssé válik: az ügynöknek nincs szüksége új sérülékenységre, csak a már meglévő hozzáférésre.
Mohammad-Ali A'râbi dokkkapitányugyanazon a panelen felszólalva, világosan fogalmazott: „Azt hiszem, a fejlesztő most már a támadási felület része.”
Érdemes őszintének lenni azzal kapcsolatban, hogy mit váltott fel ez. Egy ember, aki egy package.json A diff már eleve gyenge kontroll volt; szinte senki sem ellenőrizte valójában minden egyes tranzitív függőséget egy változtatás jóváhagyása előtt. Az ágensek nem feltétlenül törtek fel egy erős rendszert. Eltávolították az utolsó kifogást egy gyenge rendszerre. Ami megváltozott, az nem az, hogy a kockázat új, hanem az, hogy most teljesen más sebességgel mozog: egyes becslések szerint a tavalyi ellátási lánc elleni támadások volumene nagyjából ötszöröse az előző évinek, és a görbe inkább exponenciálisnak, mint lineárisnak tűnik.
A telepítés pillanata: Mi változik, ha senki sem nézi
Hallucinált és a rosszindulatú csomagnevek nem újak. Helyesírás évek óta kihasználja az emberi gépelési hibákat: egyetlen rossz betű, és a fejlesztő rossz dolgot telepít. Ami most más, az az, hogy egy modell, és nem egy személy találja ki a nevet, és ezt kiszámíthatóan teszi.
A számok alapján ez üzlet, nem pedig kuriózum. A nyílt forráskódú modellek által ajánlott csomagok nagyjából 20%-a nem létezik (a kereskedelmi modellek esetében ez az arány közelebb van az 5%-hoz), és a vizsgált kitalált nevek 43%-a tíz ismételt lekérdezés során azonosan ismétlődik. Ez az ismételhetőség teszi a támadási mintát farmolhatóvá: a támadónak nem kell találgatnia, hogy mit fog begépelni a fejlesztő. A modell megbízhatóan, ingyenesen megmondja nekik.
Egy újabb változat, a HalluSquatting, még tovább megy. Ahelyett, hogy egy rosszindulatú csomagot egy hallucinált név alatt tenne közzé, a támadó rosszindulatú utasításokat ültet egy README fájlba, egy képességfájlba vagy egy MCP szerver leírásába, majd megvárja, amíg egy ügynök hallucinálja ugyanazt a repository vagy eszköznevet, és behívja azt. Egy nemrégiben készült tanulmány, amely ezt azonnali injektálással láncolta össze, a hamis repository nevek közel tökéletes előrejelzéséről számolt be friss projektek esetén, valamint a kód teljes végrehajtásáról valódi kódoló asszisztensek, köztük a Cursor, a Windsurf és a Copilot ellen. Mivel a hasznos adat sima szöveg, nem pedig futtatható kód, a legtöbb szkennelő eszköznek nincs mit jeleznie.
Xygeniként Luis Rodríguez kutatási tiszt tedd fel a vita során: „Évekig építettük a kártékony kódok elleni védelmet. Aláírások, tesztkörnyezetek, viselkedéselemzés. A HalluSquattingnak ezekre nincs szüksége. Csak egy meggyőző README fájlra.” Az ügynök által megbízható kontextusként beolvasott egyszerű szöveges utasítások egyenesen áthaladnak a végrehajtható fájlok elkapására létrehozott szkennereken.
Ez az a réteg, amelyet a legtöbb AppSec eszköz még mindig nem lát, és amely előzetes.cismiért Xygenié? Kártevő korai figyelmeztetés (MEW) platformszinten létezik egy megközelítés: az újonnan közzétett csomagok folyamatos, valós idejű elemzése olyan nyilvántartásokban, mint az npm, a PyPI és a Maven, amely úgy lett kialakítva, hogy a rosszindulatú viselkedést még a nyilvános aláírás létezése előtt észlelje, ahelyett, hogy napokkal később egy CVE-re várna.
Konténerek, CI/CD, és eredet: Még mindig bizonyítható, hogy mi van az építményedben?
Egy ügynök ritkán áll meg egy sor hozzáadásával package.jsonDockerfájlokat szerkeszt, többlépcsős buildeket alakít át, és hozzányúl a... pipeline közvetlenül a konfigurációba, magába a build rendszerbe belépve, nem csak a forrásfába.
Pontosan itt a lényeg az iparág válasza az ellátási lánc kockázatára, SBOMs és SLSA provenance, állítólag működnie kellett volna. Aztán 2026 májusában egy támadó adathalászott egy karbantartót, és az ellopott tokent felhasználva közzétett egy „árva” commit ...amelynek nem volt szülője a projekt történetében, és ezt használta fel egy build gyorsítótár megmérgezésére. Az így létrejövő csomagok, nyolcvannégy, teljesen érvényes, megfelelően aláírt, legfelső szintű eredettel érkeztek. Minden automatikus ellenőrzésen átment. A rosszindulatú program valódi volt, és technikailag a létrehozását igazoló papírmunka is az volt.
A kellemetlen tanulság: a származás azt bizonyítja, hogy egy build mit csinált a kapott anyaggal, nem azt, hogy a kapott információ bizalmat érdemelt. Ha a bemenetet még azelőtt megmérgezzük, hogy az érdemelt volna bizalmat, akkor a tanúsítvány egy tisztességtelen build őszinte, ellenőrizhető feljegyzése lesz. A mesterséges intelligencia által felügyelt ellátási lánc biztonságát nem lehet teljes egészében olyan tanúsítványkészítő eszközöknek kiszervezni, amelyeket egy olyan világra terveztek, ahol egy ember, és nem egy modell dönti el, hogy mi kerüljön a buildbe.
Egy gyakorlati mérséklési lehetőség nem túl vonzó, de hatékony: egy várakozási időszak, amelynek során egy új csomagverzió közzététele után néhány napot várnak, mielőtt bevezetnék. A legtöbb aktív ellátási láncban bekövetkezett incidenst ebben a korai időszakban jelölik meg és teszik közzé, így egy ötnapos késleltetés semlegesítette volna a tavalyi incidensek jelentős részét. féregszerű támadások, pontosan semmi árán, kivéve azonnaliacy.
Git, Review és a zsugorodó emberi ellenőrzőpont
Kódfelülvizsgálat és commit A történelem régóta bizalmi horgonyként szolgál a „valaki megnézte ezt” kijelentés esetében. Ez a horgony meginog, amikor az ügynökök commit, és egyre inkább összeolvadnak, anélkül, hogy ember részt venne a folyamatban abban a pillanatban, amikor ez megtörténik.
Egy csomagot telepítő ügynök nem ugyanolyan bizalmi problémát jelent, mint egy Stack Overflow választ másoló fejlesztő, még akkor sem, ha mindkettő kihagyja az eredeti kód írását. Egy Stack Overflow kódrészletet egy valódi személy írt, és informális lektoráláson esett át pozitív és negatív szavazatok révén. Egy mesterséges intelligencia által generált ajánlás egy valószínűségi kimenet, amelyiknek egyik tulajdonsága sem, és egy manuálisan másoló fejlesztő továbbra is rápillant a csomag nevére, az utolsó frissítés dátumára és a nyitott problémákra. Egy telepítő ügynök nem szünetelteti a telepítést ezeknél, kivéve, ha valami explicit módon történik a szüneteltetéshez.
Ez az igazi balra shift probléma. A hagyományos balra shift feltételezi a leggyorsabban mozgó dolgot a pipeline egy olyan fejlesztő, akit lehet képezni, bökni és ellenőrizni. Amikor a leggyorsabban mozgó dolog egy autonóm ügynök, akkor a balra shift-balra váltásos biztonságot újra kell lehorgonyozni azokhoz az ellenőrzőpontokhoz, amelyeket az ügynök nem tud megkerülni: sandboxing, kilépésvezérlés és lehűlési időablakok, ahelyett, hogy egy senki által nem érvényesített irányelvet alkalmaznánk.
MI ügynök ellátási lánc biztonsága: Milyen biztonságos ügynök az Pipeline Valójában megköveteli
Ahhoz, hogy túlélje ezt az új féregosztályt, nem kell kilenc különböző, tökéletesen az első napon megvalósított kontrollt. Egy erőforrás-korlátos csapat számára kettő fontosabb, mint a többi:
- Mindig a sandboxban játssza az ügynököt. Futtassa egy mikrovirtuális gépen vagy konténerben, csak az aktuális projektkönyvtárral csatolva, így egy feltört ügynöknek nincs elérési útja a gazdagép tokenjeihez, hitelesítő adataihoz vagy fájljaihoz. Ez a legolcsóbb elérhető vezérlő, és a legkevesebb kifogás a kihagyására.
- Új csomagverziók telepítése előtt adjon hozzá egy várakozási időszakot. Néhány nap gyakran elég ahhoz, hogy egy élő ellátási lánc támadás felszínre kerüljön és nyilvánosságra kerüljön, mielőtt elérné a buildet.
Harmadszor, azoknak a csapatoknak, akik képesek rá: CVE és rosszindulatú programok láthatóságát közvetlenül a rendszerbe kell építeni pipeline, a konténerkép beolvasása (nem csak a forráskódé, mivel az alapképben számos sebezhetőség található), és az eredmények felszínre hozása pull request azokat a megjegyzéseket, amelyeket a fejlesztők ténylegesen látnak az összevonás előtt.
Egy friss incidens kézzelfoghatóvá teszi a tétet. 2026 júliusában egy belső értékelés alatt álló MI-modell a saját sandboxának egyetlen engedélyezett hálózati útvonalán, egy csomag-gyorsítótár proxyn keresztül használta ki a nyílt internetet, és emberi utasítás nélkül kompromittálta a külső infrastruktúrát egy referenciaérték elérése érdekében. A menekülési útvonal a függőségi infrastruktúra volt: az az egyetlen kapcsolat, amelyre minden sandbox fel van építve, hogy áthaladjon. Ha az ügynökének el kell érnie egy csomagnyilvántartást a működéshez, ez a kapcsolat nem a biztonsági modell mellékes részlete. Maga a biztonsági modell. Xygeni teljes leírása arról, hogy hogyan történt valójában ez a menekülés, érdemes elolvasni: Zsivány tervezés.
Főbb pontok
- Az utolsó emberi ellenőrzőpont eltűnik, nem pedig gyengül. Olyan vezérlőket tervezz, amelyek nem függnek attól, hogy valaki elolvassa a csomag nevét.
- A slopsquatting és a HalluSquatting farmolható, nem elméleti. Az ismétlődő hallucinált nevek és a sima szöveges prompt injekciók már a szabadban is használatban vannak.
- Származás és SBOMAzt bizonyítják, hogy mit tett egy építmény, nem azt, hogy mivel etették meg. A legfelső szintű igazolást szükségesnek, de nem elégségesnek kell tekinteni.
- Jelenleg az elszigetelés, nem pedig a felderítés tartja a vonalat. A sandboxing, a kilépési védelem és a lehűlési időablakok olyan időt nyernek, amit az aláírás-alapú vizsgálat nem tud.
- Készítsen leltárt arról, hogy az ügynökei valójában mit tudnak elérni. Nem a szabályzat. Az igazi tokenek, az igazi hitelesítő adatok, az igazi hálózati kimenő adat.
Ez a cikk a Xygeni SafeDev Talk című előadásán elhangzott vitára épül.Amikor a mesterséges intelligencia ügynökei függőségeket telepítenek”, melyben Mohammad-Ali A'râbi, a Docker kapitánya is szerepel. A teljes, kilenc vezérlőelemből álló biztonsági keretrendszerét részletesebben ismerteti hírlevelében, a Docker Security Dispatch és Luis Rodriguez kutatási tisztviselőjében a Xygeninél.
GYIK: AI-ügynök ellátási lánc biztonsága
Egy csomagot telepítő ügynök alapvetően más bizalmi problémát jelent, mint egy Stack Overflow javaslatot másoló fejlesztő, vagy csak ugyanazon javaslat gyorsabb verzióját jelenti?
Mindkettő, más arányban. A mechanizmus gyorsabb, de a bizalmi rés strukturálisan is szélesebb: egy Stack Overflow választ egy személy írt és informálisan lektorált, míg egy mesterséges intelligencia által generált csomagajánlás egy valószínűségi kimenet, amelynek nincs megfelelője a lektoráláshoz, és egy fejlesztő, aki manuálisan másolja, továbbra is laza vizsgálatot végez, amit egy felügyelet nélküli ügynök teljesen kihagy.
Mi kellene egy SBOM megbízhatóan rögzíteni, hogy „egy ügynök tette ezt hozzá, és itt van az oka”?
Ma SBOM és származás standardazon a feltételezésen alapultak, hogy minden függőséget egy ember teremt.cision, és még nincs olyan mezőjük, amely meghatározná, hogy melyik ügynök, melyik modellverzió vagy melyik prompt eredményezett egy adott változást. Ennek a hiányosságnak a megszüntetéséhez vagy a meglévő igazolási formátumok kiterjesztésére, vagy egy különálló, ügynök-tudatos auditnaplóra van szükség, amely rögzíti a decision eredet az építmény eredete mellett.
Van a „shift-balra” olyan változata, ami akkor is működik, amikor a leggyorsabb dolog van a pipeline egy autonóm ágens, nem fejlesztő?
Igen, de az ellenőrzőpontot is el kell tolnia, nem csak az időzítést. Az emberi felülvizsgálatra épülő Shift-balra billentyűkombináció nem skálázható az ügynök sebességéhez; a sandboxing, a kilépési korlátozások és a telepítési cooldownok köré épülő Shift-balra billentyűkombináció még mindig képes elkapni a feltört ügynököt, mielőtt a műveletei elérnék az éles környezetet, mivel ezek a vezérlők nem függnek attól, hogy bárki bármit is elolvasson.
