هل يستطيع نموذج الذكاء الاصطناعي اختراق نظام فعلًا؟ ما وراء أرقام بنش ماركات الأمن السيبراني

تفتح صفحة نتائج أحد نماذج الذكاء الاصطناعي، فتجد رقمًا مثل 84.5 في CyberGym، وآخر مثل 54.4 في ExploitBench، وبجانبه 105 / 130 في ExploitGym. للوهلة الأولى تبدو كلها نسبًا تقيس «قوة النموذج في الاختراق». لكن هنا تبدأ المشكلة: الأرقام الثلاثة لا تقيس الشيء نفسه، ولا تستخدم وحدة قياس واحدة، ولا تعني أن النموذج يستطيع اختراق 84.5% من الأنظمة الموجودة على الإنترنت.

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

هذا الفرق بين نموذج يعرف كيف يشرح الثغرة ووكيل يستطيع إثباتها عمليًا هو جوهر بنش ماركات الأمن السيبراني الحديثة.

الشكل 1: مراحل التقييم من تجميد مجموعة الاختبارات إلى إصدار نتيجة قابلة للتدقيق. الرسم توضيحي وليس مخططًا معماريًا رسميًا لأي بنش مارك بعينه.

#ما البنش مارك؟ ولماذا لا تكفي الأسئلة والأجوبة؟

الـ Benchmark ليس مجرد مجموعة أسئلة لها إجابات نموذجية. في تقييم النماذج التي تؤدي مهامًا تقنية، هو بروتوكول تجريبي قابل للإعادة يحدد المهمة والبيئة والموارد المتاحة ومعيار النجاح. يتكون عادةً من Dataset للمهام، وHarness يربط النموذج بالأدوات، وSandbox معزول لتشغيل محاولاته، وScorer أو Oracle يتحقق من المخرجات، إلى جانب سجلات تفصيلية للتكلفة والزمن والخطوات والنتيجة.

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

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

#كيف تتحول ثغرة حقيقية إلى مهمة اختبار؟

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

يُجهز لكل حالة ملف تعريف بالمهمة، شبيه بالمثال التوضيحي التالي. هذا مخطط تعليمي افتراضي لتوضيح بنية البيانات، وليس صيغة ملفات رسمية لمشروع CyberGym:

{
  "task_id": "demo-parser-001",
  "category": "vulnerability-reproduction",
  "target": {
    "repository": "sample-parser",
    "vulnerable_commit": "a1b2c3",
    "fixed_commit": "d4e5f6"
  },
  "agent_input": {
    "source_tree": "/workspace/sample-parser",
    "description": "A malformed input causes an unexpected failure"
  },
  "execution_budget": {
    "max_tool_calls": 100,
    "max_wall_seconds": 3600
  },
  "private_grading": {
    "vulnerable_build": "expected_failure",
    "fixed_build": "expected_clean_execution"
  }
}

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

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

#CyberGym: هل يستطيع النموذج إعادة إنتاج الثغرة؟

يضم CyberGym عدد 1,507 حالة لثغرات حقيقية مرتبطة بـ 188 مشروعًا برمجيًا. في إعداد Level 1 يحصل الوكيل على وصف للثغرة وعلى الشيفرة المصدرية قبل التصحيح، ثم يُطلب منه إنشاء Proof of Concept (PoC) يفعّل الخلل المستهدف. تتطلب المهمة فهم مسار البيانات من نقطة دخول البرنامج إلى الموضع المعيب، وليس العثور على اسم دالة مشبوهة فحسب. [1]

يعمل المقيم بمقارنة تنفيذ الإدخال الناتج على نسختين: Pre-patch وPost-patch. إذا ظهر الخلل في النسخة القديمة واختفى في النسخة المصححة، يكون هناك دليل على إعادة إنتاج الثغرة التاريخية. وقد تُستخدم أدوات كشف أخطاء الذاكرة مثل AddressSanitizer وUndefinedBehaviorSanitizer بحسب المهمة. أما إذا تسبب الإدخال نفسه في انهيار النسختين، فلا يجوز تلقائيًا اعتباره إعادة إنتاج ناجحة للخلل الأصلي؛ فقد يكون عيبًا مختلفًا أو إصلاحًا غير مكتمل، ويحتاج إلى تحقق إضافي. [1][4]

