BigSleep المعتمد على LLM يعثر على 45 ثغرة في V8 مقابل 37 لـ Fuzzilli، والتداخل بينهما 25%

خلال ستة أشهر، من أبريل إلى سبتمبر 2026، عثر وكيل LLM المسمى BigSleep على 45 ثغرة فعلية في V8، بينما عثر الفاحص العشوائي التوليدي Fuzzilli على 37. وتستخدم Google الأداتين معًا في بيئة الإنتاج لفحص الشيفرة الجديدة في محرّك JavaScript الخاص بمتصفح Chrome. وقارن فريق Project Zero بين نتائجهما وخرج باستنتاجين. الأول أن التداخل بين ما وجدته الأداتان محدود: نحو 25% بحسب متتبّع الأخطاء (20 من 81 بلاغًا فعليًا). أما في تجربة أُعيد بناؤها على أخطاء تاريخية فوصل التداخل إلى نحو 60%. والثاني أن جزءًا كبيرًا من الثغرات يعثر عليه أحد النهجين فقط.

كيف تحوّلت 441 بلاغًا إلى 45 ثغرة

يمنح الإحصاء الخام استنادًا إلى hotlists متتبّع أخطاء Chromium أفضلية طفيفة لـ BigSleep: 441 بلاغًا مقابل 316 لـ Fuzzilli. لكن BigSleep وجد في بدايته كثيرًا من مشكلات الإعدادات والتكامل، ومنها مثلًا عدم عمل حظر الأعلام (flags) غير الآمنة (crbug.com/503869331). وهذه الأخطاء لا تكاد تؤثر فعليًا في الأمان.

وإذا اقتصر العدّ على type:vulnerability، انقلبت الصورة: 178 بلاغًا لـ Fuzzilli و95 لـ BigSleep. غير أن هذا الرقم أيضًا مضخّم. فبعض البلاغات مكرّرة، وبعضها أُغلق بوصفه WAI («يعمل كما صُمّم»). كما أن الاكتفاء بتصفية الحالات بحسب الحالة fixed لا يحل المشكلة. فمثلًا، أنشأ Clusterfuzz بلاغ Fuzzilli رقم crbug.com/511935486 وأغلقه في اليوم نفسه، لأن حالة الاختبار (testcase) لم تعد قابلة لإعادة الإنتاج. وهو شبه مؤكد مكرّر لـ crbug.com/511210507، لكن بصمة الانهيار بحسب stack trace اختلفت قليلًا، فلم يدمج النظام البلاغين. ولم يتعامل أي مهندس مع هذا الخطأ.

لذلك احتُسبت البلاغات «الفعلية» فقط: غير المكرّرة، وغير المغلقة بوصف WAI، ولها commit إصلاح واحد على الأقل. وبالنسبة إلى النوع Type-Vuln كانت النتيجة 45 مقابل 37 لصالح BigSleep.

التداخل: الربع في المتتبّع ونحو 60% في التجربة

لحساب النتائج المشتركة، أُزيلت التكرارات بين الأخطاء في أربع خطوات:

• التكرارات الصريحة، حين يُصنَّف بلاغ نظام ما مكرّرًا لبلاغ نظام آخر، كما في crbug.com/522410841 وcrbug.com/522860268؛ • التكرارات الضمنية، حيث يُبحث عن commit الإصلاح للبلاغات «غير الفعلية» وتُدمج الأخطاء المرتبطة به. وقد تكون العلاقة متعددة الأطراف: خطأ BigSleep وخطأ Fuzzilli كلاهما مكرّر لخطأ ثالث؛ • التكرارات الواردة من قاعدة Clusterfuzz والتي لم تصل إلى المتتبّع؛ • الأخطاء المختلفة التي أُغلقت بـ CL واحد (مثل أربعة أخطاء في crrev.com/c/7965120) تُعدّ هي الأخرى مكرّرة.

النتيجة: 20 خطأً مشتركًا من أصل 81، وكان Fuzzilli أول من عثر على أكثر من نصفها بقليل.

