Google توقف مكافآت الثغرات: حين يُغرق الذكاء الاصطناعي المراجعين ببلاغات مزيّفة

في الأول من أكتوبر 2026 أعلنت جوجل أنها لم تعد تقبل بلاغات الثغرات الجديدة في المنتجات عبر برنامج مكافآت الثغرات لمشاريع المصدر المفتوح (OSS VRP). السبب الذي ذكرته الشركة صريح: ارتفاع كبير في البلاغات الآلية، وأغلبها غير صالح. المفارقة أن أدوات الذكاء الاصطناعي التي وعدت بتسريع اكتشاف الثغرات صارت هي نفسها ما يُغرق المراجعين ببلاغات تبدو متقنة ولا أساس لها.

الخبر أكبر من برنامج واحد. إنه اختبار مبكر لسؤال سيواجهه كل مشروع مفتوح المصدر: ماذا نفعل حين يصبح إنتاج البلاغات شبه مجاني، بينما يبقى فحصها مكلفاً؟

ما الذي حدث بالضبط؟

وفق ما نشرته صفحة قواعد البرنامج، توقف استقبال بلاغات ثغرات المنتجات اعتباراً من 1 أكتوبر 2026. ولم تتأثر بلاغات سلسلة التوريد (Supply Chain) ولا البلاغات المعلّقة أصلاً، كما بقيت برامج المكافآت الأخرى لدى جوجل مفتوحة. وقالت الشركة إنها ستقدّم تحديثاً جديداً في الربع الأول من 2027.

النقاط الأساسية:

• التوقف جزئي لا كلي: المتأثر هو مسار ثغرات المنتجات فقط.
• السبب: موجة من البلاغات المولَّدة آلياً، أغلبها غير صالح.
• الحافز قوي: المكافآت تتراوح بين 500 دولار وأكثر من 30 ألف دولار بحسب شدة الثغرة وفئة المشروع.
• موعد المراجعة: تحديث متوقع في الربع الأول من 2027.

لماذا يُغرق الذكاء الاصطناعي المراجعين؟

اقتصاديات غير متكافئة

كتابة بلاغ يبدو احترافياً صارت تستغرق ثواني: وصف للثغرة، وخطوات إعادة إنتاج، وتقدير للخطورة، بلغة منمّقة. أما التحقق منه فيتطلب مهندساً يقرأ الكود ويشغّل الحالة ويثبت أن الادعاء صحيح أو خاطئ. هذا التفاوت بين كلفة الإنتاج وكلفة الفحص هو لبّ المشكلة.

بلاغات مقنعة شكلاً فارغة مضموناً

الخطر ليس في البلاغ الركيك، فهذا يُرفض بسرعة. الخطر في البلاغ المصقول الذي يذكر شروط تشغيل غير صحيحة، أو يصف مسار استغلال لا وجود له في الكود الفعلي. المراجع هنا لا يستطيع الرفض بنظرة؛ عليه أن يبرهن بطلان كل ادعاء، وكل ادعاء كاذب قد يكلّف وقتاً يعادل ادعاءً صحيحاً.

الحافز المالي يضاعف الأثر

حين تصل المكافأة إلى آلاف الدولارات، يصبح إرسال مئات البلاغات الآلية رهاناً رابحاً لمن يملك سكريبت بسيطاً: ولو قُبل بلاغ واحد من مئة، فالعائد مجزٍ. النتيجة ضجيج يدفع ثمنه المراجعون والمشرفون المتطوعون.

ليست الحالة الأولى

قبل جوجل، أنهى مشروع curl مشاركته في برنامج المكافآت على منصة HackerOne في أوائل 2026 بعد أن أرهقت البلاغات الرديئة، وكثير منها آلي، فريقه الأمني الصغير. وتشير تقارير إلى أن إنتل أطلقت برنامجاً جديداً على منصة Intigriti دون مكافآت متاحة حالياً، في خطوة فُسّرت بأنها لتفادي السيل نفسه.

الجهة	الإجراء	السبب المعلن
جوجل (OSS VRP)	إيقاف استقبال بلاغات ثغرات المنتجات	ارتفاع البلاغات الآلية غير الصالحة
curl	إنهاء برنامج المكافآت على HackerOne	بلاغات رديئة تُرهق فريقاً صغيراً
إنتل	برنامج جديد بلا مكافآت متاحة حالياً	تفادي سيل البلاغات الآلية (بحسب تقارير)

حين يصبح إنتاج الادعاء مجانياً وفحصه مكلفاً، يتحوّل الانتباه البشري إلى المورد النادر الذي يجب حمايته.

ماذا يعني هذا للمطورين والمشرفين؟

إن كنت مشرفاً على مشروع مفتوح المصدر

