Supply Chain támadások az AI-ban: a „mérgezett forrásvidék” problémája

2.1. Pretrained modellek és súlyfájlok

Az előtanított modellek olyan paraméterhalmazok, amelyek egy korábbi, nagyléptékű tanulási folyamat eredményeként jönnek létre. Biztonsági szempontból a súlyfájlok nem tekinthetők egyszerű passzív adatnak. A modellparaméterek a tanítóadatokból, optimalizációs folyamatból és architekturális döntésekből származó viselkedési mintázatokat kódolnak. Egy kompromittált modell ezért közvetlenül befolyásolhatja a downstream alkalmazás döntéseit, osztályozási kimeneteit, generált válaszait vagy biztonsági határait.

Különösen veszélyesek azok a modellek, amelyek normál validációs környezetben megfelelően teljesítenek, de ritka vagy támadó által kontrollált bemeneti mintázatokra előre meghatározott, nem kívánt viselkedést mutatnak. Ezt a jelenséget a szakirodalom gyakran modell-backdoor vagy trojanizált modell néven tárgyalja.

2.2. Adatkészletek és annotációs láncok

Az adatkészletek az AI-rendszerek egyik legkritikusabb inputját jelentik. A modell által megtanult reprezentációk közvetlenül az adatok statisztikai és szemantikai szerkezetéből származnak. Ezért az adatmanipuláció nem egyszerű inputhiba, hanem a modell későbbi viselkedésébe beépülő strukturális kockázat.

A dataset poisoning során a támadó olyan adatokat juttat a tanító- vagy finomhangolási készletbe, amelyek látszólag legitimnek tűnnek, de célzottan torzítják a modell tanulását. Ez történhet hibás címkézéssel, kontextuális torzítással, trigger-mintázatok beágyazásával vagy a webes scrapingre optimalizált tartalom publikálásával. Az utóbbi különösen fontos a nagy nyelvi modellek és multimodális rendszerek esetében, amelyek tanítóadatai gyakran nagy mennyiségű webes forrásból származnak.

2.3. Függőségek, keretrendszerek és orchestration rétegek

Az AI-rendszerek fejlesztése jelentős mértékben támaszkodik külső könyvtárakra és keretrendszerekre. Ide tartoznak a numerikus számítási könyvtárak, mélytanulási keretrendszerek, modellbetöltő eszközök, adatelőkészítő csomagok, vektoradatbázis-kliensek, agent orchestration frameworkök és deployment infrastruktúrák.

E komponensek kockázata kettős. Egyrészt öröklik a klasszikus szoftverellátási lánc sérülékenységeit, például a rosszindulatú csomagokat, dependency confusion támadásokat vagy typosquattingot. Másrészt AI-környezetben gyakran magas jogosultsági szinten, GPU-erőforrásokkal, fájlrendszer-hozzáféréssel, titokkezelőkkel vagy hálózati kapcsolatokkal futnak, így kompromittálásuk közvetlen rendszerkompromittációhoz vezethet.

2.4. Model hubok és közösségi bizalmi infrastruktúra

A model hubok centralizált elosztópontként működnek: modellek, datasetek, konfigurációk, tokenizerfájlok, demoalkalmazások és dokumentációk érhetők el rajtuk. Ezek a platformok a kutatás és fejlesztés gyorsításának kulcsfontosságú eszközei, ugyanakkor implicit bizalmi réteget is létrehoznak. A felhasználók sokszor a letöltésszám, népszerűség, modellnév, felhasználói profil vagy dokumentáció alapján döntenek, nem pedig formális biztonsági audit alapján.

Ez a működési modell lehetőséget teremt typosquattingra, hamisított modellidentitásra, social proof alapú bizalomépítésre, illetve olyan „optimalizált” modellek terjesztésére, amelyek valójában rejtett viselkedési vagy futtatási kockázatot hordoznak.

2.5. Training–evaluation–deployment pipeline

Az AI supply chain sérülékenysége gyakran nem egyetlen komponensben, hanem a teljes életciklusban jelenik meg. A training, evaluation és deployment pipeline köti össze az adatokat, modelleket, kódot, infrastruktúrát és monitoring folyamatokat. Egy sérülékeny modellbetöltési lépés, nem reprodukálható finomhangolás, hiányos benchmarkolás vagy ellenőrizetlen deployment artefaktum elegendő lehet ahhoz, hogy a kompromittáció átjusson a fejlesztési környezetből az éles rendszerbe.

3.1. Model supply chain compromise: manipuláció a súlyok szintjén

A model supply chain compromise olyan támadási forma, amelyben a támadó egy látszólag legitim modellt publikál vagy módosít, miközben annak belső viselkedése bizonyos feltételek mellett eltér a várttól. A támadás nem feltétlenül igényel klasszikus értelemben vett rosszindulatú kódot. A káros viselkedés a modellparaméterekben, a tanult reprezentációkban vagy a döntési határok módosulásában jelenhet meg.

