Peneliti GitHub Security Lab, Antonio Morales, mempublikasikan tulisan pada 24 September yang memperkenalkan pipeline fuzzing berbasis large language model (LLM) untuk proyek C/C++. Kodenya ada di repositori GitHub seclab-taskflows-fuzzing, dengan model default Claude Sonnet 5.
Pipeline ini dibangun di atas framework Taskflow Agent milik GitHub sendiri, yang oleh perusahaan didefinisikan sebagai “framework untuk menulis otomatisasi keamanan berbasis LLM”. Pengguna cukup membuka Codespace di repositori, menjalankan satu baris skrip diikuti nama proyek target — misalnya tukaani-project/xz — dan sisanya ditangani oleh agent.
Dari Mencari Entry Point sampai Menulis Laporan
Menurut tulisan tersebut, pipeline ini bekerja secara berurutan: mengidentifikasi entry point kode, menulis test harness secara otomatis, memanggil AFL++ untuk menjalankan fuzzing, membaca laporan cakupan (coverage), menulis ulang harness berdasarkan cakupan, mengklasifikasikan setiap crash, dan akhirnya menghasilkan laporan kerentanan lengkap dengan saran patch dalam format unified diff.
Feedback cakupan menggunakan skema penggandaan anggaran waktu: setiap putaran mendapat waktu dua kali lipat dari putaran sebelumnya, dimulai dari 30 detik lalu berturut-turut 60, 120, 240, 480, 960 detik, dengan total kumulatif sekitar 32 menit per target. Agent memeriksa cakupan setiap akhir putaran sebelum memutuskan apa yang perlu diubah.
Agar mutasi acak lebih memahami format input, pipeline ini menumpuk empat lapis teknik "structure-aware": kamus khusus format file dan mutator kustom, kamus yang diekstrak dari source code, kamus AFL yang dibuat secara dinamis selama proses berjalan, serta penggabungan corpus.
Label klasifikasi crash dibuat cukup rinci: kerentanan nyata (vulnerability), saran penguatan library (library_hardening), bug pada harness itu sendiri (harness_bug), kehabisan memori, timeout, assertion failure, dan duplikat. Crash lebih dulu diminimalkan dengan afl-tmin, lalu dideduplikasi berdasarkan call stack. Selama proses berjalan, ada dashboard HTML di port 8765 yang menampilkan progres secara real-time.
Morales merangkum pembagian tugas di balik desain ini:
"the LLM agent owns the decisions, and the MCP tools own the execution"
(keputusan dipegang agent LLM, eksekusi dipegang tool MCP)
Dibandingkan dengan Jalur OSS-Fuzz
Google lebih dulu menggarap area ini. OSS-Fuzz sudah mencoba menggunakan LLM untuk menghasilkan fuzz target secara otomatis sejak 2023, dan Google menyatakan pada akhir 2024 bahwa pendekatan ini membantu menemukan sejumlah masalah, termasuk satu kerentanan di OpenSSL. Namun pendekatan itu terutama menyelesaikan langkah "menulis harness", dan proyek harus lebih dulu terintegrasi dengan infrastruktur OSS-Fuzz.
Pendekatan GitHub kali ini lebih mirip toolbox portabel: proyek tidak perlu mendaftar ke platform apa pun, cukup buka satu lingkungan pengembangan cloud untuk menjalankannya, dan triase serta penulisan laporan juga sudah termasuk di dalamnya. Di awal tulisan, ditekankan bahwa fuzzing berkelanjutan bukan solusi ajaib — proyek yang sudah bertahun-tahun berada di OSS-Fuzz tetap bisa menyimpan bug serius, dan ini jadi salah satu alasan mereka memilih xz sebagai demo. xz sempat jadi pusat insiden backdoor pada 2024 yang mengguncang komunitas open source, tetapi itu adalah kasus peracunan rantai pasok (supply chain), berbeda kategori dari bug memori yang bisa ditemukan fuzzing.
Bagian yang Tidak Diungkap Tulisan Ini
Beberapa angka yang paling ingin diketahui publik tidak diungkapkan: berapa jumlah crash yang ditemukan masing-masing di xz dan cJSON, berapa di antaranya dinilai sebagai kerentanan nyata, apakah ada CVE yang diberikan; konsumsi token dan biaya untuk menjalankan satu proyek; serta tingkat false positive. Gaya bahasa Morales sendiri cukup hati-hati — ia menulis bahwa kesimpulan triase sebaiknya dilihat sebagai “titik awal yang sudah disiapkan dengan baik untuk diserahkan ke manusia”, bukan hasil akhir, dan saran patch pun semuanya ditandai perlu ditinjau manusia.
Ada juga prasyarat dari sisi keamanan. Pipeline ini berjalan tanpa isolasi container, dan panduan resmi menyarankan agar hanya dijalankan di lingkungan yang bisa dibuang seperti Codespace atau VM sementara, serta tidak diberi hak akses tinggi. Tim yang ingin menerapkannya langsung di jaringan internal perusahaan akan menabrak batasan ini lebih dulu, bahkan sebelum sampai ke pemilihan model.
Bagi pengelola pustaka open source dasar di Tiongkok daratan, hambatan utamanya ada pada model: konfigurasi default memanggil model Anthropic, sementara akses langsung dari Tiongkok tidak mudah. Repositori ini open source, sehingga secara teori bisa diganti dengan model kompatibel lain, tetapi belum ada pengujian publik apakah hasilnya tetap setara.
Sumber: blog resmi GitHub, dokumentasi repositori open source seclab-taskflows-fuzzing, CocoLoop, materi publik Google OSS-Fuzz; langkah pipeline, anggaran waktu, dan klasifikasi crash mengikuti deskripsi blog GitHub.