Google توقف مكافآت ثغرات مفتوحة المصدر: تقارير AI غير الصالحة أغرقت الفرز

أوقفت Google استقبال بلاغات ثغرات المنتجات الجديدة في برنامج مكافآت ثغرات البرمجيات مفتوحة المصدر OSS VRP اعتباراً من 1 أكتوبر 2026، وفق قواعد البرنامج المنشورة، وتعهدت بتقديم تحديث عن هذا المسار في الربع الأول من 2027. يشمل التعليق هذا النوع من البلاغات فقط؛ ما زالت بلاغات اختراق سلسلة التوريد مقبولة، ولا يشمل التغيير البلاغات التي قُدمت قبل بدء التعليق. بالنسبة إلى الباحثين، ضاقت قناة المكافآت المتاحة لثغرات المنتجات من دون إغلاق البرنامج كله.

ربطت TechCrunch القرار بتقارير مولدة بالذكاء الاصطناعي، ونقلت تفسير Google حرفياً: «This pause is due to a significant rise in automated submissions, the vast majority of which are not valid». لا يحدد هذا الوصف عدد البلاغات أو نسبة ما أنتجته أدوات الذكاء الاصطناعي. والموعد المعلن يخص تحديث وضع البرنامج، وليس تاريخاً مؤكداً لاستئناف استقبال ثغرات المنتجات.

ما الذي خرج من نطاق OSS VRP؟

ثغرة المنتج هي خلل في تصميم المشروع المفتوح أو تنفيذه يمس سرية بيانات المستخدمين أو سلامتها عند استخدام البرمجية. قد يظهر الخلل في محلل ملفات، أو آلية تنقية مدخلات، أو معالجة لمسار ملف؛ وهي أمثلة ترد ضمن قواعد البرنامج. بعد بدء التعليق، لا يجعل وجود الخلل في مستودع تابع لـGoogle بلاغه الجديد مؤهلاً لمسار ثغرات المنتجات في OSS VRP. وتعرض خانة مكافآت هذا النوع في جدول البرنامج الحالي شرطات بدلاً من مبالغ، بما ينسجم مع وقف استقباله.

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

أين بقي باب البلاغات مفتوحاً؟

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

ثمة مسار منفصل لبعض مستودعات Google Cloud: قد يُقبل بلاغ ثغرة منتج عبر Cloud VRP إذا ثبت أثرها في أحد منتجات Google Cloud. وتوضح تغطية Tom’s Hardware أن هذا الاحتمال يخص بعض المستودعات، وليس كل شيفرة منشورة باسم الخدمة السحابية. معيار القبول هو الأثر في منتج مشمول بقواعد البرنامج السحابي؛ وملكية Google للمستودع لا تعني وحدها قبول البلاغ أو استحقاق مكافأة.

تتحدد حدود القبول الحالية بحسب موضع الخلل وأثره:

• ثغرة منتج جديدة في OSS VRP: استقبالها معلّق، حتى إذا كان العيب حقيقياً في مشروع مشمول سابقاً.
• ثغرة سلسلة توريد في OSS VRP: يظل تقديمها ممكناً إذا أمكن إظهار أثرها في سلامة المصدر أو البناء أو الحزم المنشورة، وفق شروط البرنامج.
• ثغرة منتج في مستودع Google Cloud: قد تتجه إلى Cloud VRP عندما تؤثر في منتج سحابي مؤهل؛ اسم المستودع وحده لا يحسم القبول.
• بلاغ منتج سبق التعليق: لا يسري عليه وقف استقبال البلاغات الجديدة، ويظل تقييمه مرتبطاً بالقواعد التي تحكم حالته.

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

لماذا أصبحت قابلية إعادة الإنتاج حاسمة؟

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

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

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

ما الذي ينتظر البرنامج بعد التعليق؟

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

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

اقرأ أيضًا:

• تقارير ظهور AI في Search Console أصبحت عالمية، لكنها بلا بيانات نقر
• Google SecOps يؤتمت القضية كاملة، لكن المعاينة تستثني بعض السجلات
• North Small Translate يدعم العربية، لكن أوزانه المفتوحة غير تجارية