A modell-backdoor lényege, hogy a rendszer normál bemeneteken megfelelő teljesítményt mutat, de specifikus trigger jelenlétében támadó által kívánt kimenetet produkál. Egy képosztályozó rendszer például egy apró vizuális mintázatra hibás címkét adhat; egy nyelvi modell pedig meghatározott szöveges minta esetén megkerülheti a biztonsági irányelveket vagy preferált választ generálhat.

A trigger-alapú trojan viselkedés különösen nehezen detektálható, mivel a modell csak ritka bemeneti környezetben aktiválja a rejtett döntési útvonalat. Ez megkülönbözteti a hagyományos hibáktól: a támadás nem feltétlenül jelenik meg általános teljesítményromlásként, ezért a standard validációs metrikák nem biztosítanak elegendő védelmet.

3.2. Data supply chain attack: upstream adatmérgezés

Az adatmérgezés az AI supply chain egyik legfontosabb támadási kategóriája, mivel a modell tanulási folyamata közvetlenül az adatokból építi fel a reprezentációit. Upstream támadás esetén a kompromittáció még azelőtt történik, hogy az adat bekerülne a fejlesztési pipeline-ba. Ez különösen veszélyes, mert a későbbi fejlesztési szakaszokban az adat már legitim forrásként jelenhet meg.

A dataset poisoning nem feltétlenül durva vagy könnyen észlelhető manipuláció. Gyakran finom, kontextuális torzításokról van szó: bizonyos fogalmak, csoportok, viselkedések vagy döntési helyzetek következetesen meghatározott irányban jelennek meg az adatokban. A modell ezt nem explicit szabályként, hanem statisztikai összefüggésként tanulja meg.

A scraping-alapú adatbevitel további kockázatot jelent. Ha egy szervezet automatizáltan gyűjt webes tartalmakat tanítási vagy retrieval célra, a támadó képes olyan tartalmat publikálni, amely kifejezetten az adatgyűjtő pipeline-ba való bekerülésre optimalizált. Ez összekapcsolja az adatmérgezést a prompt injection és indirect prompt injection problémájával: a támadó nem közvetlenül a futó modellt támadja, hanem azt az információs környezetet, amelyből a modell vagy az azt kiszolgáló rendszer később dolgozni fog.

3.3. Dependency attack: kódszintű kompromittáció AI-környezetben

A dependency attack a klasszikus szoftverbiztonsági támadásokhoz áll közelebb, de AI-környezetben gyakran nagyobb hatókörrel bír. A rosszindulatú csomagok buildidőben, fejlesztési környezetben vagy futásidőben kerülhetnek be a rendszerbe. A dependency confusion kihasználja, hogy a csomagkezelők és buildfolyamatok nem mindig különítik el megfelelően a privát és publikus namespace-eket. A typosquatting pedig arra épít, hogy a fejlesztő egy ismert csomagnévhez nagyon hasonló, de támadó által kontrollált csomagot telepít.

AI-rendszerekben e támadások súlyosabbak lehetnek, mert a fejlesztési környezetek gyakran nagy mennyiségű adatot, API-kulcsokat, modellartefaktumokat, felhőerőforrásokat és belső kutatási eredményeket tartalmaznak. Egy kompromittált függőség nemcsak kódfuttatást eredményezhet, hanem modell- és adatlopást, finomhangolási folyamat manipulálását vagy deployment artefaktumok módosítását is.

Kiemelt figyelmet érdemel a model loading RCE problémája. Egyes szerializációs formátumok, különösen a Python pickle-alapú megoldásai, nem pusztán adatot tárolnak, hanem objektumrekonstrukció közben kódvégrehajtást is lehetővé tehetnek. Ez azt jelenti, hogy egy modell „betöltése” bizonyos formátumok esetén valójában nem semleges adatbeolvasás, hanem potenciális kódfuttatási esemény. Ez teljes rendszerkompromittációhoz vezethet, különösen akkor, ha a modellbetöltés automatizált pipeline-ban, magas jogosultsági szinten vagy izoláció nélkül történik.

3.4. Model hub támadások: a bizalmi réteg kihasználása

A model hubok elleni támadások központi eleme az implicit bizalom kihasználása. A támadó nem feltétlenül közvetlenül egy szervezet infrastruktúráját támadja, hanem olyan artefaktumot hoz létre, amelyet a célpont önként tölt le és integrál.

A typosquatting a modell- vagy szerzőnév megtévesztő hasonlóságára épít. A trust exploitation kifinomultabb forma: a támadó hitelesnek tűnő profilt épít, dokumentációt készít, benchmarkeredményeket közöl, és a modellt gyorsabb, kisebb, olcsóbb vagy optimalizált alternatívaként pozicionálja. Az ilyen modellek nem feltétlenül azonnal kártékonyak. Előfordulhat, hogy csak specifikus deployment környezetben, meghatározott inputokon vagy adott downstream feladatra finomhangolva aktiválják a nem kívánt viselkedést.

