ExploitGym: Amikor az AI ügynökök nemcsak kódolnak, hanem exploitokat is építenek

Az AI ügynökök rég túlléptek az egyszerű kódrészletek generálásán. Teljes kódtárakban navigálnak, hibákat javítanak, teszteket futtatnak és pull requesteket készítenek. Megfelelő jogosultságokkal CI/CD-folyamatokhoz, fejlesztői eszközökhöz vagy akár infrastruktúra-elemekhez is hozzáférhetnek.

Ezért az értékelésüknél már nem elég kizárólag azt vizsgálni, mennyire hatékonyan programoznak. Külön mérni kell az offenzív kiberbiztonsági képességeiket is – különösen akkor, ha éles kódbázisokhoz vagy futó rendszerekhez kapnak hozzáférést.

Ezt a szűk, de kritikus képességet vizsgálja az ExploitGym benchmark.

Mi az ExploitGym?

Az ExploitGym egy nagyszabású kiberbiztonsági benchmark, amely azt méri, hogy egy AI ügynök képes-e egy már ismert sérülékenységet működő exploittá továbbfejleszteni.

Módszertani kulcspont: a PoV szerepe

A benchmark nem a sérülékenység önálló felderítésével kezdődik. Az agent megkapja:

– a sérülékeny kódbázist és a buildeléshez szükséges információkat;
– a hibát aktiváló Proof-of-Vulnerability (PoV) bemenetet;
– a sérülékenység szöveges leírását;
– a futtatási környezet adatait.

A benchmark egyes bemeneti elemei konfigurálhatók. A sérülékenységet javító patch rendelkezésre állhat, de az alapértelmezett értékelési beállításban nem érhető el az agent számára.

Az agent feladata, hogy ebből a kiinduló állapotból olyan exploitot építsen, amely jogosulatlan kódfuttatást ér el, majd megszerez egy védett, dinamikusan generált flaget.

A flag megszerzése önmagában még nem feltétlenül jelent sikeres megoldást. Az értékelés azt is ellenőrzi, hogy az agent valóban a feladatban kijelölt sérülékenységet használta-e ki, nem pedig egy másik hibát vagy kerülőutat.

Az exploitfejlesztés többek között alacsony szintű programértelmezést, a memóriaviszonyok és a vezérlésátadás követését, futásidejű alkalmazkodást, valamint hosszabb, több lépésből álló feladatsor végigvitelét igényelheti.

Kik készítették a benchmarkot?

A benchmark módszertanát a UC Berkeley, a Max Planck Institute for Security and Privacy, a UC Santa Barbara és az Arizona State University kutatói dolgozták ki.

A szerzők között az Anthropic, az OpenAI és a Google kutatói is szerepelnek. A tanulmány szerint az iparági partnerek visszajelzést, modell-hozzáférést és egyes kísérletek futtatásához támogatást biztosítottak.

Mit tartalmaz a benchmark?

A kutatási tanulmány 898, valós sérülékenységekből kialakított feladatot vizsgált három területen:

– 520 userspace feladatot, elsősorban nyílt forrású C/C++ projektekből;
– 185 feladatot a V8 JavaScript-motorból;
– 193 Linux kernelhez kapcsolódó feladatot.

Adatmennyiségi pontosítás: a nyilvános 1.0 kiadás

A nyilvánosan közzétett 1.0 kiadás nem teljesen azonos a tanulmányban értékelt adatkészlettel. A projekt hivatalos changelogja szerint a kiadás előtt kiszűrték a nem exploitálható eseteket, így a nyilvános verzió 869 feladatot tartalmaz:

– 502 userspace feladatot;
– 181 V8-feladatot;
– 186 kernelfeladatot.

A tanulmányban közölt eredmények a 898 feladatból álló kutatási mintára vonatkoznak, nem a később közzétett 869 feladatos verzióra.

Milyen környezetben futnak a feladatok?

A feladatokat reprodukálható, izolált értékelési környezetekbe csomagolták. A userspace- és V8-célpontok konténeres környezetben, a kernelcélpontok pedig QEMU/KVM-alapú virtuális gépekben futnak.

A benchmark különböző célrendszeri védelmek hatását is vizsgálja. Ezek közé tartozik:

– userspace környezetben az ASLR, a PIE és a stack canary;
– V8 esetén az ASLR és a V8 heap sandbox;
– a Linux kernelnél a KASLR és a user namespace-ek elérhetősége.

Mit mutattak az eredmények?

A tanulmány szerint az automatizált exploitfejlesztés továbbra is rendkívül nehéz. A legerősebb vizsgált modell–agent párosítások azonban ellenőrzött környezetben már a sérülékenységek számottevő részéből tudtak működő exploitot készíteni.

A fő összehasonlításban:

– a teljes, 898 feladatos kutatási mintát használták;
– a célrendszeri technikai mitigációkat kikapcsolták;
– minden feladatra legfeljebb két óra állt rendelkezésre;
– feladatonként egyetlen, idő- és költségkorlátozott futtatást végeztek;
– a modelleket jóváhagyott trusted-access kutatási programokon keresztül használták.

Ebben a beállításban:

– a Claude Mythos Preview–Claude Code párosítás 157 feladatot oldott meg;
– a GPT‑5.5–Codex CLI párosítás 120 esetben volt sikeres;
– a GPT‑5.4–Codex CLI párosítás 54 feladatot oldott meg.

A számok értelmezésekor fontos, hogy a Mythos Preview módosított instrukciót is kapott egy kiegészítő CLAUDE.md fájlon keresztül. Az eredmények ezért nem tekinthetők olyan tiszta modell-összehasonlításnak, amelyben minden egyéb feltétel teljesen azonos volt.

Két különböző védelmi réteg

Az eredmények értelmezéséhez két eltérő védelmi szintet kell megkülönböztetni.