هذا يفسر المعنى الدقيق لنتيجة 84.5% المنشورة لـ GLM-5.3: إنها نسبة نجاح معلنة في إعادة إنتاج الحالات ضمن إعداد محدد، وليست نسبة نجاح في السيطرة على الأنظمة أو تنفيذ شيفرة عن بعد. كذلك لا تكفي النسبة وحدها لمعرفة مدى استقرار الأداء: هل كانت المحاولة واحدة أم عدة محاولات؟ هل كانت أدوات البحث متاحة؟ وهل اختلفت نسخة الوكيل أو حد الزمن؟

التمييز بين مستويات الاختبار هنا أساسي أيضًا. يقدم CyberGym عدة مستويات تختلف في المعلومات المعطاة للنموذج؛ وتمثل Level 0 وLevel 1 إعدادات أصعب من Level 3 الذي يوفر معلومات أكثر. جمع نتائج هذه المستويات في رقم واحد من دون توضيح تركيب العينة يؤدي إلى مقارنة غير صحيحة. [4]

#ExploitGym: هل يستطيع تحويل خلل معروف إلى استغلال عملي؟

إذا أثبت النموذج وجود ثغرة، فالسؤال التالي أصعب بكثير: هل يستطيع تحويلها إلى نتيجة استغلال قابلة للتحقق؟ هنا يأتي ExploitGym. يحتوي الإصدار المنشور من المشروع على 869 مهمة موزعة على 502 من برامج فضاء المستخدم Userspace، و181 تخص محرك V8، و186 تخص نواة Linux. [2]

تختلف نقطة البداية عن CyberGym: يحصل الوكيل على معلومات البناء، والشفرة المعرضة للخلل، وإدخال موجود مسبقًا يفعّل المشكلة Proof of Vulnerability (PoV)، إلى جانب بيئة تشغيل معزولة. ولا يكفي أن يتسبب في انهيار البرنامج مجددًا؛ المطلوب أن ينتج استغلالًا يحقق تنفيذًا غير مصرح به داخل الهدف التجريبي، ويثبت ذلك باستخراج قيمة سرية Flag لا تتاح عبر الواجهة المشروعة. ويتحقق الحكم أيضًا من أن النجاح جاء عبر الثغرة المقصودة، لا عبر خطأ آخر غير مرتبط بها. [2]

وهنا تظهر أهمية الفصل بين مؤشرين مختلفين: Flag captured وIntended vulnerability exploited. قد يستخرج الوكيل القيمة عبر مسار غير متوقع أو خلل آخر، لكن احتساب ذلك نجاحًا للثغرة المحددة يلوث المقياس. يستخدم المشروع حكمًا إضافيًا للتحقق من ارتباط النتيجة بالخلل المقصود. كما يمكن تشغيل سيناريوهات مع وسائل حماية مثل ASLR وعزل المحرك؛ لذلك يجب فصل نتائج إعدادات الحماية المفعّلة عن غير المفعّلة. [2]

أما الصيغة 105 / 130 المنشورة بجوار GLM-5.3 فهي ليست كسرًا حسابيًا ولا درجة من 130. إنها 105 مهام ناجحة ضمن ميزانية ساعتين و130 مهام ناجحة ضمن ميزانية ست ساعات، من أصل مجموعة الاختبار المحددة. وباستخدام مقام 869 تصبح النسبتان الوصفيتان نحو 12.1% و15.0% على التوالي. هذه الأرقام لا تصلح للمقارنة المباشرة مع 84.5% في CyberGym؛ لأن الاختبار هنا يقيس خطوة أكثر تقدمًا في سلسلة الاستغلال. [2][3]

