جعل الذكاء الاصطناعي اكتشاف الثغرات رخيصاً، وأصبح إصلاحها هو عنق الزجاجة
انهار تكلفة الاكتشاف
كان العثور على ثغرة معقولة يتطلب مهارة ووقتاً وفهماً عميقاً لقاعدة الشيفرة. وقد أزالت النماذج اللغوية الكبيرة معظم هذه التكلفة. فالباحثون والأدوات الآلية يستطيعون اليوم توليد أعداد كبيرة من التقارير المرشحة ضد مشاريع مفتوحة المصدر شائعة في غضون ساعات. لكن العمل لا ينتهي عند الاكتشاف؛ إذ لا يزال لزاماً إعادة إنتاج المشكلة وتقدير خطورتها وكتابة الإصلاح ومراجعته وإيصاله إلى المستخدمين. ولم تصبح أي من هذه الخطوات أرخص.
هذا التفاوت يجبر برامج مكافآت الثغرات على تغيير قواعدها. فقد علّقت curl برنامج مكافآتها في يناير 2026. وشدّدت Google برنامج مكافآت البرمجيات مفتوحة المصدر في مارس 2026، فصارت تطلب أدلة أعلى جودة، مثل إعادة إنتاج عبر OSS-Fuzz أو وصلة مدموجة، لبعض مستويات الدفع. وقد صرّحت Google بأن كثيراً من التقارير المولّدة بالذكاء الاصطناعي تتضمن شروط تفعيل مختلَقة أو تبلغ عن أخطاء ذات أثر أمني ضعيف. وفي أبريل، أوقفت HackerOne مدفوعات Internet Bug Bounty، وكان البرنامج قد دفع أكثر من 1.5 مليون دولار منذ 2012، وكان يخصص تاريخياً نحو 80 في المئة من المكافآت للاكتشافات الجديدة و20 في المئة لدعم الإصلاح.
وتُعد تفسيرات HackerOne أوضح بيان للمشكلة حتى الآن. فقد قالت إن البحث المدعوم بالذكاء الاصطناعي يوسّع اكتشاف الثغرات عبر المنظومة ويزيد التغطية والسرعة، وإن التوازن بين النتائج وقدرة الإصلاح في المصادر المفتوحة قد تغيّر جوهرياً. وما زال Node.js، وهو من أوائل المشاريع المتأثرة، يقبل التقارير عبر HackerOne، لكنه لم يعد يدفع عليها مكافآت.
لماذا تكون التقارير الخاطئة مكلفة
التقرير الخاطئ ليس مجانياً على من يتلقاه. فعلى المشرف أن يقرأه ويعيد إنتاجه ويشرح لماذا لا يعمل، وغالباً ما يحدث ذلك في سلسلة مليئة بالمراسلات المهذبة وغير المفيدة. وإذا وصف التقرير مساراً للتفعيل لا وجود له، فقد يقضي المشرف ساعات في فحص شيفرة لا تُنفَّذ أبداً. وعند ضرب ذلك في عشرات الإرساليات، قد يفقد فريق متطوع أسبوعه كله في الفرز. والتقارير التي تبدو موثوقة وهي خاطئة أغلى من التقارير الرديئة الواضحة، لأنها لا يمكن رفضها بنظرة سريعة.
وقد ردّت البرامج بإعادة عبء الإثبات إلى المُبلِّغ. فطلب إعادة إنتاج بمُختبِر الانحراف (fuzzer)، أو إثبات مفهوم يعمل على الإصدار الحالي، أو وصلة، يجعل المُبلِّغ يتحمل جزءاً من العمل الذي كان سيقع على المشرف. كما يصفّي الإرساليات التي لم يشغّل صاحبها الشيفرة فعلاً.
لماذا يتجاوز الأمر المصادر المفتوحة
العواقب ليست نظرية. فقد وجد تقرير Verizon لخروقات البيانات لعام 2026 أن نحو 31 في المئة من الخروقات تبدأ الآن من استغلال ثغرات البرمجيات، مقابل نحو 20 في المئة في العام السابق. وقد تجاوز استغلال الثغرات سرقة بيانات الاعتماد بوصفه المسار الأول للدخول في تلك المجموعة من البيانات. ومعظم البرمجيات المؤسسية مبنية على مكونات مفتوحة المصدر، لذلك يتحول تراكم الإصلاحات في المنبع إلى تراكم في كل منتج في المصبّ.
وقد أبرزت تغطية فجوة التمويل حجم المشكلة. فبحسب التقارير، طلبت Linux Foundation مساعدة مالية من شركات الذكاء الاصطناعي، والتزمت Google وAnthropic وAWS وMicrosoft وOpenAI معاً بمبلغ 12.5 مليون دولار للعمل الأمني في المصادر المفتوحة. وهذا مبلغ معتبر، لكنه مساهمة لمرة واحدة مقارنة بالعمل المستمر لصيانة المكتبات واسعة الاستخدام.
ما الذي يجب أن يتغير
الخطوة الصحيحة أن يُدفع المال مقابل الجزء المكلف من العمل. فالاكتشاف صار رخيصاً، أما الإصلاح المؤكد الذي يُنشر فلا. وتترتب على ذلك تغييرات عدة.
- ينبغي للمشرفين أن يكتبوا معياراً صريحاً للأدلة في سياسة الأمان لديهم. فالتقارير التي تفتقر إلى إعادة إنتاج أو اختبار فاشل أو إثبات مفهوم يمكن إغلاقها تلقائياً، مع قالب قصير يوضح المطلوب. وإعداد ذلك يستغرق دقائق ويوفر ساعات لاحقاً.
- ينبغي للمشرفين التعامل مع مراجعة الوصلات كنشاط له ميزانية. فإن كان المشروع يعتمد على متطوعين، فيجب أن يغطي التمويل وقت المراجعة لا مكافآت التقارير فقط.
- ينبغي للشركات المعتمدة على البرمجيات مفتوحة المصدر قياس زمن الإصلاح لا زمن الإبلاغ. فالفريق الذي يتتبع عدد ما فرزه سيتجه نحو الحجم. أما الفريق الذي يتتبع المدة التي تبقى فيها ثغرة غير مُصلحة في تبعياته فسيمول العمل الذي يهم.
- ينبغي لمنصات مكافآت الثغرات أن تدفع للوصلات المدموجة أكثر من التقارير، وأن تفكر في دفع مكافآت لمستندات إعادة الإنتاج قبل بدء الفرز.
- ينبغي للباحثين الذين يجدون ثغرات حقيقية أن يرسلوا الإصلاح مع التقرير. فالوصلة التي تجتاز مجموعة الاختبارات هي أنفع ما يمكن أن يقدمه المُبلِّغ للمشرف.
ماذا يعني هذا لفريقك
إن كنت تدير منتجاً يعتمد على مكونات مفتوحة المصدر، فابدأ بجرد المشاريع الأساسية التي تعتمد عليها وتحقق مما إذا كان لديها مسار استجابة أمنية نشط. واطلب من مورّديك مستويات خدمة للإصلاح، لا نتائج الفحص فقط. فحين تُبلَّغ ثغرة في المنبع، يكون الزمن حتى إصدار نسخة مُصلحة هو الرقم الذي يحدد تعرّضك، وهذا الرقم يعتمد على سعة المشرفين التي يمكنك المساهمة في تمويلها.
مشكلة الاكتشاف لن تختفي، وربما لا ينبغي لها أن تختفي. فاكتشاف مزيد من الثغرات ليس فشلاً في حد ذاته. الفشل أن نواصل مكافأة الخطوة الرخيصة بينما تقع الخطوة المكلفة على عدد قليل من المتطوعين المنهكين. والبرامج التي تغيّر قواعدها الآن تحاول تصحيح ذلك، وعلى الفرق التي تعتمد على هذه البرمجيات أن تنتبه أيضاً.