قدّم GitHub Security Lab شرحاً لمسار مفتوح المصدر باسم Fuzzing Taskflow، صُمم لأتمتة أجزاء كبيرة من اختبار مشاريع C/C++ باستخدام التنقيح الضبابي (fuzzing) ووكلاء نماذج اللغة. ويستطيع المسار، عند توجيهه إلى مستودع GitHub، تحليل نظام البناء، تحديد نقاط الدخول المناسبة، إنشاء أدوات fuzz harnesses، تشغيل AFL++، قراءة تقارير التغطية، تحسين الأدوات، وفرز الأعطال وإعداد تقرير منفصل لكل مشكلة محتملة.
المشروع مبني فوق إطار GitHub Security Lab Taskflow Agent، الذي يعبّر عن سير العمل على هيئة مجموعة من المسارات تنفذها الوكالة من البداية إلى النهاية. ويشير كاتب المادة، Antonio Morales، إلى أن الهدف ليس إلغاء دور الباحث، بل نقل الأعمال المتكررة التي تستهلك وقتاً كبيراً إلى الوكيل، مع إبقاء القرارات والتنفيذ في طبقتين منفصلتين.
كيف يعمل المسار؟
يبدأ الاستخدام من مستودع المشروع، عبر تشغيل الأمر ./scripts/fuzzing/run_fuzzing.sh PROJECT داخل Codespace مثلاً. يتولى المسار تثبيت الأدوات، واستنساخ المستودع، وتحليل الوظائف المهمة، ثم إنشاء أهداف fuzzing وتشغيل الحملات عليها. وتتكون بنيته من مشغل shell، وملفات YAML تصف مراحل العمل والتعليمات الموجهة إلى النموذج، وأدوات MCP تنفذ عمليات مثل تشغيل AFL، وترجمة الأدوات، وقراءة التغطية، وتخزين الأعطال.
لا يستدعي الوكيل AFL أو clang مباشرة؛ فهو يقرر ما الذي ينبغي اختباره وأي فجوة في التغطية تستحق المتابعة، بينما تنفذ أدوات MCP العمليات منخفضة المستوى. وتخزن الحالة في قاعدة SQLite باسم fuzz_context.db، ما يسمح بتمرير النتائج بين المراحل دون الاعتماد على الذاكرة المشتركة.
حلقة تحسين التغطية
يبني كل harness مرتين: نسخة .afl لتوجيه AFL باستخدام أدوات التهيئة المناسبة، ونسخة .cov لإعادة تشغيل قائمة المدخلات وقياس تغطية الأسطر والفروع. بعد كل جولة، يراجع الوكيل الفروع غير المغطاة، ثم يختار إجراءً مثل إضافة seed جديد، أو تعديل مصدر harness لاستدعاء واجهة أخرى، أو إثراء قاموس AFL بالقيم التي تتحقق منها الشيفرة، أو تجاهل مسار بارد لا يستحق التكلفة.
تتضاعف ميزانية الوقت من 30 ثم 60 و120 و240 و480 إلى 960 ثانية، أي نحو 32 دقيقة لكل هدف في الحد الأقصى المذكور. ويتوقف المسار عند رصد تراجع العائد: إذا حققت جولتان متتاليتان أقل من نقطة مئوية واحدة من تغطية الأسطر، وفق القيمة الافتراضية القابلة للضبط، ينتقل إلى هدف آخر.
التعامل مع المدخلات والأعطال
يدعم المسار آليات مخصصة لصيغ JSON وXML والتعبيرات النمطية وPNG وTLV الثنائي ذي الأطوال المضمنة، كما يستطيع توليد قاموس من ثوابت السلاسل والأرقام الموجودة في ملفات C وH. ويُثري هذا القاموس بعد كل خطوة تغطية اعتماداً على الحواجز القريبة من الأسطر غير المغطاة. كذلك يحتفظ كل harness بمجلد corpus ثابت، ويستخدم afl-cmin للحد من حجمه مع إبقاء المدخلات المفيدة بين الجولات والحملات.
بعد انتهاء الحملة، تُصغّر الأعطال باستخدام afl-tmin، وتُعاد تحت AddressSanitizer، ثم تُزال التكرارات اعتماداً على بصمة أعلى المكدس. كما يعيد المسار اختبار الأعطال المعروفة للتحقق من أثر الإصلاحات، ويصنف النتائج ضمن فئات تشمل: ثغرة، أو تقوية للمكتبة، أو خطأ في harness، أو نفاد ذاكرة، أو مهلة، أو فشل assertion، أو تكرار.
لماذا يهم هذا الخبر؟
القيمة العملية هنا أن المسار يحاول أتمتة الحلقة التي غالباً ما تحد من فاعلية fuzzing المستمر: كتابة harnesses، قراءة التغطية، اختيار الفجوة التالية، وفرز الأعطال. وهذا قد يخفض كلفة بدء اختبار مشروع لم يخضع للتنقيح الضبابي سابقاً، أو يساعد في توسيع تغطية مشروع قائم.
لكن GitHub Security Lab يضع قيداً جوهرياً: المسار يشغل afl-fuzz وclang وأوامر بناء يختارها النموذج مباشرة على النظام المضيف، من دون حاوية فاصلة. لذلك قد يؤدي وكيل متأثر بحقن التعليمات إلى تنفيذ ما يستطيع المستخدم تنفيذه. يوصي المشروع بتشغيله داخل بيئة قابلة للتخلص، مثل Codespace أو آلة افتراضية مؤقتة، ومن دون صلاحيات مرتفعة.
كما أن تقارير الثغرات والتصحيحات المقترحة ليست نتائج نهائية. فالمادة تؤكد أن تحليل النموذج قد يخطئ، وأن الرقعة المقترحة موسومة بضرورة المراجعة. وبذلك يمثل Fuzzing Taskflow نقطة انطلاق معدة جيداً للباحث، لا بديلاً عن التحقق البشري من قابلية الوصول والاستغلال والسبب الجذري.
كيف أعددنا هذا الخبر؟
اعتمد الخبر على المصدر الأصلي الموضح أعلاه. قد نستخدم أدوات آلية للمساعدة في الاستخراج والتصنيف والصياغة،
لكن النشر يخضع لقواعد تمنع المحتوى المكرر والقصير أو الروتيني منخفض القيمة.
اقرأ سياستنا التحريرية.