وتوجد تفصيلة منهجية مهمة في نتائج Z.ai: ميزانيتا الساعتين والست ساعات للنماذج المقارنة حُسبتا بإعادة تحجيم زمن استدعاءات واجهات النماذج اعتمادًا على سرعة الرموز في الثانية Tokens per Second، مع إضافة زمن المعالجة غير المرتبط بالاستدلال. بالتالي ليست كل نتيجة مساوية لتشغيل ساعتين أو ست ساعات فعلية على حاسوب واحد. قراءة بروتوكول احتساب الزمن شرط لفهم المقارنة. [3]

#ExploitBench: إلى أي مستوى يصل الاستغلال؟

يركز ExploitBench على 41 ثغرة حقيقية مصححة في محرك V8، لكنه يتجنب اختزال التطور إلى نتيجة ثنائية: نجاح أو فشل. بدلًا من ذلك يستخدم 16 قدرة قابلة للقياس موزعة على خمس طبقات Capability Tiers، بحيث تظهر المسافة بين الوصول إلى السطر المعيب وبين امتلاك تحكم كامل في العملية. [5][6]

تقاس القدرات باستخدام Oracles آلية، لا بنص يكتبه النموذج. وبدلًا من سؤال «هل اخترق الهدف؟» فقط، يمكن تحديد الموضع الذي توقفت عنده المحاولة: هل وصلت إلى العيب، أم أحدثت انهيارًا، أم بنت قدرة استغلال داخل النطاق المعزول، أم تجاوزت العزل؟ هذه الدقة مهمة عند دراسة قدرة النماذج على تجاوز آليات التحصين، كما أنها تمنع تضخيم إنجازات لا تتجاوز إنتاج إدخال يؤدي إلى Crash.

لذلك فإن 54.4% المنشورة لـ GLM-5.3 في هذا الاختبار هي متوسط تغطية درجات القدرات المقاسة، وليست نسبة المهام التي تحقق فيها تنفيذ شيفرة كامل. وتذكر منهجية Z.ai أنها استخدمت حدًا أقصاه 300 جولة تفاعل، وقيّمت 41 مهمة عبر ثلاث مراجعات/محاولات، ثم جمعت القدرات المحققة عبر المراجعات لحساب نتيجة كل مهمة. وعليه يجب عدم قراءة الرقم على أنه «استغلال كامل في 54.4% من ثغرات V8». [3][5]

#قراءة نتائج GLM-5.3 بطريقة صحيحة

الجدول التالي يعيد ترتيب الأرقام المنشورة من Z.ai في أغسطس 2026 مع أسماء النماذج، حتى لا تصبح القيم مفصولة عن الأعمدة التي تنتمي إليها. علامة الشرطة تعني عدم إتاحة نتيجة في ذلك الجدول، وليست درجة صفر. الأرقام بيانات منشورة وفق إعدادات أصحابها، وليست إعادة تقييم مستقلة أجريت لهذا المقال. [3]

الشكل 2: رسم أُعيد بناؤه من أرقام Z.ai المنشورة. كل لوحة تستخدم مقياسًا مختلفًا عمدًا: نسبة إعادة إنتاج، وعدد مهام، ونسبة تغطية قدرات. لا يجوز جمعها أو حساب متوسط مباشر بينها.

يكشف الانتقال من GLM-5.2 إلى GLM-5.3 عن تحسن معلن في جميع الاختبارات الثلاثة، لكنه ليس التحسن ذاته من حيث الدلالة. الفرق في CyberGym هو 7.3 نقاط مئوية، وفي ExploitBench هو 30 نقطة مئوية في تغطية القدرات، بينما ارتفع عدد نجاحات ExploitGym خلال ساعتين من 29 إلى 105. هذه ثلاث جمل صحيحة، لكنها لا تسمح باستنتاج أن النموذج أصبح أسرع في اختراق شبكة إنتاجية بمقدار معين أو أنه سيكتشف النسبة نفسها من الثغرات الصفرية.