Modelloldali biztonsági korlátozások

Ezek a szolgáltatók által az inference során alkalmazott biztonsági szűrők, amelyek korlátozhatják, hogy a modell milyen kiberbiztonsági kéréseket hajt végre.

A fő kísérleteket az OpenAI Trusted Access for Cyber és az Anthropic Cyber Verification Program keretében futtatták. Ezekben a jóváhagyott kutatási környezetekben az inference-szintű szolgáltatói korlátozásokat kikapcsolták.

Ez nem jelenti a betanítás és a biztonsági finomhangolás során kialakított visszautasító viselkedés eltávolítását: egyes modellek ilyen környezetben is megtagadtak bizonyos feladatokat.

A GPT‑5.5 alapértelmezett szolgáltatói szűrőinek visszakapcsolásakor az esetek 88,2 százalékában az agent még az első eszközhasználat előtt blokkolódott. A fennmaradó futások eljutottak bizonyos felderítési lépésekig, de nem értek el érdemi előrehaladást az exploitálásban.

Célrendszeri technikai mitigációk

Ezek az operációs rendszer és a futtatókörnyezet védelmi mechanizmusai, például az ASLR, a stack canary, a V8 heap sandbox vagy a KASLR.

A standard mitigációk bekapcsolása jelentősen csökkentette, de nem szüntette meg teljesen az agentek sikerességét. A mitigációkkal újrafuttatott, korábban sikeres feladatok közül az összes vizsgált modell eredményeit együtt számolva 37 userspace-, 20 V8- és 12 kernelfeladat maradt sikeres.

Ezek az eredmények alátámasztják, hogy a célrendszeri védelmek érdemben nehezítik az exploitálást, és támogatják a réteges védelem alkalmazását. A számok nem egyetlen modell teljesítményét, hanem az összes vizsgált modell összesített eredményét jelentik.

Mit mér – és mit nem mér – az ExploitGym?

Az ExploitGym azt vizsgálja, hogy az agent:

– képes-e egy ismert sérülékenységből és PoV-ból exploitláncot építeni;
– tudja-e követni és manipulálni az alacsony szintű futási folyamatokat;
– végig tud-e vinni egy hosszabb, több lépésből álló exploitfejlesztési feladatot;
– képes-e jogosulatlan kódfuttatást elérni a kijelölt sérülékenység felhasználásával;
– hogyan változik a teljesítménye bizonyos memóriavédelmi és sandbox-mechanizmusok bekapcsolásakor.

Az ExploitGym nem méri:

– az agent általános biztonságosságát vagy megbízhatóságát;
– a prompt injection támadásokkal szembeni ellenállását;
– az önálló, nulladik napi sérülékenységek felderítését;
– a biztonságos kódgenerálási képességet;
– a titkok és hitelesítő adatok biztonságos kezelését;
– a teljes vállalati AI kockázatot.

A magasabb ExploitGym-pontszám ezért erősebb exploitálási képességet jelez – nem pedig általánosságban jobb vagy biztonságosabb modellt.

Miért nem elég egyetlen kódolási benchmark?

A SWE-bench és a hozzá hasonló benchmarkok repositoryszintű szoftverfejlesztési feladatokat mérnek: képes-e az agent értelmezni egy hibajegyet, módosítani a kódot és átvinni a teszteket.

Az ExploitGym ettől eltérő kérdést tesz fel: képes-e az agent egy ismert sérülékenységből jogosulatlan kódfuttatáshoz vezető exploitot készíteni?

A két mérés nem helyettesíti egymást.

A magas kódolási benchmarkpontszám önmagában nem bizonyít erős sérülékenységelemzési, biztonságos kódgenerálási vagy exploitálási képességet. Ugyanígy az exploit fejlesztésben elért jó eredmény sem jelenti azt, hogy a modell megbízható biztonsági lektor vagy biztonságos kódgenerátor.

Az AI ügynökök értékeléséhez ezért több különálló dimenzió szükséges:

– fejlesztői produktivitás és kódhelyesség;
– biztonságos kódgenerálás;
– sérülékenységek felismerése;
– exploitálási képesség;
– prompt injection elleni ellenállás;
– jogosultság- és titokkezelés;
– kontrollálhatóság és emberi felügyelet.

Mit jelent ez a fejlesztőcsapatoknak?

Ne egyetlen leaderboard alapján válasszatok modellt

Ha egy modellt kódgenerálásra, security review-ra vagy threat modelingre használtok, az adott feladathoz tartozó értékeléseket vizsgáljátok. A jó általános kódolási teljesítmény önmagában nem bizonyít erős biztonsági képességet.

Az AI által generált kód maradjon a megszokott kontrollok alatt

Az AI használata nem indokolja a statikus alkalmazásbiztonsági tesztelés, a függőségvizsgálat, az automatizált tesztelés vagy az emberi code review elhagyását. Az AI által írt kód ugyanúgy tartalmazhat biztonsági hibákat, mint az ember által készített kód.

Az agent csak a szükséges jogosultságokat kapja meg

A szervezeti kockázatot a modell képességei, az elérhető adatok, az eszközök és a jogosultságok együtt határozzák meg.

Ennek megfelelően:

– alkalmazzátok a legkisebb szükséges jogosultság elvét;
– különítsétek el a fejlesztői, teszt- és éles környezeteket;
– korlátozzátok az agent hálózati hozzáférését;
– minimalizáljátok a hitelesítő adatokhoz és titkokhoz való hozzáférést;
– a kockázatos műveleteket izolált sandboxban futtassátok;
– merge, release és deploy előtt követeljetek meg emberi jóváhagyást;
– naplózzátok az agent műveleteit és eszközhasználatát.

A prompt injectiont külön kockázatként kezeljétek