• اطلب إثباتاً قابلاً للتشغيل: حالة اختبار أو مقتطفاً يعيد إنتاج المشكلة، لا وصفاً نصياً فقط.
• اجعل قالب البلاغ إلزامياً: حقول واضحة للإصدار والبيئة والخطوات والأثر.
• رتّب البلاغات بالأولوية: أعطِ وزناً أكبر لمن لديهم سجل بلاغات صحيحة سابقة.
• أعلن سياسة الذكاء الاصطناعي: وضّح ما هو مقبول، وأن المسؤولية عن صحة البلاغ على من يرسله.

إن كنت باحثاً أمنياً تستخدم أدوات الذكاء الاصطناعي

الأداة مفيدة في الاستكشاف، لكنها لا تُعفيك من التحقق. قبل إرسال أي بلاغ شغّل الحالة بنفسك، وتأكد أن الثغرة موجودة في النسخة المحددة، وأن الأثر الذي تصفه حقيقي. البلاغ الذي لا تستطيع إثباته بيدك لا يستحق وقت مراجعٍ آخر.

إن كنت تدير فريقاً أو منتجاً

راجع كيف تتلقى فرقك الأمنية المدخلات الخارجية. إن كان لديك برنامج مكافآت أو قناة إفصاح، فأضف مرشّحات أولية (مثل التحقق الآلي من إعادة الإنتاج) قبل أن يصل أي بلاغ إلى مهندس بشري.

كيف تبني قناة استقبال تقاوم الضجيج؟

مرشّحات قبل البشر

أفضل ما يمكن فعله هو نقل جزء من الفحص الأول إلى الآلة نفسها. اطلب من المُرسِل إرفاق سكريبت إعادة إنتاج يعمل في حاوية معزولة، ودع نظاماً آلياً يشغّله ويتأكد أنه يفشل فعلاً على النسخة المذكورة. البلاغ الذي لا يعيد إنتاج المشكلة لا يصل إلى مهندس أصلاً، وبذلك يتحول فحص الصلاحية من جهد بشري إلى خطوة آلية رخيصة.

كلفة رمزية على الإرسال

بعض المشاريع تفرض سقفاً لعدد البلاغات المفتوحة لكل حساب، أو تشترط سجلاً سابقاً قبل قبول بلاغات جديدة بكثافة. هذه القيود لا تمنع الباحث الجاد، لكنها ترفع كلفة الإغراق على من يعتمد على الكمية.

مكافأة الجودة لا العدد

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

شفافية مع المجتمع

حين تعلن جهة ما أنها أوقفت استقبال نوع معيّن من البلاغات، فهي تعترف بأن النموذج القديم لم يعد يعمل. الأهم هنا أن يعرف المجتمع متى سيُعاد النظر في القرار وعلى أي أساس، وأن يشارك الباحثون الجادون في صياغة القواعد الجديدة بدل أن يدفعوا ثمن سلوك غيرهم.

أسئلة شائعة

هل أوقفت جوجل برامج المكافآت كلها؟

لا. التوقف يخص استقبال بلاغات ثغرات المنتجات في برنامج OSS VRP فقط. بلاغات سلسلة التوريد والبلاغات المعلّقة لم تتأثر، وبرامج جوجل الأخرى ما زالت تعمل.

هل يعني ذلك أن الذكاء الاصطناعي لا يصلح لاكتشاف الثغرات؟

لا يعني ذلك. المشكلة في استخدامه بلا تحقق بشري. هناك أدوات مفيدة فعلاً في الفحص والاستكشاف، لكن الفرق بين أداة تساعد باحثاً وسكريبت يرسل بلاغات بالجملة هو وجود إنسان يتحمل مسؤولية صحة النتيجة.

متى يعود البرنامج؟

قالت جوجل إنها ستنشر تحديثاً في الربع الأول من 2027. لم تُعلن آلية جديدة حتى الآن، لذا يبقى الموعد مجرد موعد للتحديث وليس وعداً بالعودة.

الخلاصة

إيقاف جوجل لجزء من برنامج مكافآت المصدر المفتوح مؤشر على مشكلة أعمق: الذكاء الاصطناعي خفّض كلفة إنتاج البلاغات إلى ما يقارب الصفر، بينما بقيت كلفة التحقق منها بشرية ومرتفعة. الحل لن يأتي من منع الأدوات، بل من رفع معيار الإثبات، وتحميل المُرسِل مسؤولية صحة بلاغه، وتصميم قنوات استقبال تحمي وقت المراجعين. ومن يعمل في الأمن أو في صيانة مشاريع مفتوحة المصدر، فالأفضل أن يبدأ بتعديل قوالب البلاغات وسياساته الآن، قبل أن يصل إليه السيل نفسه.

المصادر: Help Net Security، BleepingComputer، Malwarebytes