Prompt Structure Redistributes, Not Reduces: An Empirical Analysis of Security-Weaknesses in LLM-Generated Python Code
تُظهر هذه الدراسة التجريبية أنه في حين أن المطالبات المهيكلة والموجهة نحو الأمن تُحسن بشكل كبير من امتثال النماذج اللغوية الكبيرة وتُقلل من المخرجات غير الصالحة، إلا أنها تفشل باستمرار في خفض الانتشار العام للثغرات الأمنية في لغة بايثون المُولدة، بل غالبًا ما تعيد توزيع المخاطر عبر تحويل الثغرات عالية الخطورة إلى أخرى منخفضة الخطورة وتتسبب في انحراف دلالي يغير الوظائف المطلوبة بصمت.
البحث الأصلي مرخَّص بموجب CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل
في المشهد الحديث لإنشاء البرمجيات، ظهر نوع جديد من المساعدين: النماذج اللغوية الكبيرة. هذه برامج حاسوبية قوية تم تدريبها على كميات هائلة من النصوص، وهي قادرة على كتابة كود برمجي عند طلب ذلك بلغة إنجليزية بسيطة. يستخدم المطورون هذه النماذج لتسريع عملهم، حيث يكتبون وصفاً لمهمة ما ويتلقون في المقابل كتلة من الكود البرمجي. ومع ذلك، تماماً كما قد يدرج كاتب بشري عن غير قصد فكرة خطيرة إذا لم يتم توجيهه بعناية، يمكن لهذه الآلات أن تنتج كوداً يحتوي على ثغرات أمنية خفية. ولمنع حدนี้، يستخدم المهندسون تقنية تسمى "هندسة الأوامر" (prompt engineering)، والتي تتضمن صياغة تعليمات محددة لتوجيه النموذج نحو نتائج أكثر أماناً. وكان الأمل السائد هو أنه بمجرد مطالبة النموذج بأن يكون أكثر حذراً أو من خلال توفير قالب مهيكل لاستجابته، يمكننا تقليل عدد الثغرات الأمنية في البرمجيات التي ينشئها بشكل كبير.
لقد وضع فريق من الباحثين هدفاً لاختبار ما إذا كان هذا الأمل مبرراً تماماً. فقد ركزوا على سؤال جوهري: هل إضافة المزيد من الهيكلية والتحذيرات الأمنية إلى التعليمات يجعل الكود أكثر أماناً بالفعل، أم أنه يغير فقط الطريقة التي يبدو بها الكود؟ ولإيجاد الإجابة، أجروا تجربة واسعة النطاق باستخدام نموذجين مختلفين من الذكاء الاصطناعي، أحدهما من شركة تكنولوجية كبرى والآخر مفتوح للاستخدام العام. وقد طلبوا من هذين النموذجين حل 424 مهمة برمجية محددة معروفة بأنها عرضة للمخاطر الأمنية، مثل التعامل مع الملفات أو إدارة بيانات المستخدمين. ولكل مهمة، جربوا خمس نسخ مختلفة من التعليمات، تتراوح من طلب بسيط إلى أمر مفصل للغاية يتضمن قواعد صارمة بشأن المعايير الأمنية وتحذيرات ضد المدخلات الضارة.
نظر الباحثون أولاً فيما إذا كانت النماذج ستحاول حتى كتابة الكود. فعندما أُعطيت طلباً بسيطاً وغير مهيكل، رفض النموذج الأكثر تقدماً توليد كود لمعظم المهام الحساسة أمنياً، وغالباً ما كان يستجيب برفض مهذب بدلاً من تقديم حل. ومع ذلك، بمجرد أن أضاف الباحثون قالباً مهيكلاً يحدد بوضوح دور مهندس البرمجيات ويحدد بدقة شكل المخرجات، انخفض معدل الرفض بشكل كبير؛ حيث بدأ النموذج في إنتاج كود صالح لكل مهمة تقريباً. هذا النجاح الأولي أشار إلى أن التعليمات المهيكلة ممتازة في جعل الآلة تقوم بعملها، لكن الباحثين كانوا بحاجة لمعرفة ما إذا كان الكود الذي أنتجته آمناً حقاً.
وعندما حللوا الكود الصالح الذي تم توليده، كشفت النتائج عن واقع أكثر تعقيداً. استخدم الباحثون أدوات مسح متخصصة لتحديد نقاط الضعف الأمنية، وتصنيفها حسب مدى خطورتها. ووجدوا أنه بينما قللت الأوامر الأكثر تفصيلاً وتركيزاً على الأمن من عدد العيوب الأكثر خطورة، إلا أنها لم تقضِ على المشكلات تماماً. بدلاً من ذلك، تغيرت طبيعة العيوب؛ إذ يبدو أن التعليمات دفعت النموذج لتجنب الأخطاء الأكثر وضوحاً وخطورة، ولكن في سبيل القيام بذلك، غالباً ما استبدلها بمشكلات أقل خطورة، لكنها لا تزال موجودة. بالنسبة للنموذج الأكثر تقدماً، انخفضت نسبة الأخطاء عالية المخاطر بشكل ملحوظ، لكن نسبة الأخطاء منخفضة المخاطر ارتفعت. كان الأمر كما لو أن التعليمات لم تنظف الغرفة، بل قامت ببساطة بنقل الأوساخ من منتصف الأرضية إلى الزوايا.
ولعل الاكتشاف الأكثر إثارة للدهشة كان ظاهرة أطلق عليها الباحثون اسم "الانزياح الدلالي" (semantic drift). ففي حالات عديدة، عندما أصبحت التعليمات أكثر صرامة بشأن الأمن، قامت النماذج بصمت بتغيير طريقة حلها للمشكلة لتلبية قواعد السلامة، حتى عندما تتطلب المهمة الأصلية نهجاً معيناً قد يكون محفوفاً بالمخاطر. على سبيل المثال، إذا طلبت مهمة من النموذج استخدام طريقة معينة لتشغيل أوامر النظام، فإن أمراً أمنياً صارماً قد يتسبب في قيام النموذج باستبدال تلك الطريقة ببديل أكثر أماناً يحل المشكلة تقنياً ولكنه ينتهك المتطلبات المحددة. حدث هذا في حوالي ثلثي المهام بالنسبة للنموذج المتقدم عند استخدام التعليمات الأمنية الأكثر صرامة، بينما أظهر النموذج مفتوح المصدر معدلاً أقل بكثير من مثل هذه التغييرات. لقد كان الكود أكثر أماناً في نظر أدوات المسح، ولكنه لم يعد مطابقاً تماماً لما طلبه المطور.
كما سلطت الدراسة الضوء على أن هذه التأثيرات لم تكن متساوية لكل نموذج. فبينما أظهر النموذج المتقدم تحولاً واضحاً في كيفية تعامله مع المخاطر، استجاب النموذج مفتوح المصدر بشكل أقل اتساقاً، حيث ظلت عيوبه الأمنية مستقرة نسبياً بغض النظر عن كيفية صياغة التعليمات. علاوة على ذلك، لاحظ الباحثون أن أدوات المسح التي استخدموها، رغم فعاليتها في رصد الأنماط الشائعة، لم تستطع اكتشاف كل خطر محتمل. فبعض المخاطر تعتمد على كيفية سلوك الكود أثناء التشغيل أو على السياق المحدد الذي يُستخدم فيه، وهي مجالات غالباً ما تغفلها أدوات المسح الساكنة. وهذا يعني أن عدد العيوب التي تم العثور عليها كان على الأرجح تقديراً متحفظاً، وأن الخطر الحقيقي قد يكون أعلى.
في نهاية المطاف، تشير الأبحاث إلى أنه بينما تعد كتابة تعليمات أفضل أداة قوية لجعل الذكاء الاصطناعي يولد كوداً، إلا أنها ليست حلاً كاملاً للأمن. فالأوامر المهيكلة تعمل أشبه بمرشح (فلتر) يغير توزيع المخاطر بدلاً من كونها درعاً يزيلها. وهي فعالة للغاية في ضمان اتباع الآلة للقواعد وإنتاج المخرجات، ويمكنها تقليل شدة الأخطاء الأكثر خطورة. ومع ذلك، فهي لا تضمن أن يكون الكود خالياً من الثغرات، ولا تضمن بقاء الكود وفياً للهدف الأصلي للمطور. وتشير النتائج إلى أن الاعتماد فقط على كيفية صياغة الطلب أمر غير كافٍ؛ إذ لا يزال الأمن القوي يتطلب مراجعة بشرية وطبقات حماية إضافية تتجاوز الأمر الأولي.
غارق في أبحاث مجالك؟
تصلك نشرة يومية بأحدث الأبحاث المطابقة لكلماتك البحثية المفتاحية — مع ملخصات تقنية، بلغتك.