· kaynak GitHub Blog
GitHub Security Lab'ın Taskflow Agent'ı, fuzzing kampanyalarını harness'ten hata raporuna kadar yürütüyor
GitHub, LLM destekli güvenlik otomasyonu için geliştirdiği Taskflow Agent çerçevesini kullanan ve C/C++ depoları için fuzz hedeflerini özerk biçimde seçen, harness yazan, AFL++ çalıştıran ve çökmeleri ayrıştıran bir Fuzzing Taskflow'u açık kaynak olarak yayımladı.

Fuzzing'deki insan boşluğunu kapatmak
GitHub'un Security Lab ekibi, LLM destekli güvenlik otomasyonu için geliştirdiği Taskflow Agent çerçevesi üzerine kurulu, C ve C++ projeleri için özerk bir fuzzing pipeline'ı olan bir Fuzzing Taskflow yayımladı. GitHub Blog'a göre pipeline'ı bir GitHub deposuna yönlendirmeniz yeterli; gerisini o hallediyor: uygun giriş noktalarını belirliyor, build sistemini analiz ediyor, fuzz harness'leri yazıyor, AFL++ çalıştırıyor, kapsam raporlarını okuyor, harness'leri iyileştiriyor, her çökmeyi ayrıştırıyor ve insan müdahalesi olmadan her benzersiz hata için bir güvenlik açığı raporu yazıyor.
Yazı bir gözlemden yola çıkıyor: sürekli fuzzing kendi kendini idame ettiren bir süreç değil. Yıllardır OSS-Fuzz'a kayıtlı projeler bile kritik hataları gizleyebiliyor, çünkü kapsamı izleyen, kimsenin ulaşmadığı kod için harness yazan ve çökmeleri ayrıştıran birilerinin olması hâlâ gerekiyor. Bu taskflow, bu işin ne kadarını bir LLM agent'ın devralabileceğine dair bir deneydir.
Çalıştırma
Kod GitHubSecurityLab/seclab-taskflows-fuzzing deposunda yer alıyor ve en basit yol bir Codespace. Tek bir script bir kampanyayı yürütüyor ve argüman olarak bir owner/repo ifadesi alıyor:
./scripts/fuzzing/run_fuzzing.sh PROJECT
Yazıda örnek olarak tukaani-project/xz kullanılıyor ve hızlı bir smoke test için DaveGamble/cJSON gibi küçük bir kütüphane öneriliyor. Agent ihtiyaç duyduğu her şeyi (AFL dahil) kuruyor, depoyu klonluyor, en ilgili fonksiyonları seçiyor ve bunlar için fuzz hedefleri oluşturuyor.
Öne çıkan bir uyarı var: taskflow, afl-fuzz, clang ve LLM'nin seçtiği rastgele build komutlarını arada bir container olmadan doğrudan host üzerinde çalıştırıyor; dolayısıyla bir prompt injection'a maruz kalan agent kullanıcının yapabileceği her şeyi yapabilir. GitHub, bunun yalnızca genişletilmiş yetkiler olmadan, atılabilir bir ortamda çalıştırılmasını öneriyor.
Mimari ve model seçimi
Pipeline üç katmandan oluşuyor: aşamaları zincirleyen bir shell sürücüsü, her aşama için bir taskflow YAML dosyası (özünde agent'a o adımda ne yapacağını söyleyen prompt) ve gerçek işi yapan bir dizi MCP aracı; örneğin AFL çalıştırmak, bir harness derlemek, bir çökme kaydetmek veya bir kapsam raporu okumak.
Temel tasarım kuralı sorumlulukların ayrılması: kararlar agent'a, yürütme araçlara aittir. Agent AFL'yi veya clang'i asla doğrudan çağırmaz; bunun yerine run_afl_for ve compile_harness gibi ilkel öğeleri birleştirir. Tüm durum bir SQLite veritabanında, fuzz_context.db içinde tutulur; böylece aşamalar veriyi yalnızca bellekte değil, veritabanı üzerinden paylaşır.
Varsayılan model Claude Sonnet 5'tir; GitHub'un dahili testlerini sorunsuz geçtiği için seçilmiştir; bazı frontier modeller ise sürece müdahale eden çıktı kısıtlamaları getiriyor. Pipeline'ın model_config.yaml dosyasından başka bir model ayarlanabilir.
Kapsam geri bildirim döngüsü
Manuel kapsam-iyileştirme iş akışını otomatikleştiren kısım burasıdır. Her harness için bir yineleme, AFL'yi bir süre bütçesi dahilinde çalıştırır, elde edilen kuyruğu kapsam enstrümantasyonlu bir binary'ye karşı yeniden oynatır ve kapsanmayan dalları okur. Agent ardından bir eylem seçer: kapsanmayan bir dala ulaşmak için özel olarak hazırlanmış bir seed eklemek, ek bir API'yi çağırmak için harness kaynak kodunu düzenlemek, bir guard'ın karşılaştırdığı magic constant'larla AFL sözlüğünü zenginleştirmek ya da boşluk soğuk bir hata yolu veya vendor kodu olduğunda atlamak.
Süre bütçeleri her yinelemede iki katına çıkar: 30 saniyeden 960 saniyeye, hedef başına kabaca 32 dakikaya kadar. Böylece ucuz erken turlar kolayca alınabilecek kapsamı toplarken, sonraki turlar zorlu guard'ları aşmak için zamana kavuşur. Durdurma, plato tespitine dayanır: art arda iki yineleme de yapılandırılabilir bir eşiğin (varsayılan olarak mutlak %1 satır kapsamı) altında kazanım sağladığında döngü devam eder.
Her harness ayrıca iki kez derlenir. afl-clang-lto ile ve address ile undefined sanitizer'larıyla derlenen bir .afl binary'si fuzzing'i yaparken, Clang'in kapsam bayraklarıyla derlenen bir .cov binary'si, AFL'nin kenar enstrümantasyonu insanlara yönelik raporlar için işe yaramadığından, AFL'nin kuyruğunu sonradan oynatıp okunabilir kaynak satırı ve dal kapsamı üretir.
Yapı duyarlı girdiler
AFL'nin bayt düzeyindeki mutasyonları ikili formatlara uyar ama yapılandırılmış, metin tabanlı girdilerde zorlanır ve her format için özel mutator'ları elle yazmak yorucudur. Taskflow dört mekanizmayla gelir. JSON, XML, regex, PNG ve uzunluk önekli ikili TLV dahil tanınan formatlar için önceden hazırlanmış sözlükler ve LLVMFuzzerCustomMutator dosyaları sağlar: JSON mutator'u token birleştirme ve dengeli parantez çoğaltma yapar, XML mutator'u tag'leri, entity'leri ve billion-laughs token'larını bilir, regex mutator'u ise gerçek ReDoS kalıpları taşır. Her biri, motorun rastgeleliğini korumak için mutasyonlarının yarısını AFL'nin bayt mutator'una devreder. Tanımadığı formatlar için ise hedefin kendi C kaynak kodunu string literal'ler ve #define, case ve enum bildirimlerinden gelen 32 bit sabitler için tarar; mantık şu ki bir parser'ın magic değerleri genellikle kendi kodunda yazılıdır. Bir diğer mekanizma ise kapsam tarafından yönlendirilen bir AFL sözlüğünü dinamik olarak oluşturur.
Neden önemli
Fuzzing, bellek güvenliği hatalarını bulmanın en yüksek değerli yollarından biridir ama aynı zamanda en emek yoğun olanlarından biridir; çünkü yetenekli insanların harness yazmasına ve çökmeleri ayrıştırmasına bağlıdır. Taskflow, bir LLM agent'ın bu döngüyü — hedefleri seçmeyi, kapsam üzerinde yinelemeyi ve hata başına raporlar üretmeyi — kararları agent'ta ve yürütmeyi sınırlı araçlarda tutan bir mimari içinde özümseyebildiğinin çalışan bir gösterimidir. Uyarılar gerçektir: LLM'nin seçtiği build komutlarını doğrudan host üzerinde yürüttüğü için atılabilir bir ortam zorunludur ve raporları hâlâ insan incelemesini hak eder. Yine de C ve C++ bakımcıları için kendi harness'lerini yazıp iyileştiren bir kampanya, yıllarca süren sürekli fuzzing'in gözünden kaçan hataları bulmanın maliyetini ciddi biçimde düşürebilir.
- #fuzzing
- #security
- #llm-agents
- #github
- #open-source