Evaluating and Preventing Security Smells in AI-Generated Ansible Code

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

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

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

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

عندما طبق الباحثون هذا النهج المهيكل، تحسنت النتائج بشكل كبير. تمكنت أربعة من النماذج الستة عشر من اتباع التعليمات المعقدة وتوليد كود خالٍ من الثغرات الأمنية التي ظهرت في الجولة الأولى. أما النموذج الأفضل أداءً، فقد أنتج كودًا استوفى ما بين 95 و100 بالمائة من المعايير الأمنية الصارمة، وهي قفزة هائلة من المستوى الأساسي. وفي الواقع، تفوق نموذج الذكاء الاصطناعي الأعلى أداءً على متوسط الكود الذي كتبه البشر، والذي استوفى فقط ما بين 23 و43 بالمائة من المعايير نفسها. أظهرت الدراسة أنه بالنسبة لهذه النماذج القادرة، لم تكن المشكلة تكمن في نقص المعرفة، بل في الفشل في تطبيق تلك المعرفة عندما تكون التعليمات غامضة. فعندما كانت القواعد واضحة والقيود صريحة، استطاع الذكاء الاصطناعي دمج كود آمن وعالي الجودة في محاولة واحدة، مما ألغى الحاجة إلى الإصلاحات المستهلكة للوقت بعد كتابة الكود بالفعل.

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

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