يقلّل هذا الحساب من حجم التداخل، ولذلك أُجريت تجربة. أُخذ نحو 1150 خطأً تاريخيًا من أخطاء Fuzzilli بين عام 2023 ومنتصف 2026. وبقي منها نحو 600 ثغرة، ثم 132 خطأً قابلًا لإعادة الإنتاج في بناء d8 العام من نوع debug+asan على x64 دون أعلام خاصة. وبعد إزالة التكرارات بقي 112 خطأً. وعُثر لكل خطأ على commit المُسبِّب المرجَّح، وذلك في الغالب بالبحث الثنائي (bisection). ثم شُغّل الوكيل 25 مرة بمهمة البحث عن الأخطاء في هذا الـ commit وتأكيدها بحالة اختبار تُسقط البناء. وبذلك بلغ المجموع 2800 تشغيل على إعدادات BigSleep الإنتاجية في ذلك الوقت، مع نموذج Gemini 3.6 flash.

النتيجة: أُعيد اكتشاف نحو 62% من الأخطاء الأصلية، وأفضى نحو 12% من الـ commits إلى خطأ آخر سبق إصلاحه، ولم يُعثر على شيء في 26%. وهذا الإعداد غير منصف للوكيل عمدًا: فقد يكون الـ commit حُدّد خطأً، وقد يُلتقط الخطأ فعليًا عبر commit لاحق في الشيفرة نفسها.

الحفظ والصعوبة وما يبقى للفاحص العشوائي

جرى فحص منفصل لمعرفة ما إذا كان النموذج يستذكر أخطاءً من بيانات التدريب. فتاريخ القطع المعرفي لـ Gemini 3.6 flash هو مارس 2026. وكانت أخطاء Chrome تُتاح للعامة آنذاك بعد نحو ثلاثة أشهر، لذا يقع القطع الفعلي لأخطاء Fuzzilli في يناير 2026. ولم يُرصد حفظ ذو دلالة إحصائية في الأخطاء السابقة لعام 2026. أما بالنسبة إلى النماذج الأخرى فينبغي تكرار هذا الفحص.

وبالنسبة إلى «صعوبة» الخطأ، أي الزمن الذي استغرقه Fuzzilli للعثور عليه، فالعلاقة ذات دلالة إحصائية وإن كانت ضعيفة من حيث الحجم. ويأتي اتجاهها معاكسًا للسيناريو المثالي الذي يلتقط فيه LLM بسهولة ما يصعب على الفاحص العشوائي، فيمكن عندئذ إعادة توزيع ميزانية الفحص العشوائي.

ولم تُجرَ التجربة العكسية (البحث بالفاحص العشوائي عن أخطاء BigSleep السابقة). فلا يمكن توجيه الفاحص العشوائي إلى commit محدد بالسهولة نفسها. يضاف إلى ذلك أن معظم أخطاء BigSleep القديمة عُثر عليها بعد أشهر أو سنوات من فحص البناءات المعرّضة للثغرات. وفي بيئة الإنتاج يتمتع الفاحص العشوائي أصلًا بأفضلية زمنية: إذ يعمل BigSleep مرة واحدة يوميًا ويبلّغ عن الانهيارات بتأخير يوم إلى يومين.

ما ينبغي لفرق الأمان فعله عمليًا

لا يمكن حتى الآن مقارنة تكلفة العثور على الخطأ. فقد جرى تحسين Clusterfuzz على مدى سنوات، بينما لم يُبذل جهد مماثل في BigSleep، ولم يُضبط سعر الخطأ الواحد في أي من النظامين.

خلاصات المنهجية:

• شغّلوا الفحص العشوائي والتحليل الوكيلي معًا: فلكل منهما «نقاط عمياء» مختلفة بوضوح؛ • زوّدوا الوكيل بـ diff لـ commit محدد واطلبوا منه PoC. والتوقف عند أول انهيار يحدّ من استهلاك الرموز (tokens)؛ • تحققوا من PoC على البناءات قبل الإصلاح وبعده، لتمييز الخطأ المطلوب عن خطأ آخر؛ • استخدموا بناءات sanitizer ووضع «الأعلام الآمنة فقط»؛ • احسبوا المقاييس من البلاغات الفعلية ذات commit الإصلاح فقط، وأزيلوا تكراراتها مع Clusterfuzz؛ • عند التقييم على أخطاء تاريخية، قارنوا نسبة النجاح قبل تاريخ القطع المعرفي للنموذج وبعده، لاستبعاد أثر الحفظ.