💬 NLP

SecureForge: Finding and Preventing Vulnerabilities in LLM-Generated Code via Prompt Optimization

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

المؤلفون الأصليون: Houjun Liu, Lisa Einstein, John Yang, Joachim Baumann, Duncan Eddy, Christopher D. Manning, Mykel Kochenderfer, Diyi Yang

نُشر 2026-05-12

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

CC BY 4.0

المؤلفون الأصليون: Houjun Liu, Lisa Einstein, John Yang, Joachim Baumann, Duncan Eddy, Christopher D. Manning, Mykel Kochenderfer, Diyi Yang

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

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

هذه هي المشكلة التي يحلها SecureForge.

إليك شرح الورقة البحثية بكلمات بسيية، باستخدام التشبيهات لجعل الأمر واضحًا.

المشكلة: "الشق الخفي"

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

وجد الباحثون أنه حتى عندما أخبروا الذكاء الاصطناعي صراحةً: "يرجى كتابة كود آمن وتجنب هذه الأخطاء الأمنية المحددة"، لا يزال الذكاء الاصطناعي يخطئ بنسبة 23% تقريبًا.

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

الحل: SecureForge

ابتكر المؤلفون أداة تسمى SecureForge. بدلاً من محاولة إعادة تدريب الروبوت (وهو أمر مكلف وصعب)، قاموا بإنشاء "كتيب تعليمات" (System Prompt) يقرأه الروبوت قبل أن يبدأ العمل.

يعمل SecureForge عبر ثلاث خطوات بسيطة، مثل محقق يحل قضية:

الخطوة 1: الفخ (إيجاد الأخطاء)

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

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

الخطوة 2: غرفة الصدى (تضخيم الأخطاء)

بمجرد العثور على طلب واحد يتسبب في خطأ، لا يتوقفون عند هذا الحد. يستخدمون تقنية تسمى MCMC (سلسلة ماركوف مونت كارلو).

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

الخطوة 3: التدريب (تحسين التعليمات)

الآن، يأخذ SecureForge هذه المكتبة الضخمة من سيناريوهات الفشل ويعلم الذكاء الاصطناعي كيفية تجنبها. يستخدم خوارزمية جينية (عملية تطور رقمية) لتعديل التعليمات التي يقرأها الذكاء الاصطناعي.

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

النتائج: أقوى وأذكى

اختبرت الورقة البحثية هذا على أكثر نماذج الذكاء الاصطناعي تقدمًا المتاحة (مثل GPT-5 وClaude).

قبل SecureForge: كان الذكاء الاصطناعي يرتكب أخطاء أمنية بنسبة 23% تقريبًا، حتى عند أمره بأن يكون آمنًا.
بعد SecureForge: انخفضت الأخطاء بنسبة تصل إلى 48%.
الجزء الأفضل: لم يصبح الذكاء الاصطناعي أسوأ في وظيفته الفعلية. بل ظل يجتاز جميع اختبارات الكود الخاصة به. في الواقع، أصبح أفضل في كونه آمنًا ومفيدًا في نفس الوقت.

لماذا هذا مهم؟

معظم الأدوات الأمنية تحاول رصد الكود السيئ بعد كتابته (مثل مدقق الأخطاء الإملائية). أما SecureForge فيقوم بتغيير التعليمات التي يتبعها الذكاء الاصطنا_ي _قبل أن يكتب سطرًا واحدًا من الكود.

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

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

ملخص تقني: SecureForge

بيان المشكلة

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

تعاني النهج الحالية للتخفيف من هذه المخاطر من فجوات كبيرة:

نماذج تهديد غير متوافقة: تعتمد عمليات اختبار الاختراق (Red-teaming) السابقة غالباً على مطالبات عدائية لا تعكس التفاعلات النموذجية للمستخدمين مع مهام البرمجة الحميدة.
تغطية غير كافية: تفشل السيناريوهات المصممة يدوياً والتي تستهدف تصنيفات محددة من الـ CWE (Common Weaknesses Enumerations) في توصيف المجال الكامل للمطالبات الحميدة التي قد تؤدي عن غير قصد إلى إنتاج كود معرض للاختراق.
عوائق النشر: تتطلب طرق التحصين الحالية وصولاً إلى الأوزان (weights) في الصندوق الأبيض لإجراء الضبط الدقيق (fine-tuning) أو ضبط البادئة (prefix tuning)، وهو أمر لا يمكن للمطورين الذين يستخدمون نماذج مغلقة الأوزان عبر واجهة برمجة التطبيقات (API) الوصول إليه. علاوة على ذلك، فإن الضبط الدقيق ينطوي على مخاطر حدوث تحولات في التوزيع (distribution shifts) مما يؤدي إلى تدهور القدرات البرمجية العامة.