وهناك مثال أكثر دقة لضرورة قراءة المنهجية قبل الرقم: نشرت Anthropic تقييمًا منفصلًا يركز على الوصول إلى نتيجة الاستغلال الكامل، وذكرت أن GLM-5.3 حقق هذه النتيجة في 50 محاولة من أصل 410 على ExploitBench، أي نحو 12.2% من محاولات ذلك الإعداد. لا يناقض هذا رقم 54.4%؛ فالأول يقيس بلوغ النتيجة النهائية بينما الثاني يقيس تغطية قدرات متدرجة. [6][7]

كذلك أعلنت NIST/CAISI في تقييم مستقل صدر في 17 سبتمبر 2026 نتيجة 61.1% لـ GLM-5.3 على ExploitBench باستخدام بروتوكولها، أي متوسطًا يعادل 9.8 من 16 نقطة مع احتساب أفضل ثلاث محاولات للمهمة، وهو إعداد يختلف عن الإعداد المنشور من Z.ai. اختلاف النتيجتين لا يعني بالضرورة خطأ أحد الطرفين؛ بل يبرز أثر Harness وطريقة اختيار المحاولة الأفضل وضوابط التقييم. ونشرت الجهة أيضًا فواصل ثقة Wilson بنسبة 95%، وهو مستوى من الإفصاح الإحصائي ينبغي أن ترافقه أي مقارنة مهنية. [8]

#كيف تُحسب الدرجة؟ الفرق بين النجاح والتكرار وتغطية القدرات

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

SuccessRate = 100 * successful_tasks / valid_tasks

CoverageScore = 100 * mean(
    verified_capability_flags_per_task / total_capability_flags
)

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

ثم تأتي مشكلة العشوائية Stochasticity: المحاولة نفسها قد تنجح مرة وتفشل مرة أخرى بسبب توليد النموذج، أو اختلاف مسار الأدوات، أو إدارة السياق. يقيس pass@1 نتيجة محاولة واحدة وفق بروتوكول محدد، بينما يقيس pass@k احتمال أن تنجح محاولة واحدة على الأقل ضمن k محاولات، إذا سمح البروتوكول بذلك. أما pass^k فيعبّر عن احتمال نجاح كل المحاولات، وهو مؤشر أقرب إلى الثبات التشغيلي. لا ينبغي استخدام هذه المقاييس بالتبادل، وخصوصًا عند مقارنة نموذج يُسمح له بتكرار المهمة بآخر تُحتسب له محاولة واحدة فقط. [9]

وفي المقارنات الأكثر تقدمًا، لا تُعامل جميع المهام وكأنها متساوية الصعوبة. استخدمت CAISI نموذجًا إحصائيًا من نوع Item Response Theory (IRT) لتقدير القدرة الكامنة للنموذج وصعوبة المهمة. في الصيغة اللوجستية المبسطة:

P(success_ij) = sigmoid(theta_i - delta_j)

# theta_i: model capability
# delta_j: task difficulty

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

#اختبار عملي: ابنِ مقيمًا مصغرًا يفهم الفرق بين العيب والإصلاح

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

احفظ الملف باسم toy_oracle.py:

import json


def vulnerable_parser(data: bytes):
    index = data[0]
    return data[index]


def fixed_parser(data: bytes):
    if not data:
        return None
    index = data[0]
    if index >= len(data):
        return None
    return data[index]


def has_index_error(parser, payload: bytes) -> bool:
    try:
        parser(payload)
        return False
    except IndexError:
        return True


payload = bytes.fromhex("0441")
old_failed = has_index_error(vulnerable_parser, payload)
new_failed = has_index_error(fixed_parser, payload)

verdict = {
    "payload_hex": payload.hex(),
    "vulnerable_failed": old_failed,
    "patched_failed": new_failed,
    "reproduced": old_failed and not new_failed,
}

print(json.dumps(verdict, indent=2))
assert verdict["reproduced"] is True

شغّل التجربة على Linux أو Windows بوجود مفسر Python:

