Cloudflare

Cloudflare تنقل صيد الثغرات إلى داخل الشفرة: لا نتيجة من دون دليل في المصدر

أضافت Cloudflare إلى خدمة Managed Defense ميزة اكتشاف الثغرات ومعالجتها، تقرأ الشفرة المصدرية إلى جانب حركة الإنتاج وإشارات الأمن. القاعدة صريحة: كل نتيجة يجب أن تُدعَم بدليل في الشفرة. ويجري الاستطلاع والتحقق بنموذج GPT-5.6 Cyber من OpenAI، والاستدلال على خوادم OpenAI لا على الشبكة الطرفية.

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

قاعدة الدليل

تضع Cloudflare المعيار في جملة واحدة: "كل نتيجة ثغرة يجب أن تُدعَم بدليل في الشفرة المصدرية". وفي المثال الذي تفتتح به التدوينة، المشكلة ليست العدد: فحص واحد ينتج 4000 ثغرة جديدة و78 حرجة، والفريق لا يعرف أيها قابل للوصول فعلاً. وتقول الشركة إن النماذج اللغوية الكبيرة تستطيع إظهار نقاط الضعف في قاعدة الشفرة خلال دقائق؛ الناقص هو ربط تلك القائمة بدليل التعرّض.

ما الذي تقرأه

جرد Web Assets، بصلاحية قراءة مصرّح بها
قواعد جدار حماية التطبيقات وضوابطه
Workers Trace Events Logpush، حيثما توفّر
بيانات وصفية عن الحركة ولقطات لأحداث الأمن تُظهر المسارات النشطة وعمليات الكشف المُفعَّلة
الشفرة المصدرية ضمن النطاق الذي يصرّح به العميل

أين يعمل النموذج

تستخدم خطوات الاستطلاع والتنقيب والتحقق نماذج Daybreak من OpenAI، وتحديداً GPT-5.6 Cyber. وتكتب Cloudflare أن الاستدلال يجري على خوادم OpenAI عبر Cloudflare AI Gateway، لا على شبكتها الطرفية. والنموذج لا يستطيع بنفسه تطبيق الرقعة أو القاعدة التي يقترحها.

للقارئ المؤسسي

هذه محاولة للانتقال من منطق "افحص وسجّل ألف نتيجة" إلى منطق "أثبت ثم رتّب الأولويات"، وهو السؤال الصحيح لفرق تعاني إرهاق التنبيهات. أما النصف الآخر من القرار فهو في العقد: الشفرة المصدرية تخرج إلى نموذج طرف ثالث ضمن نطاق مصرّح به. والأسئلة الواجبة: أي مستودع، ولأي مدة، وبأي سياسة احتفاظ. قالت Cloudflare بوضوح أين يجري الاستدلال، والباقي يتوقف على تصنيف بيانات المؤسسة نفسها.