Cloudflare تتيح أداة التدقيق التي تستخدمها داخليًا: الجوهر أنها تجادل

أصدرت Cloudflare هذا الأسبوع مهارة (skill) تحوّل وكيل البرمجة إلى مدقّق أمني، فصارت أسرع المستودعات نموًا في قائمة GitHub الأسبوعية: نحو 16,400 نجمة في سبعة أيام، و51,000 في الإجمالي. ووصف الشركة نفسها متواضع على نحو غير معتاد: هذه هي نقطة البداية ذات المستودع الواحد التي تطوّرت منها أداة اكتشاف الثغرات الداخلية لديها، ونُشرت كي يبني آخرون أدواتهم الخاصة.

ما يستحق القراءة ليس فهرس فئات الهجوم، وإن كان واسعًا. بل الجزء المتعلق بكيفية دحض النتائج.

ست مراحل، إحداها مجرد مسك دفاتر

سير العمل مُهيكل لا حواري، وهذا أول ما يفصله عن «اطلب من Claude أن يجد الأخطاء».

المرحلة الأولى استطلاع: رسم البنية وحدود الثقة وأسطح الإدخال، وهنا الجزء غير المألوف، كتابة ذلك في architecture.md وcoverage-ledger.json. المرحلة الثانية توزّع صيادين معزولين على وحدات ذلك السجل، وتدوّن ما فحصه كل منهم، ثم تشغّل نقّاد التغطية للعثور على ما لم ينظر إليه أحد. المرحلة الثالثة تسلّم كل مرشّح فريد إلى مدقّق جديد مهمته دحضه. المرحلة الرابعة تكتب سجلات confirmed أو needs_validation أو rejected في findings.json وتتحقق منها مقابل مخطط JSON. المرحلة الخامسة تكلّف وكلاء جددًا بالتحقق من الادعاءات النهائية على الشيفرة المصدرية، وأي استبدال جوهري يمرّ عبر مدقّق مستقل آخر. المرحلة السادسة تستخرج التقارير من السجلات المتحقَّق منها.

المدقّقان سكربتا Node بسيطان بلا أي اعتماديات: validate-coverage-ledger.cjs يعمل بعد إنشاء السجل وبعد كل تحديث، وvalidate-findings.cjs يعمل في المرحلة الرابعة ثم مرة أخرى بعد كل استبدال في المرحلة الخامسة. هما أقل الملفات إثارة للاهتمام في المستودع، والسبب في تماسك بقية العمل. فوكيل لا يستطيع إنتاج نتيجة مطابقة للمخطط لا يستطيع ادّعاء أنه وجد شيئًا.

الأحكام الثلاثة هي التصميم الحقيقي

معظم أدوات الأمن للوكلاء لها مخرجان: قائمة أخطاء، أو لا شيء. هذه الأداة لها ثلاثة، والفئة الوسطى هي موضع التفكير.

confirmed تعني أثرًا كاملًا في الشيفرة المصدرية مع نتيجة محدودة ومرصودة. needs_validation تعني حقيقة واحدة غير محسومة ومحددة بدقة، دون إسناد درجة خطورة. rejected تعني مرشّحًا دُحض فعليًا، يُسجّل بدل أن يُحذف.

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

المبدأ التصميمي الكامن تحت ذلك مذكور بصراحة في README: لا تؤكّد إلا إخفاقات الحدود القائمة، وإذا تعطّل خيط مستند إلى الشيفرة فأبقه needs_validation مع حقيقته الدقيقة غير المحسومة بدل ترقيته إلى نتيجة. وهناك قاعدة مرتبطة: ثغرات الدفاع في العمق ليست ثغرات أمنية؛ فإذا كان الطبقة A تصد الهجوم، فإن غياب الطبقة B مجرد ملاحظة تقوية.

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

تحقق خصومي، بالمعنى الحرفي

أهم سطر في الأمر: الوكيل الذي يفحص النتيجة ليس أبدًا الوكيل الذي وجدها.

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

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

الرقم الصادق

مدفون في مبادئ التصميم هذا: في اختبارات Cloudflare، وجد تشغيل واحد نحو نصف الثغرات التي وجدتها التشغيلات المتكررة إجمالًا.

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

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

الشرط الذي سيوقف معظم الناس

يسرد README شرطًا صارمًا سيتجاوزه معظم المستخدمين ثم يصطدمون به: صندوق رمل يفرضه نظام التشغيل للبناء والاختبارات والعمليات والمتصفحات والمحاكيات وأدوات التضبيب (fuzzers) والبيانات الثابتة، مع تعطيل الشبكة الخارجية، وبيئة منظّفة ومقيّدة بقائمة سماح، وحدود موارد مفروضة، وكتابة محصورة في مسارات مؤقتة.

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

ويعني أيضًا أنها ليست أداة حاسوب محمول، رغم سطر التثبيت بـnpx. التثبيت أمر واحد:

npx skills add https://github.com/cloudflare/security-audit-skill \
  --skill security-audit

والاستخدام مجرد طلب:

security audit this codebase

والتباين غريب: الاستدعاء جملة واحدة، والمتطلبات المسبقة سياسة صندوق رمل. وفي هذه الفجوة سيذهب معظم جهد النشر.

كيف يبدو المخرج فعليًا

ثلاثة نواتج، مستخرجة لا مكتوبة: REPORT.md وFINDINGS-DETAIL.md وNEEDS-VALIDATION.md، إضافة إلى findings.json الأساسي وسجل التغطية.

هذا الفصل أنفع مما يبدو. تقرير ثغرات واحد يدفع كل نتيجة إلى السجل نفسه، وهكذا ينتهي بك الأمر بحقن SQL حرج بجوار ترويسة CSP غائبة. أما فصل النتائج المؤكدة عن الأسئلة المفتوحة عن الملخصات المستخرجة فيعني أن من يقرأ NEEDS-VALIDATION.md يعرف أنه ينظر إلى عمل جارٍ لا إلى نتائج.

مجلد المخرجات الافتراضي هو ~/security-audit-skill/<repo-name>/run-<N>، ولا يكتب سير العمل داخل المستودع المستهدف إلا إذا وجّهته صراحة إلى مجلد مستبعد من git. تفصيل صغير وحدس صحيح: نواتج التدقيق داخل المستودع تُرفع بالخطأ، وقائمة مثبّتة بثغرات غير مُصلحة هي حادثة بحد ذاتها.

كيف تعرف أنه نجح

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

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

ماذا يقول ذلك عن هذه الفئة

ثلاثة أمور، باختصار.

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

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

وعادة الرقم الصادق تنتشر. البائع الذي ينشر «وجدنا النصف» هو بائع تصدّق ادعاءه التالي أكثر.

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