python3 toy_oracle.py

py toy_oracle.py

ستظهر النتيجة التالية:

{
  "payload_hex": "0441",
  "vulnerable_failed": true,
  "patched_failed": false,
  "reproduced": true
}

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

#كيف تشغّل بنش مارك حقيقيًا على نموذج مثل GLM-5.3؟

يوفر مشروع Inspect AI ومجموعة Inspect Evals تنفيذًا مفتوحًا لتجارب متعددة، بينها CyberGym. في بيئة Linux اختبارية مزودة بـ Docker وبصلاحيات وصول مصرح بها للنموذج، تبدأ بتثبيت الأدوات والاعتماد المطلوب للتجربة. توثق واجهة المشروع الرسمية إمكانية اختيار عدد محدود من المهام بدل تنزيل المجموعة الكاملة، التي يبلغ حجم بياناتها نحو 236GB قبل احتساب صور التشغيل. [4][10]

python3 -m venv .venv
source .venv/bin/activate
python -m pip install -U 'inspect-evals[cybergym]' openai

docker info

إذا أردت استخدام واجهة Z.ai المتوافقة مع تنسيق OpenAI عبر Inspect، فيمكن ضبط اسم المزود وعنوانه ومفتاحه. تظهر هنا صيغة التشغيل المصغرة؛ وهي ليست إعادة إنتاج تلقائية لدرجة 84.5% المنشورة، لأن الوصول إلى نتيجة قابلة للمقارنة يتطلب مطابقة إعدادات النموذج والوكيل وعدد المحاولات والموارد والإصدار على كامل المجموعة. [3][10][11]

read -rsp 'Z.ai API key: ' ZAI_API_KEY; echo
export ZAI_API_KEY
export ZAI_BASE_URL='https://api.z.ai/api/paas/v4'

inspect eval inspect_evals/cybergym \
  --model openai-api/zai/glm-5.3 \
  -T eval_names='["cybergym_arvo_47101"]'

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

يمكن تشغيل ExploitGym وExploitBench من مستودعاتهما الرسمية، لكنهما يحتاجان إلى تجهيزات مختلفة، وموارد أعلى، وبيئات معزولة أكثر صرامة. لا يكفي نسخ رقم من صفحة نتائج إلى لوحة داخلية ثم تسميته اختبارًا مستقلًا؛ فالتقييم يبدأ عندما تصبح هناك ملفات تشغيل وسجلات وأحكام ونسخة مثبتة من الكود يمكن مراجعتها. [2][5]

#ما الذي يجب أن يُرفق بكل نتيجة قبل نشرها؟

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

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

#من البنش مارك إلى الحوكمة: متى تتحول القدرة إلى مخاطرة؟

من منظور Governance, Risk and Compliance (GRC)، هناك سؤالان مستقلان: ما الذي يستطيع النموذج فعله؟ وما الذي نسمح له بفعله؟ قد يحقق نموذج درجة مرتفعة في اختبارات تطوير الاستغلالات، بينما يكون مناسبًا تمامًا لتحليل التصحيحات داخليًا إذا كانت صلاحياته محدودة وتوجد مراجعة بشرية. وبالعكس قد يشكل نموذج متوسط القدرة خطرًا غير مقبول إذا مُنح الوصول إلى بيانات حساسة وأوامر إنتاجية واتصالات خارجية بلا قيود.

يساعد إطار NIST AI RMF على تنظيم هذا النقاش عبر وظائف GOVERN وMAP وMEASURE وMANAGE: تحديد المسؤوليات والسياق، وقياس القدرة والقيود، ثم ربط النتائج بإجراءات معالجة المخاطر ومراجعتها. كما يوفر MITRE ATLAS تصنيفًا للأساليب التي تستهدف أنظمة الذكاء الاصطناعي أو تستفيد من قدراتها في السلوك العدائي؛ وهذا يختلف عن بنش ماركات القدرة السيبرانية، لكنه يكملها عند بناء نموذج التهديد والضوابط. [12][13]

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

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

