💻 computer science

AutoBaxBuilder: Bootstrapping Code Security Benchmarking

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

المؤلفون الأصليون: Tobias von Arx, Niels Mündler, Mark Vero, Maximilian Baader, Martin Vechev

نُشر 2026-05-22

📖 4 دقيقة قراءة☕ قراءة في استراحة قهوة

CC BY 4.0

المؤلفون الأصليون: Tobias von Arx, Niels Mündler, Mark Vero, Maximilian Baader, Martin Vechev

البحث الأصلي مرخَّص بموجب CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل

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

لذلك، عليك إعداد "امتحان نهائي" (معيار قياس) لا يتحقق فقط مما إذا كان الكود يعمل، بل يتحقق أيضاً مما إذا كان آمناً.

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

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

الحل: AUTOBAXBUILDER (مصنع الامتحانات ذاتي التكرار)
قام المؤلفون ببناء نظام جديد يسمى AUTOBAXBUILDER. فكر في هذا النظام كـ "مصنع امتحانات" مدعوم بالذكاء الاصطناعي يمكنه بناء اختباراته الأمنية الخاصة من الصفر، دون الحاجة إلى إنسان يمسك بالقلم.

إليك كيف يعمل المصنع، خطوة بخطوة، باستخدام تشبيه بسيط:

1. المهندس المعماري (توليد السيناريو)

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

2. البنّاء والمفتش (الاختبارات الوظيفية)

بعد ذلك، يطلب النظام من عدة "بنائين" يعملون بالذكاء الاصطناست بناء التطبيق بناءً على تلك الفكرة الجديدة.

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

3. المخترق (الثغرات الأمنية)

هذا هو الجزء الأكثر أهمية. بمجرد أن يصبح المبنى متيناً، يرتدي النظام "قبعة المخترق".

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

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

السرعة والتكلفة: بدلاً من استغراق إنسان 3 ساعات لبناء امتحان واحد، يقوم المصنع بذلك في أقل من ساعتين بتكلفة تقل عن 4 دولارات. لقد قلل ذلك من الجهد البشري بمقدار 12 مرة.
الجودة: عندما قارنوا امتحانات المصنع بالامتحانات القديمة التي صنعها البشر، وجدوا أن امتحانات المصنع كانت بنفس الجودة، ولكنها غالباً ما كانت أكثر صرامة. لقد اكتشفت ثغرات أمنية أكثر مما فات خبراء البشر.
اختبار الواقع: عندما اختبروا أذكى نماذج البرمجة بالذكاء الاصطناعي في العالم على هذه الامتحانات الجديدة، كانت النتائج صادمة. حتى أفضل النماذج لم تتمكن من اجتياز سوى حوالي 36% من الاختبارات الأمنية. وهذا يعني أنه رغم براعة الذكاء الاصطناعي في كتابة كود "يعمل"، إلا أنه لا يزال سيئاً جداً في كتابة كود "آمن".

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

ملخص تقني: AUTOBAXBUILDER

بيان المشكلة

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

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

غالباً ما تقيم المعايير المرجعية الحالية الصحة والأمن في مهام منفصلة أو تركز فقط على توليد الدوال (function-level)، وتفشل في استيعاب تعقيدات الأنظمة الخلفية (backends) للتطبيقات الكاملة. وبينما عالج معيار BAXBENCH ذلك من خلال تقييم الأنظمة الخلفية لتطبيقات الويب من البداية إلى النهاية، إلا أن إنشاؤه اعتمد بشكل كبير على الجهد البشري اليدوي، مما حد من استدامته وقابليته للتوسع.

المنهجية: AUTOBAXBUILDER

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

يعمل المسار عبر ثلاث خطوات صقل تكرارية، يديرها نموذج لغوي مركزي ("المنظم" - Orchestrator) ويتم التحقق منها مقابل الحلول المرجعية التي تولدها "نماذج الحلول" (Solution LLMs):

