بعد Mythos: لماذا تحتاج برامج bug bounty الآن إلى أدلة أقوى

قبل بضعة أسابيع كتبت عن Anthropic Mythos و Project Glasswing. كان الموضوع وقتها هو الصورة الكبيرة: إذا أصبحت النماذج أفضل فعلا في العثور على الثغرات القديمة، ودمج مسارات exploit، وفهم codebase كامل، فإن vulnerability research سيتغير.

مقال Sophos الجديد عن bug bounty في عصر Mythos يوضح الآن الجانب التشغيلي من ذلك.

لم يعد السؤال فقط ما إذا كان الذكاء الاصطناعي يجد ثغرات أفضل. السؤال هو ما إذا كانت برامج bug bounty وفرق security ومؤسسات engineering تستطيع التمييز بسرعة كافية بين النفايات، والادعاءات التي تبدو معقولة، ومشكلات الأمن الحقيقية.

المشكلة الحقيقية ليست AI slop فقط

عند الحديث عن AI و bug bounty، يفكر كثيرون بسرعة في slop: تقارير مولدة تلقائيا، رسائل أخطاء مفهومة نصف فهم، سلاسل exploit مخترعة، ادعاءات لا يمكن إعادة إنتاجها، ونصوص كثيرة بمضمون قليل.

هذا حقيقي. وهو مزعج جدا للـ maintainers وفرق product security وأشخاص triage.

لكنه جانب واحد فقط.

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

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

لماذا Sophos مصدر مهم هنا

مقال Sophos ليس تعليقا عاما عن AI. Sophos تنظر إلى برنامج bug bounty الخاص بها وتذكر أرقاما محددة.

بحسب Sophos، يعمل البرنامج العام على Bugcrowd منذ ديسمبر 2017. وتكتب Sophos أنه حتى وقت المقال تمت مكافأة 1,343 ثغرة، من أصل 7,091 submission إجمالا، وبمجموع دفعات قدره 599,695 دولارا أمريكيا.

بالنسبة إلى 2025 تذكر Sophos، من بين أمور أخرى:

• 59,400 دولار أمريكي كدفعات لأكثر من 52 تقريرا
• نحو 420 باحثا مشاركا
• حتى 80,000 دولار أمريكي لـ Intercept X Endpoint تحت شروط معينة
• حتى 50,000 دولار أمريكي لـ Sophos Central
• حتى 50,000 دولار أمريكي لـ Sophos Firewall
• 13 bug صالحة في Sophos Firewall عام 2025 بإجمالي دفعات 21,500 دولار أمريكي
• 13 bug صالحة في Sophos Central عام 2025 بإجمالي دفعات 11,650 دولار أمريكي

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

سيجعلها أصعب.

قابلية إعادة الإنتاج تصبح تذكرة الدخول

أهم نتيجة في رأيي بسيطة لكنها غير مريحة: security report بلا قابلية إعادة إنتاج نظيفة سيصبح أقل قيمة.

ليس لأن فرق triage كسولة. بل لأن وقتها يصبح أندر.

إذا ادعى تقرير أنه يثبت remote code execution أو auth bypass أو تسرب بيانات خطير، فعليه أن يوضح بدقة:

• أي version متأثرة
• أي configuration مطلوبة
• ما الصلاحيات التي يحتاجها المهاجم
• ما الخطوات التي تؤدي إلى النتيجة بشكل قابل لإعادة الإنتاج
• أي logs أو requests أو traces أو screenshots تدعم الادعاء
• ما impact الذي تم إثباته فعلا
• أين يقع الحد بين الفرضية والدليل

هذا يبدو صارما. وهو كذلك. لكنه سيكون ضروريا إذا لم نرد لفرق security أن تغرق في نصوص تبدو مقنعة.

يمكن لتقرير مولد بالذكاء الاصطناعي أن يبدو مقنعا جدا لغويا. يمكنه اقتباس code، والكتابة بأسلوب CVE، وتقليد بنية مرتبة. هذا لا يجعله صحيحا. وفي المقابل، قد يكون تقرير قصير وجاف مع proof of concept جيد ذا قيمة كبيرة جدا.

العملة الجديدة ليست الصياغة. العملة الجديدة هي الدليل.

