A GitHub ügynöke önállóan épít fuzzingfolyamatot C és C++ projektekhez

A Taskflow Agent végigviszi a fuzzingfolyamatot

A GitHub szeptember 24-i bejegyzése szerint a Fuzzing Taskflow C és C++ projektekhez készült autonóm fuzzingfolyamat. A felhasználónak egy GitHub-tárhelyet kell megadnia, a rendszer pedig telepíti a szükséges szoftvereket, klónozza a kódot, azonosítja a releváns függvényeket, elkészíti a fuzzing célpontokat, majd futtatja az AFL++ eszközt.

A folyamat a lefedettségi jelentéseket is feldolgozza, szükség esetén módosítja a tesztelő kódot, osztályozza az összeomlásokat, és minden egyedi hibához sérülékenységi jelentést készít. A GitHub szerint a folyamatos fuzzing önmagában nem old meg minden problémát, mivel a lefedettséget továbbra is figyelni kell, új tesztelő kódokat kell írni, a hibákat pedig elemezni kell. A Fuzzing Taskflow ezt a munkát egy LLM-ügynökre bízza.

GitHub Codespace-ből is elindítható

A legegyszerűbb használathoz a GitHub Security Lab seclab-taskflows-fuzzing tárházából kell Codespace-t indítani, majd lefuttatni a ./scripts/fuzzing/run_fuzzing.sh PROJECT parancsot. A PROJECT helyén a GitHub tulajdonos és tárház azonosítója szerepel, például tukaani-project/xz. Gyors próbaként a bejegyzés a DaveGamble/cJSON projektet javasolja.

A GitHub külön biztonsági figyelmeztetést is közzétett. A folyamat közvetlenül a gazdagépen futtatja az afl-fuzz, a clang és az LLM által kiválasztott buildparancsokat, konténer használata nélkül. Egy promptinjektált ügynök elméletben bármit végrehajthat, amit az adott felhasználó. Ezért a GitHub eldobható környezetet, például Codespace-t vagy ideiglenes virtuális gépet, valamint emelt jogosultságok nélküli futtatást javasol.

Az alapértelmezett modell a Claude Sonnet 5, amely a GitHub szerint megfelelt a belső teszteken. Másik modell a src/seclab_taskflows_fuzzing/configs/model_config.yaml fájl módosításával választható.

Lefedettség alapján javítja a tesztelést

A rendszer három fő rétegből áll: egy shell-vezérlőből, szakaszonkénti Taskflow YAML-fájlokból és MCP-eszközökből. Az ügynök dönti el, mit kell tesztelni, milyen harness, vagyis fuzzing célpont készüljön, és melyik lefedettségi hiányt érdemes következőként megcélozni. Az MCP-eszközök hajtják végre például az AFL futtatását, a fordítást, a hibák tárolását és a lefedettségi jelentés beolvasását. Az állapotot a fuzz_context.db SQLite-adatbázis tárolja.

Minden harness két bináris formában készül el. Az .afl bináris a fuzzingot végzi, az .cov bináris pedig az AFL várólistáját játssza vissza, hogy forrásszintű sor- és ág-lefedettség legyen mérhető. Az ügynök ezután új magbemenetet adhat hozzá, módosíthatja a harness kódját, automatikusan bővítheti az AFL szótárát, vagy kihagyhatja az adott hiányt, ha az hideg hibakezelési útvonalhoz vagy külső kódhoz tartozik.

Az időkeretek iterációnként duplázódnak: 30, 60, 120, 240, 480, majd 960 másodperc. A folyamat alapértelmezés szerint akkor áll tovább, ha két egymást követő iteráció kevesebb mint 1 százalékpontos abszolút sor-lefedettségi javulást hoz.

Strukturált bemenetek és tartós tesztelési korpusz

A byte-szintű AFL-mutátorok a bináris formátumoknál hatékonyak, a strukturált szöveges bemeneteknél viszont nehezebben boldogulnak. A Taskflow ezért előre elkészített szótárakat és egyedi mutátorokat kínál JSON, XML, reguláris kifejezések, PNG és hosszmezős bináris TLV formátumokhoz. Ismeretlen formátumoknál a rendszer a projekt C és headerfájljait vizsgálja, és karakterláncokat, valamint a #define, case és enum elemekből származó 32 bites számokat használ fel.

A lefedettség alapján az ügynök újabb, a kódban vizsgált értékeket is hozzáadhat a szótárhoz. A corpus-splice művelet meglévő bemenetek részleteit is beillesztheti az új tesztekbe. A harness-ekhez tartozó tartós korpusz az iterációk és a teljes kampányok között is megmarad, az AFL várólistáját pedig minden iteráció végén egyesítik és az afl-cmin eszközzel méretkorlátozzák. Így az újraindított kampányok megtarthatják a korábban talált érdekes bemeneteket.