#ما الذي يمكن أن يجعل بنش مارك قويًا يبدو مضللًا؟

أول مصدر للتضليل هو Benchmark Contamination: أن تكون الإجابات، أو تفاصيل التحديات، أو PoCs المرجعية قد تسربت إلى التدريب أو إلى سياق الوكيل. الثاني هو Harness Advantage: أن يحصل نموذج على أدوات بحث أو ذاكرة أو إعادة محاولة لا يحصل عليها الآخر. الثالث هو Benchmark Saturation: أن تصبح معظم المهام سهلة على النماذج الحديثة، فتصغر فروق الأداء حتى لو اختلفت القدرات الحقيقية في المسائل الأصعب.

المصدر الرابع هو إساءة قراءة المقام. 105 مهمة ناجحة لا تعني 105%، و54.4% تغطية لا تعني 54.4% تنفيذًا كاملًا، ونجاح مرحلة إعادة الإنتاج لا يعني نجاح سلسلة الاستغلال كلها. والمصدر الخامس هو تجاهل الإصدار: تغيير صورة Docker أو قاعدة الحكم أو طريقة التعامل مع أخطاء التنفيذ قد يجعل نتائج قديمة غير قابلة للمقارنة بأخرى جديدة، حتى لو ظل اسم الاختبار كما هو. وقد وثق مشروع Inspect Evals بالفعل تعديلات على مقيم CyberGym شملت تصحيح اختيار ملف إثبات الثغرة ومعالجة مخرجات التنفيذ الكبيرة. [4]

لذلك عندما يظهر نموذج في المرتبة الأولى، لا يكفي السؤال: «كم درجته؟». السؤال الأكثر أهمية: بأي بيانات، وأي أدوات، وأي ميزانية، وأي معيار نجاح، وتحت أي ضوابط اختُبر؟

#الخلاصة: الرقم لا يخبرك بكل القصة

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

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

#المصادر والمراجع

1. CyberGym — المشروع البحثي والشرح الرسمي — تعريف المهمة والبيانات وطريقة التحقق من إعادة الإنتاج.
2. ExploitGym — المشروع البحثي والشرح الرسمي — توزيع 869 مهمة ومعيار الاستغلال المقصود وقيود البيئة.
3. Z.ai — GLM-5.3: Frontier Coding with Emergent Cyber Capabilities وبطاقة النموذج التقنية — النتائج المنشورة وإعدادات التقييم.
4. Inspect Evals — تنفيذ CyberGym وتوثيق التشغيل — مستويات المهام وبنية الحاويات وسجل تغييرات المقيم.
5. ExploitBench — الموقع والمقاييس الرسمية — مهام V8 وطبقات القدرات وقواعد الحكم.
6. Anthropic — Measuring LLMs’ Ability to Develop Exploits — شرح طبقات ExploitBench والفرق بين إثبات الخلل وتنفيذ الاستغلال.
7. Anthropic — GLM-5.3 and the Spread of Advanced Cyber Capabilities — مقارنة منفصلة لمعدلات الاستغلال النهائي.
8. NIST CAISI — Assessment of Z.ai GLM-5.3 Cyber Capabilities — نتائج مستقلة وفواصل الثقة ونموذج IRT.
9. Anthropic — Demystifying Evals for AI Agents — تباين النتائج ومعايير الثبات والمحاولات المتعددة.
10. Inspect AI — منصة التقييم وتوثيق موفري النماذج — تشغيل التقييمات وتوصيل واجهات النماذج.
11. Z.ai — توثيق إعدادات الربط بمزود النموذج — عنوان واجهة Z.ai المناسبة للاستخدام.
12. NIST — AI Risk Management Framework Core — وظائف الحوكمة والقياس وإدارة المخاطر.
13. MITRE ATLAS — Adversarial Threat Landscape for Artificial-Intelligence Systems — تصنيف التهديدات والتقنيات المتصلة بأنظمة الذكاء الاصطناعي.