AI يجعل authorization bugs مزعجة بشكل خاص

نقطة في مقال Sophos تبدو لي عملية جدا: يمكن لـ AI أن يساعد في توسيع authorization bypass تم العثور عليه عبر مساحة scope أكبر.

هذا يطابق ما نراه في بيئات SaaS الحقيقية. Authorization نادرا ما يكون مفتاحا واحدا. إنه يعيش في roles و tenants و object IDs و subdomains و API versions و admin surfaces و mobile endpoints و legacy routes و features نصف مهاجرة.

إذا وجد باحث نمطا، يمكن لـ AI أن يساعد في فحص تنويعاته بشكل منهجي:

• هل يعمل bypass على endpoint واحد فقط أم على عائلة endpoints كاملة؟
• هل يعمل داخل tenant واحد فقط أم عبر tenants؟
• هل توجد المنطق نفسه في APIs قديمة وجديدة؟
• هل أدوار admin و user مفصولة فعلا في كل مكان؟
• هل يمكن تحميل object مباشرة عبر ID رغم أن UI لن يعرضه؟

هنا يصبح AI مفيدا بشكل خطير. ليس كـ hacker سحري، بل كمسرع لاختبار ممل وواسع ومنهجي.

وهذا سيئ للمؤسسات التي تعتمد أمنيا على أن لا أحد يملك الوقت الكافي لاختبار كل التنويعات المملة.

bug bounty ليس صندوق بريد للعلاقات العامة

كثير من الشركات ما زالت تتعامل مع bug bounty كأنه موضوع صورة: لدينا برنامج، إذن نحن منفتحون وحديثون و security-minded.

هذا لم يعد كافيا.

برنامج bug bounty هو نظام إنتاج. يحتاج إلى قواعد واضحة، triage جيد، إعادة إنتاج تقنية، قرب من المنتج، مسؤولية engineering، وارتباط بـ incident response. وإلا فإنه يصبح صندوق بريد عاما يستخدمه الباحثون الخارجيون، و AI slop، والمهاجمون الحقيقيون من المدخل نفسه.

Sophos تجمع في المقال بين نقطتين غير مريحتين:

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

ثانيا: نظام فيه مال وثقة يمكن أيضا إساءة استخدامه. تشير Sophos إلى تجارب حول Pacific Rim و Asnarök و Personal Panda، حيث أثار التقارب الزمني بين الاستغلال النشط وتقارير bug bounty اللاحقة أسئلة على الأقل. لا تقول Sophos صراحة إن كل تقرير من هذا النوع كان خبيثا. لكن النقطة التشغيلية تبقى: لا يجوز بناء bug bounty بسذاجة.

عمليا يعني ذلك:

• يجب ربط reports مع telemetry.
• finding جديد يجب أن يستطيع أيضا إطلاق threat hunts رجعية.
• يجب أن يعرف triage ما إذا كانت محاولات exploit مشابهة قد ظهرت بالفعل.
• سمعة الباحث تساعد، لكنها لا تعوض التحقق التقني.
• Safe harbor مهم، لكنه ليس بديلا عن اكتشاف إساءة الاستخدام.

هذه هي الحقيقة الهادئة: bug bounty جزء من Secure by Design، وليس بديلا عنه.

أدلة أقوى تعني مسؤولية أقوى أيضا

هنا يوجد توتر لا ينبغي تلطيفه.

تاريخيا، يقال للباحثين كثيرا: توقفوا مبكرا بما يكفي. أظهروا bug، لكن لا تتعمقوا أكثر من اللازم. لا تلمسوا بيانات العملاء. لا lateral movement. لا أفعال تخريبية.

هذا صحيح.

في الوقت نفسه، سيزداد عبء الإثبات. إذا أنتج AI بكميات كبيرة reports تبدو معقولة لكنها خاطئة، ستطلب البرامج evidence أكثر. عندها يظهر السؤال الصعب: كيف يمكن للباحث إثبات impact بقوة أكبر من دون الانزلاق إلى سلوك خطر؟

لا يمكن أن يكون الجواب: “افعلوا المزيد فقط.” يجب أن يصبح الجواب أكثر تحكما:

• Rules of Engagement أوضح
• test environments مخصصة
• reproduction paths آمنة
• حدود متفق عليها لإثبات impact
• sandbox و lab systems أفضل
• replays آلية لـ proof of concept

بالنسبة إلى الشركات الكبيرة، سيصبح هذا شبه إلزامي. من يدفع bounties عالية بجدية يجب أن يمتلك أيضا البنية التحتية للتحقق من reports بسرعة ونظافة.

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

ماذا يمكن أن يتعلم admins و MSPs

قد يقول أحدهم: هذا يخص المصنعين وبرامج Bugcrowd فقط.

لا أعتقد ذلك.

الآلية نفسها تضرب MSPs وفرق IT الداخلية ومسؤولي security. في كل مكان يجب فيه تقييم findings خارجية أو داخلية، يرتفع الضغط:

• scanners تنتج findings أكثر.
• AI assistants تشرح findings بشكل أكثر إقناعا.
• developers يجلبون AI-generated security notes.
• customers يسألون عن CVEs قبل معرفة السياق.
• management يريد معرفة هل الخطر حقيقي أم مجرد صوت عال.

الإجابة العملية ليست تجاهل كل شيء. الإجابة هي عملية validation أكثر صرامة.

بالنسبة لي، تشمل على الأقل هذه الأسئلة:

1. هل المشكلة قابلة لإعادة الإنتاج؟
2. هل scope المتأثر واضح؟
3. هل يوجد attacker path واقعي؟
4. هل impact مثبت تقنيا أم مجرد ادعاء؟
5. هل توجد logs أو telemetry يمكن أن تظهر exploitation؟
6. هل fix عبارة عن patch أو configuration أو workaround أو مجرد ترقيع؟
7. هل يجب البحث رجعيا لمعرفة ما إذا كان قد تم استغلال ذلك بالفعل؟

هذا يبدو عملا أكثر. وهو كذلك. لكنه عمل أفضل من الرد العصبي على كل report مكتوب جيدا.

لماذا يناسب هذا Mythos

النقطة الحاسمة في Mythos بالنسبة لي لم تكن أبدا فقط: “رائع، نموذج يجد bugs.”

النقطة كانت: إذا أصبحت هذه القدرات أكثر واقعية، فإن الوقت بين الاكتشاف والفهم وإعادة الإنتاج والاستغلال ينخفض. هناك بالضبط تتأثر برامج bug bounty. إنها تقع عند تقاطع research و attack potential و engineering و responsibility.

Sophos تصوغ الأمر بشكل مشابه في مقالها: السؤال ليس كيف نوقف AI submissions. السؤال هو كيف نحافظ على trust و signal عندما يمكن إنتاج البحث الجيد والضجيج بسرعة الآلة.

بالنسبة لي، هذه أنظف خلاصة للمشكلة.

ليست كل مؤسسة بحاجة إلى برنامج bug bounty كبير خاص بها. لكن كل مؤسسة تحتاج إلى آليات أفضل لفحص الادعاءات التقنية. لأن فيضان معلومات security لن يصبح أصغر. سيصبح أسرع، وأعلى صوتا، وأفضل صياغة.

تقييمي

أرى مقال Sophos كـ follow-up مفيد لـ Mythos، لأنه ينقل النقاش من غرفة النماذج إلى غرفة التشغيل.

Mythos هو signal المذهل. أما bug bounty triage فهو طاولة العمل التي يظهر عليها هل تستطيع security processes مجاراة السرعة.

أطروحتي بسيطة:

• من يجمع reports أكثر فقط سيخسر.
• من يطلب evidence قابلة لإعادة الإنتاج سيحدد الأولويات بشكل أفضل.
• من يربط bug bounty و telemetry و engineering و incident response سيرد أسرع.
• من يفهم AI كـ text generator فقط يستهين بقيمته للعمل الأمني المنهجي.
• من لا يفلتر AI slop يحرق وقت الأشخاص الذين يفترض أن يحلوا المشكلات الحقيقية.

هذا أقل بريقا من frontier model يجد zero-days. لكن هناك بالضبط يتحدد هل تصل مكاسب security إلى defenders، أم يغرق الجميع في ضجيج أكثر.

إلى اللقاء في المرة القادمة،
Joe