هناك نقص في نهج مؤتمت، سهل النشر، يعمل في وقت الاستنتاج (inference-time) لقياس ومنع إدخال نقاط الضعف الشائعة في الأكواد التي تولدها النماذج الرائدة دون الحاجة إلى تحديث أوزان النموذج.

المنهجية: خط إنتاج SecureForge

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

1. التكذيب بضربة واحدة (الاكتشاف)

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

توليد المطالبات: بدءاً من قاعدة بيانات MITRE CWE، يقوم النظام بتوليد مهام برمجية واقعية تستخدم مكتبات محددة مرتبطة بنقاط ضعف معروفة (مثل حقن SQL في Django).
التصفية الحميدة: يتم تنقيح هذه المطالبات لإزالة أي ذكر صريح للهجمات، أو الثغرات، أو الـ CWEs. يتم توجيه المولد لاستخدام لغة جودة الإنتاج (على سبيل المثال، "تأكد من تطهير المدخلات بشكل صحيح") لضمان أن تبدو المطالبات كطلبات مستخدم قياسية.
التقييم: يقوم النموذج المستهدف بتوليد كود لهذه المطالبات عند درجة حرارة (temperature) تبلغ 1.0. يتم تحليل المخرجات باستخدام Semgrep (أداة تحليل ثابت). المطالبات التي ينتج عنها كود يجتاز اختبارات الوحدة (unit tests) ولكنه يفشل في التحليل الثابت (مما يؤدي لتفعيل ثغرة) يتم الاحتفاظ بها كمطالبات بذرية "مكذبة" (falsified).

2. اكتشاف توزيع الفشل (التضخيم)

للتغلب على ندرة أمثلة الفشل الأولية وضمان التنوع، يستخدم SecureForge أخذ عينات من خلال "سلاسل ماركوف مونت كارلو" (MCMC)، وتحديداً باستخدام معيار "Metropolis-Hastings" (MH).

الهدف: أخذ عينات من التوزيع الشرطي للفشل $p(\cdot | F_j)$ ، حيث $F_j$ هو نوع ضعف محدد.
العملية: بدءاً من مطالبة بذرية، يقوم نواة استكشاف (kernel) (وهو نموذج لغوي لإعادة صياغة المطالبة) بتوليد متغيرات مرشحة. يتم تحديد قبول مطالبة جديدة $x'$ بناءً على نسبة احتمال فشلها غير المعاير $\bar{p}(x')$ إلى احتمال المطالبة الحالية، مع تعديلها بواسطة نواة الانتقال.
تقدير الاحتمال: يتم تقدير احتمال الفشل $p_{fail}(x)$ عن طريق تشغيل المطالبة عدة مرات وملاءمة توزيع "بيتا" (Beta distribution) لعدات النجاح/الفشل حتى يتقارب التباين تحت عتبة معينة.
النتيجة: تعمل هذه العملية على تضخيم مجموعة صغيرة من المطالبات البذرية إلى مجموعة ضخمة ومتنوعة من المطالبات الاصطناعية (80,000 مطالبة) تحافظ على معدلات عالية من الثغرات مع استكشاف توزيع الفشل.

3. التحصين عبر تحسين المطالبة

تعمل المرحلة النهائية على تحسين "مطالبة النظام" (system prompt) لتقليل احتمال توليد كود غير آمن دون تعديل أوزان النموذج.

