ما هي؟ Fuzzing Taskflow خطّ اختبار مستقل لمشاريع C/C++ بناه Antonio Morales من GitHub Security Lab، فوق إطار Taskflow Agent الذي يستخدمه الفريق لكتابة أتمتة أمنية يقودها نموذج لغوي. تعطيه اسم مستودع على GitHub، فيقوم بالباقي دون إشراف بشري مستمر.
ماذا تفعل؟
الاختبار بالتشويش (Fuzzing) المستمر ليس حلًا سحريًا، بحسب المقال: حتى المشاريع المسجّلة في OSS-Fuzz منذ سنوات قد تخفي أخطاء حرجة، لأن أحدًا يجب أن يراقب التغطية ويكتب أدوات اختبار للكود الذي لا يصله أحد ويفرز الأعطال. الأداة تحاول تسليم هذا العمل لوكيل:
- تحدّد نقاط الدخول المناسبة وتحلّل نظام البناء.
- تكتب أدوات الاختبار (Harnesses) وتشغّل AFL++.
- تقرأ تقارير التغطية وتحسّن أدوات الاختبار.
- تفرز كل عطل، وتكتب تقرير ثغرة لكل خطأ فريد.
كيف تُستخدم؟
أسهل طريقة فتح مستودع GitHubSecurityLab/seclab-taskflows-fuzzing في Codespace، ثم تشغيل:
./scripts/fuzzing/run_fuzzing.sh tukaani-project/xzولاختبار سريع قبل حملة طويلة، يقترح المقال مشروعًا صغيرًا مثل DaveGamble/cJSON.
التصميم
ثلاث طبقات: سكربت shell يربط المراحل، وملفات YAML لكل مرحلة هي فعليًا التعليمات للوكيل، وأدوات MCP ينفّذ بها الوكيل العمل، مثل تشغيل AFL وتجميع أداة الاختبار وتخزين العطل. والقاعدة الأهمّ لدى المطوّر: الوكيل يملك القرارات، والأدوات تملك التنفيذ. الوكيل يقرّر ماذا يختبر وأي فجوة تغطية يطارد، لكنه لا يستدعي AFL أو المترجم مباشرة.
ويستخدم المشروع افتراضيًا نموذج Claude Sonnet 5 لأنه اجتاز كل الاختبارات الداخلية للفريق، مع إمكانية تغييره في ملف إعدادات النموذج. ويذكر المقال أن بعض النماذج الرائدة تضع قيودًا أمنية على مخرجاتها قد تعيق هذه المهمّة.
حدود وتحذيرات
التحذير في المقال صريح: الأداة تشغّل afl-fuzz وclang وأوامر بناء يختارها النموذج مباشرة على الجهاز، دون حاوية. وكيل تعرّض لحقن أوامر يستطيع نظريًا فعل أي شيء يستطيعه مستخدمك. لذلك شغّلها فقط في بيئة مؤقّتة يمكن التخلّص منها، مثل Codespace أو آلة افتراضية، ودون صلاحيات مرتفعة.
لمن تناسب؟
للباحثين الأمنيين ومشرفي مشاريع C/C++ المفتوحة الذين يريدون تغطية أوسع بالتشويش دون كتابة أدوات الاختبار يدويًا. وتناسب من هو مستعدّ لمراجعة تقارير الثغرات قبل الإبلاغ عنها، فالمخرجات ما زالت من إنتاج وكيل.
المصادر: GitHub Blog — 2026-09-24