5.1. Model provenance és adatproveniencia

A model provenance célja, hogy minden felhasznált modell eredete, verziója, módosítási története, tanítási vagy finomhangolási kontextusa és publikációs útvonala visszakövethető legyen. Ez kiterjedhet a modellkártyákra, commit-hash-ekre, letöltési forrásokra, szerzői információkra, licencfeltételekre, checkpointokra és evaluációs eredményekre.

Az adatproveniencia hasonló logikát követ: dokumentálni kell az adatok eredetét, gyűjtési módját, annotációs folyamatát, transzformációit, szűrését, deduplikációját és jogi felhasználhatóságát. A cél nem pusztán megfelelőségi dokumentáció, hanem biztonsági kontroll: ha később sérülékenység, torzítás vagy kompromittáció merül fel, a hatás gyorsan visszakövethető és lokalizálható legyen.

5.2. Artefact signing és integritás-ellenőrzés

Az artefact signing kriptográfiai módszerekkel biztosítja, hogy egy modell, dataset, konténerkép vagy könyvtár nem módosult a publikálás óta. A digitális aláírás, hash-alapú ellenőrzés és ellenőrzött release-folyamat csökkenti annak kockázatát, hogy a pipeline manipulált komponenst töltsön be.

Ez különösen fontos model hubok, CI/CD rendszerek és automatizált deployment pipeline-ok esetében. Az integritás-ellenőrzésnek nem opcionális manuális lépésnek, hanem kötelező pipeline-kapunak kell lennie.

5.3. SBOM, AIBOM és komponensleltár

A Software Bill of Materials olyan komponenslista, amely dokumentálja a szoftverrendszerben felhasznált könyvtárakat, verziókat és függőségeket. AI-rendszerek esetében ezt a megközelítést ki kell terjeszteni modellekre, datasetekre, tokenizerfájlokra, embedding-modellekre, evaluációs készletekre, infrastruktúra-komponensekre és külső szolgáltatókra is.

Az AI-specifikus komponensleltár — gyakran AIBOM vagy AI-SBOM néven — lehetővé teszi a sérülékenységek hatáselemzését, a licenc- és compliance-kockázatok feltárását, valamint a kompromittált upstream komponensek gyors azonosítását. Egy ilyen leltár nem önmagában oldja meg a supply chain problémát, de alapvető feltétele a kockázatok mérhetőségének és kezelhetőségének.

5.4. Reprodukálható és kontrollált training

A reproducible training célja, hogy a kritikus modellek tanítása vagy finomhangolása ellenőrzött, dokumentált és lehetőség szerint reprodukálható környezetben történjen. Teljes reprodukálhatóság nagy modellek esetében gyakran nehezen érhető el, de a determinisztikus konfigurációk, rögzített adatverziók, naplózott hyperparaméterek, kontrollált random seedek és verziózott pipeline-ok jelentősen csökkentik a kockázatot.

A kontrollált training különösen fontos magas kockázatú alkalmazásokban, például egészségügyi, pénzügyi, ipari, kiberbiztonsági vagy kritikus infrastruktúrához kapcsolódó AI-rendszerekben. Ilyen környezetekben nem elegendő egy publikus modell közvetlen átvétele; szükség van belső validációra, threat modelingre és governance-jóváhagyásra.

5.5. Safe serialization és izolált modellbetöltés

A safe serialization célja annak biztosítása, hogy a modellfájl valóban adatként viselkedjen, és betöltése ne járjon automatikus kódfuttatással. A safetensors típusú formátumok ebben az irányban fontos előrelépést jelentenek, mivel a tensoradatok tárolását kifejezetten úgy tervezik, hogy elkerüljék a pickle-szerű objektumdeszerializáció kockázatait.

Ezzel párhuzamosan a modellbetöltést izolált környezetben kell végrehajtani. A minimális jogosultság elve, sandboxing, konténerizáció, hálózati izoláció és futtatási policy-k alkalmazása csökkenti annak hatását, ha egy modellartefaktum mégis rosszindulatú vagy sérülékeny.

5.6. Zero trust AI pipeline

Az AI supply chain biztonságának alapelve, hogy egyetlen külső komponens sem tekinthető automatikusan megbízhatónak. A zero trust szemlélet az AI-pipeline-ban azt jelenti, hogy minden modell, dataset, könyvtár, benchmark, konfiguráció és deployment artefaktum ellenőrzésen megy keresztül, mielőtt bekerülne a rendszerbe.

Ez a gyakorlat magában foglalja a forrásellenőrzést, integritásvalidációt, biztonsági szkennelést, statikus és dinamikus elemzést, modellviselkedési teszteket, red teaminget, hozzáférés-szabályozást és folyamatos monitoringot. A cél nem az abszolút bizalom megteremtése, hanem az, hogy a kompromittáció valószínűsége és hatása mérhetően csökkenjen.