خوارزمية التحسين: يستخدم خط الإنتاج GEPA (Genetic-Pareto)، وهي خوارزمية جينية من الدرجة صفر تستخدم التأمل الذاتي (self-reflection).
العملية: بدءاً من مطالبة نظام عامة، تقوم GEPA بتوليد مطالبات نظام مرشحة بشكل تكراري. يتم تقييم كل مرشح مقابل المجموعة الكاملة من مطالبات الفشل الاصطناعية.
دالة اللياقة (Fitness Function): تقوم الخوارزمية بتقليل إجمالي احتمال الفشل عبر المجموعة مع الحفاظ على الصحة الوظيفية (اجتياز اختبارات الوحدة).
حلقة التغذية الراجعة: يوفر المحلل الثابت إشارة (±1 درجة) بناءً على ما إذا كان الكود المولد يحتوي على ثغرات. يتم تحوير مطالبة النظام واختيارها بناءً على "الأمثلية الباريتية" (Pareto optimality)، مما يوازن بين الأمن والقدرة.

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

التوصيف التجريبي للإخفاقات الحميدة: يوضح المؤلفون أن النماذج الرائدة تولد أكواداً غير آمنة حتى عندما يُطلب منها صراحة أن تكون آمنة وتُزود بسياق CWE. وجدوا أن 12.7% من المخرجات هي ثغرات وفي نفس الوقت تجتاز اختبارات الوحدة، مما يسلط الضوء على "خفاء" هذه الإخفاقات.
التضخيم القائم على MCMC: يقدم البحث طريقة لتوسيع أمثلة التكذيب الفردية إلى مجموعة متنوعة من سيناريوهات الفشل باستخدام MCMC. تظهر دراسات الاستئصال (Ablation studies) أن هذه الطريقة تكتشف مطالبات ثغرات جديدة بنجاح أكبر بمرتين مقارنة بإعادة الصياغة البسيطة.
التحصين في وقت الاستنتاج: يوفر SecureForge حلاً قابلاً للنشر يحسن الأمن عبر تحسين مطالبة النظام وحدها. لا يتطلب الأمر ضبطاً دقيقاً، أو وصولاً للأوزان، أو التعرض لتوزيعات مطالبات المستخدمين الحقيقية أثناء مرحلة التحسين.
مجموعة أدوات مفتوحة المصالم: يطلق المؤلفون مجموعة أدوات (secureforge) تعمل على أتمتة خط الإنتاج بالكامل، بدءاً من توليد مطالبات الفشل الحميدة وصولاً إلى تحسين مطالبات النظام عبر واجهة برمجة التطبيقات أو النشر المحلي.

النتائج

أُجري التقييم على مجموعة من النماذج مفتوحة المصدر (Qwen, CodeLlama, Kimi) والنماذج المغلقة الرائدة (سلسلة GPT-5، وClaude Sonnet 4.6).

تقليل الثغرات: حقق SecureForge انخفاضاً ذا دلالة إحصائية في معدلات الثغرات، مع حد أقصى للانخفاض بلغ 48% عبر النماذج المختبرة.
تحسين باريتو (Pareto Improvement): أدت مطالبات النظام المحسنة إلى تحسين مشترك في كل من معدلات نجاح اختبارات الوحدة وأمن المخرجات. انتقلت النماذج بشكل ملحوظ نحو الربع "الأكثر أماناً" في مخطط (اجتياز الاختبار، الأمن) دون تدهور في القدرة البرمجية.
النقل الصفري (Zero-Shot Transfer): انتقلت مطالبات النظام التي تم تحسينها على بيانات اصطناعية بفعالية إلى مطالبات وكلاء البرمجة الواقعية "في العالم الحقيقي" من مجموعة بيانات SWE-chat. حدث هذا الانتقال دون أي تعرض لتوزيعات مطالبات المستخدمين الحقيقية أثناء مرحلة التحسين، مما أدى لتحسين المعدل المشترك لاجتياز الاختبار والأمن بنسبة تصل إلى 13.5% في المهام الواقعية.
المقارنة مع الخطوط المرجعية: فشلت استراتيجيات المطالبة البسيطة (مثل طلب كود آمن أو سرد الـ CWEs) في تقليل معدلات الثغرات بنفس قدر SecureForge، حيث تركت معدلات ثغرات مزدوجة الأرقام حتى في السيناريوهات التي تجتاز الاختبارات.

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

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

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

يؤكد العمل أنه بينما يقتصر التقييم الحالي على توليد كود Python أحادي الدور، فإن خط الإنتاج يوفر إطاراً عاماً لاكتشاف وتقليل عدم الأمان البرمجي في النماذج الرائدة، مما يتطلب فقط تحليلاً ثابتاً للحقيقة الأرضية (ground-truth) ولا يتطلب أي تسمية بشرية (human annotation).