اقتراح السيناريو: يقوم المنظم بتوليد مواصفات خدمة خلفية مبتكرة (بتنسيق OpenAPI) مصممة للكشف عن سطح هجوم واضح. ويضمن الحداثة من خلال التحقق من عناوين السيناريوهات الموجودة. ثم تقوم نماذج الحل الحلول بتوليد تنفيذات مرجعية أولية.
توليد الاختبارات الوظيفية: يستخرج المنظم المتطلبات الوظيفية ويبني اختبارات وظيفية. ولضمان الصحة، يستخدم المسار حلقة صقل ثنائية المراحل:
- صقل الحلول: يتم تصحيح الحلول المرجعية الفاشلة بناءً على سجلات التنفيذ، دون أن يرى المنظم كود الاختبار لمنع الإفراط في التخصيص (overfitting).
- صقل الاختبارات: يحلل المنظم العلاقة بين كود الاختبار، وكود الحل، وسجلات التنفيذ لتحديد ما إذا كان الفشل ناتجاً عن اختبار معيب أم حل معيب. ويستمر في التكرار حتى يتم التوصل إلى إجماع عالمي، مما يضمن مرور حل مرجعي واحد على الأقل بجميع الاختبارات.
توليد الثغرات الأمنية: يحدد المنظم الثغرات المحتملة (CWEs) في السيناريو والحلول المرجعية. ولكل ثغرة مستهدفة، يقوم بتوليد ثغرة (exploit) ويتحقق منها باستخدام نهج مقارن:
- يتم تشغيل الثغرة على حل مرجعي.
- إذا كانت النتيجة صحيحة (على سبيل المثال، تم تحديد الحل المعيب)، يقوم المنظم بتوليد حل "مضاد" عن طريق إما إصلاح الثغرة أو إدخالها، بناءً فقط على الوصف اللغوي الطبيعي للثغرة (وليس منطق الثغرة نفسها).
- يتم قبول الثغرة فقط إذا نجحت في التمييز بدقة بين النسخ الآمنة وغير الآمنة من الحل. وتتكرر هذه العملية حتى يتم العثور على زوج دقيق من الحلول الآمنة وغير الآمنة.

يتضمن المسار ضوابط مثل التحقق من تنسيق YAML لمواصفات OpenAPI، وفحوصات تجميع Python للكود، وآليات النقد الذاتي للتعامل مع إخفاقات النماذج اللغوية الكبيرة.

المساهمات الرئيسية

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

النتائج التجريبية

قيم المؤلفون المسار ومعيار AUTOBAXBENCH الناتج باستخدام مجموعة واسعة من النماذج اللغوية الكبيرة الحديثة (بما في ذلك GPT-5، وClaude 4.5 Sonnet، وGemini 3 Pro، ونماذج متنوعة ذات أوزان مفتوحة).

التحقق من المسار: عند تطبيقه على سيناريوهات BAXBENCH الحالية، أظهرت الاختبارات والثغرات المولدة بواسطة AUTOBAXBUILDER توافقاً عالياً مع تلك المكتوبة بشرياً. وتحديداً، تطابقت الاختبارات الوظيفية في 80.9% من الحلول. كما أن الثغرات الأمنية التي ولدها المسار حددت حالات غير آمنة أكثر من الثغرات البشرية الأصلية، ويعزى ذلك إلى اكتشاف المزيد من الـ CWEs ومتغيرات الهجوم. وقد وجدت عملية التدقيق اليدوي لـ 71 ثغرة مولدة ثغرة واحدة فقط غير سليمة.
أداء المعيار المرجعي: في AUTOBAXBENCH، حقق أقوى نموذج تم تقييمه (Claude 4.5 Sonnet) نسبة sec_pass@1 إجمالية (نسبة الحلول الآمنة والصحيحة) بلغت 36% فقط. وفي المجموعة "الصعبة"، انخفضت هذه النسبة إلى 25%. وتبرز الفجوة بين pass@1 (الصحة الوظيفية) و sec_pass@1 أن العديد من التنفيذات الصحيحة وظيفياً تظل قابلة للاختراق.
الكفاءة: يولد المسار مهاماً جديدة في أقل من ساعتين بتكلفة API تقل عن 4 دولارات لكل مهمة. وبإضافة التحقق اليدوي، يقلل هذا من الجهد البشري بمقدار 12 ضعفاً مقارنة بالبناء اليدوي.
المتانة: أظهرت دراسات الاستئصال (Ablation studies) باستخدام مجموعات منفصلة من النماذج المستخدمة في البناء ارتباطاً رتبوياً عالياً (Spearman $\rho > 0.9$ ) في أداء النماذج، مما يشير إلى أن المعيار ليس منحازاً للنماذج المستخدمة لتوليده.

الأهمية والادعاءات

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

يؤكد المؤلفون أن طريقتهم توفر حداً أقصى سليماً للأمن باستخدام ثغرات قائمة على التنفيذ بدلاً من التحليل الساكن (static analysis)، الذي يميل إلى كثرة النتائج الإيجابية والسلبية الخاطئة. ويؤكدون أن الإطار "مقاوم للمستقبل"، وقادر على توليد مهام تزدح في الصعوبة مع تحسن قدرات النماذج، مقترباً من تعقيد واجهات برمجة التطبيقات (APIs) الخلفية المستخدمة في الواقع. ويخلص العمل إلى أنه بينما أحرزت النماذج اللغوية تقدماً في توليد الكود الوظيفي، لا تزال هناك فجوة كبيرة في قدرتها على توليد كود آمن بشكل موثوق، وهي الفجوة التي يكشفها AUTOBAXBENCH بفعالية.