Férgek, szivárgások, humán tévedések: hogyan törték fel az MI-csomagokat?
Május elején egy önmagát terjesztő féreg mindössze hat perc alatt 84 káros csomagot juttatott fel a TanStack fejlesztői csomagjaiba a GitHubon keresztül. Nem adathalászattal vagy 2FA elfogásával jutott be: az igazolt céges hozzáférést felhasználva élő OIDC (OpenID Connect) tokent szerzett az Actions runner memóriájából, majd azzal, szabályos workflow-t követve, közzétett. A bizalomra épülő rendszer épp úgy működött, ahogy kellett – mégis, fertőzött csomag lett az eredmény.
Ezután alig két nappal derült ki, hogy az OpenAI két alkalmazottjának eszközét kompromittálták, és érzékeny adatok szivárogtak ki a belső kódtárakból. Emiatt a vállalat kénytelen volt visszahívni a macOS biztonsági tanúsítványait, és minden desktopfelhasználójának frissítést írt elő. Bár a cég épp a közelmúltban szigorította a kiadási folyamatot – egy korábbi incidensből tanulva –, a két fertőzött munkaállomáson nem frissült időben a konfiguráció.
Hibás kiadások: véletlenül publikált forráskód és ellopott kulcsok
Március végén az Anthropic egy óriási baklövést követett el: a Claude Code npm-csomag 59,8 MB-nyi, teljes forrásmap-fájllal került ki a nyilvános szerverre, amely 513 ezer sor, mintegy kétezer fájlból álló, obfuszkálatlan TypeScript-kódot, ügynöklogikát, rendszerutasításokat és feature-flag-eket is tartalmazott. Mindez véletlen csomagolási hiba – egy hiányzó sor a .npmignore fájlban – miatt történhetett meg, de a kód így minden belépési korlátozás nélkül letölthetővé vált bárki számára. Mindössze néhány óra alatt le is vették a hibás csomagot.
Ennek ellenére a legnagyobb hullámokat a LiteLLM Python-csomaghoz kapcsolódó támadás keltette. Március utolsó hetében egy fenyegető csoport, amely korábban már feltörte az Aqua Security Trivy szkennerét, mérgezett verziókat juttatott fel a PyPI-re. Ezekből közel 47 ezer letöltés történt negyven perc alatt, mielőtt eltávolították. A kompromittált LiteLLM-et számos nagy MI-infrastruktúra is használta, így a mérgezés eljutott a Mercorhoz is, amely a Meta és az OpenAI számára szolgáltat tanítóadatokat. Mintegy 4 terabájt adat került a támadókhoz, köztük a Meta belső tréningmódszertani anyagai. Néhány napon belül csoportos per is indult az ügyben.
A build-pipeline a legnagyobb vakfolt
A négy incidens közös pontja, hogy nem a modellből indultak a veszélyek, hanem a kiadási folyamat réseit használták ki. A hagyományos red team auditok a modellek biztonságát ellenőrzik, miközben a legkritikusabb folyamatok – a pipeline-ok, a CI-futtatók, a csomagolási ellenőrzések – kívül esnek a látókörön.
Ez világosan látszott az OpenAI példáján: május 10-én elindították a saját, GPT-5.5-ön és új, permisszív modellen alapuló kiberbiztonsági kezdeményezésüket, majd másnap már be is következett az újabb ellátási lánc-támadás. Hiába volt folyamatban a védelmi rendszer kiterjesztése, a támadás gyorsabb volt a kiadási biztonsági frissítésnél.
A szakma is ugyanazt a rést látta: amikor a tanúsítványokat kell sürgősen cserélni, az azt jelzi, hogy a bizalom alapját, a hitelesítést érte támadás.
Mit kellene máshogy csinálni? – Feladatsor a biztonsági csapatoknak
A legfontosabb teendők: minden MI-beszállítói kérdőívén szerepeljen, hogy saját release-pipeline-ját is red-teamezték-e, mikor, és pontosan milyen kiterjedésben. Ha nincs dátum vagy dokumentáció a terjedelemről, az maga a kritikus hiány.
Ezután minden fejlesztői csapatnak végig kell mennie a saját pipeline-jain: külön értékelve a CI-runner izolációját, a kiadási csomagolás humán átvizsgálását, az OIDC-tokenek és tanúsítványok kezelését, a függőségek életciklusának automatikus figyelését, a kiadás méreteinek és tartalmának auditját. Ezen túl minden fejlesztői vagy kiadói hozzáféréshez hardveres kulcsot kellene előírni, a transzitív függőségi fák auditját negyedévente megismételni.
A TanStack-féreg megmutatta: a támadók nemcsak CI-titkokat keresnek, hanem a teljes fejlesztői környezetben mindenhol keresik a hitelesítő adatokat – .claude.json, 1Password, Bitwarden, Kubernetes-tokenek, shell-előzmények, API-kulcsok. A tipikus MI-programozó gépéhez vezető utat a féreg már ismeri.
Lehetetlen csak rendszerszintű védelemmel nyerni
Bármennyire fontos a rendszeres red teamelés és a modellek folyamatos tesztelése, a szoftverkiadási folyamat minden apró lépése ugyanakkora figyelmet igényel. Nincs olyan automatizált rendszer, amely kiválthatná az emberi éberséget és a tudatos folyamatellenőrzést. A védelem akkor működik, ha a munkafolyamat minden szintjén keresik és aktívan zárják a hézagokat – nemcsak a modellekben, hanem az egész kiadási láncban is.
