وكلاء الذكاء الاصطناعي المخصصون لمراجعة الأكواد قد يتحولون إلى بوابة هجوم، إذ يمكن خداعهم لتشغيل كود خبيث أثناء فحص مشاريع مفتوحة المصدر.
ما هي ثغرة Friendly Fire في وكلاء الذكاء الاصطناعي؟
تكشف التجربة مفهوما هجوميا يحمل اسم Friendly Fire، ويستهدف أدوات برمجية تعتمد على التنفيذ الذاتي للأوامر. الفكرة خطيرة لأنها تضرب المهمة الأساسية لهذه الأدوات: البحث عن الثغرات، لا تشغيلها.
في السيناريو المعروض، يطلب المستخدم من الوكيل فحص مشروع مفتوح المصدر بحثا عن مشاكل أمنية. لكن بدلا من اكتشاف الخطر فقط، يقرأ الوكيل تعليمات مضمنة داخل ملفات المشروع ثم ينفذها على جهازه المضيف.
لماذا تبدو المشكلة مقلقة؟
- الهجوم لا يحتاج إلى استغلال تقني معقد داخل نظام التشغيل نفسه.
- الاعتماد يكون على ثقة الوكيل في أوامر يراها جزءا من مهمة المراجعة.
- الخطر يظهر تحديدا عند فحص كود غير موثوق مع تفعيل الأوضاع الذاتية.
كيف تُخدع كلود كود وكوديكس لتشغيل كود خبيث؟
وفق التفاصيل التي راجعتها تيكبامين، تم اختبار الهجوم على وضعي تشغيل ذاتيين في كلود كود وكوديكس. هذان الوضعان يسمحان للوكيل بتنفيذ الأوامر التي يصنفها على أنها آمنة، مع التوقف فقط عند الأوامر التي يراها عالية الخطورة.
المهاجم يضيف داخل مكتبة مفتوحة المصدر ملفات تبدو اعتيادية، بينها ملاحظة داخل README.md توصي بتشغيل سكربت أمني قبل فتح طلب سحب. عند مطالبة الوكيل بإجراء اختبار أمني للمشروع، يقرأ README ويعتبر السكربت جزءا من خطوات الفحص الطبيعية.
- ملف README.md يحتوي تعليمات تبدو مشروعة.
- سكربت باسم security.sh يعمل كخطوة تمويه.
- حمولة خفية تنطلق في الخلفية بعد تنفيذ السكربت.
- ملف ثنائي مموه ليبدو كأنه ناتج بناء لملف Go بريء.
لماذا لا يكفي التحديث الأمني لإغلاق الخطر؟
المسألة هنا ليست مرتبطة بإصدار واحد أو نسخة بعينها، بل بطريقة تصميم سير العمل نفسه. لذلك لا يوجد تحديث سحري يمكن انتظاره، لأن جوهر المشكلة أن الوكيل يملك صلاحية التنفيذ الذاتي أثناء التعامل مع كود غير موثوق.
بمعنى آخر، إذا كانت الأداة مخولة لتقرر وحدها ما هو آمن، فقد تقع ضحية لملفات تم إعدادها بعناية لتبدو سليمة. وهذا ما يجعل الخطر مرتبطا بالاعتماد الزائد على الأتمتة داخل مراجعات الأمن البرمجي.
متى يصبح الخطر فعليا؟
- عند استخدام وكيل قادر على تشغيل الأوامر.
- عند تفعيل وضع يمنح موافقات تلقائية لبعض العمليات.
- عند فحص مشروع أو مكتبة لا تملك السيطرة الكاملة عليها.
كيف تحمي جهازك عند فحص مشاريع مفتوحة المصدر؟
أفضل خطوة هي تقليل الثقة التلقائية. لا تمنح وكلاء الذكاء الاصطناعي صلاحية تنفيذ أوامر من مشاريع خارجية إلا داخل بيئة معزولة مثل الحاويات أو الآلات الافتراضية.
كما يفضل تعطيل الأوضاع الذاتية عند مراجعة الأكواد الحساسة، ومراجعة ملفات README والسكربتات المساعدة يدويا قبل أي تشغيل. وتوصي تيكبامين أيضا بالفصل بين بيئة التطوير اليومية وبيئة تحليل الأكواد غير الموثوقة.
- استخدم Sandbox أو VM عند الفحص الأمني.
- عطل الموافقات التلقائية كلما أمكن.
- لا تشغل سكربتات الصيانة أو الاختبار دون تدقيق.
- راقب أي ملفات تنفيذية مضافة حديثا داخل المشروع.
الخلاصة أن صعود وكلاء البرمجة بالذكاء الاصطناعي يوفر سرعة كبيرة، لكنه يفتح بابا جديدا للهجمات إذا غابت الضوابط. ومع اتساع الاعتماد على وكلاء الذكاء الاصطناعي في التطوير، تصبح العزلة التشغيلية والمراجعة البشرية شرطين أساسيين لا رفاهية.
