العنوان: أصبحت جلسة مساعد برمجة بالذكاء الاصطناعي هجوماً على سلاسل التوريد
تُظهر أحدث دراسة حالة من Mandiant أن جلسة مساعد برمجة بالذكاء الاصطناعي تم اختراقها سمحت للمهاجم بحقن حزمة مسمومة في قاعدة كود شركة برمجيات، مما أدى إلى اختراق 100 مستودع داخلي، وسرقة رموز GitHub OAuth، وتسريب الكود المصدري والأسرار. يثبت هذا الاختراق أنه لا يمكن للمطورين التعامل مع الاقتراحات التي يولدها الذكاء الاصطناعي ككود آمن.
ماذا حدث
خلال جلسة تطوير مباشرة، سيطر مهاجم على مساعد الذكاء الاصطناعي المدمج في محرر الفريق. ثم اقترح المساعد المخترق حزمة خبيثة. وبسبب ثقة المطور في الأداة، قبل الاقتراح دون إجراء فحوصات إضافية.
قامت الحزمة المسمومة بإسقاط برنامج لسرقة المعلومات (infostealer) قام بجمع رموز GitHub OAuth المخزنة على محطة العمل. وباستخدام تلك الرموز، نشر المهاجم دودة "Shai-Hulud"، التي نسخت نفسها عبر 100 مستودع داخلي. ولأن الكود الخبيث كان يحمل نفس نطاق (namespace) الشركة، فقد أصيب المطورون الآخرون الذين سحبوا نفس الحزم لاحقاً بالعدوى أيضاً.
لماذا يهم هذا الأمر
يمكن لمساعدي البرمجة بالذكاء الاصطناعي قراءة ملفات المشروع، وتوليد أوامر التثبيت، وتحرير ملفات التبعيات (dependency manifests)، وحتى تشغيل أوامر الطرفية (terminal commands). هذا النطاق الواسع من الوصول يجعلها نواقل جذابة لهجمات سلاسل التوريد. عندما يثق المطور في اقتراح الذكاء الاصطناعي أكثر من نصيحة غريب، تصبح مهمة المهاجم أسهل: حيث يمكن للمساعد إدراج كود خبيث يبدو شرعياً بشكل صامت.
تسمح هجمات سلاسل التوريد للمهاجم بالتحرك عرضياً عبر قاعدة كود المؤسسة، وسرقة بيانات الاعتماد، وتسريب الأصول المملوكة — كل ذلك دون أن يلاحظ الضحية حتى يقع الضرر بالفعل.
كيف تطور الهجوم
- اختطاف الجلسة – سيطر المهاجم على جلسة مساعد ذكاء اصطناعي جارية.
- توصية مسمومة – أُجبر المساعد المخترق على اقتراح حزمة خبيثة.
- قبول المطور – لاعتقاده بتوصية الذكاء الاصطناعي، أضاف المطور الحزمة وشغل أمر التثبيت الذي تم توليده.
- تنفيذ الحمولة (Payload) – قامت الحزمة بتثبيت برنامج لسرقة المعلومات قرأ رموز GitHub OAuth المحلية والأسرار الأخرى.
- انتشار الدودة – باستخدام الرموز المسروقة، نشر المهاجم دودة Shai-Hulud، التي انتشرت في 100 مستودع داخلي.
- تسريب البيانات – تم سحب الكود المصدري والمكتبات الداخلية والمفاتيح السرية إلى البنية التحتية للمهاجم.
ما يمكن للمطورين فعله الآن
تعامل مع كل اقتراح من الذكاء الاصطناعي ككود غير موثوق. طبق نفس خطوات التحقق التي تستخدمها لأي تبعية (dependency) من طرف ثالث.
التحقق من صحة الحزمة
- تحقق من الوثائق الرسمية وسجل الإصدارات.
- تأكد من هوية الناشر وسمعته.
- راجع مستودع المصدر والالتزامات (commits) الأخيرة.
- افحص شجرة التبعيات الكاملة بحثاً عن أي روابط غير متوقعة.
- دقق في أي سكربتات تثبيت بحثاً عن أوامر مخفية.
تعزيز التعامل مع بيانات الاعتماد
- امنح أقل صلاحيات ممكنة لكل رمز (token).
- فضل الرموز قصيرة العمر على الرموز طويلة العمر.
- ابقِ أسرار الإنتاج بعيداً عن أجهزة التطوير المحلية.
- قيد وصول إضافات المحرر إلى بيانات الاعتماد التي لا يحتاجونها.
الاستجابة لاختراق مشتبه به
- اعزل البيئة المتضررة فوراً؛ فحذف
node_modulesأو المجلدات المماثلة ليس كافياً. - قم بتدوير (Rotate) جميع بيانات اعتماد GitHub و npm و PyPI والسحابة.
- راجع نشاط المستودع بحثاً عن التزامات (commits) غير متوقعة أو عمليات دمج لطلبات السحب (pull-request merges).
- راجع سجلات CI/CD وسكربتات Git-hook بحثاً عن أي سلوك غير طبيعي.
- اعزل البيئة المتضررة فوراً؛ فحذف
نظرة إلى المستقبل
ستظل مساعدات الذكاء الاصطناعي دفعة قوية للإنتاجية للعديد من المطورين، لكن قوتها تأتي مع تكلفة تتعلق بالثقة. يجب على المؤسسات دمج الكود المولد بواسطة الذكاء الاصطناعي في خطوط مراجعة الأمان الحالية، تماماً كما تفعل مع أي مكتبة خارجية. يمكن لعمليات التحقق الآلية من السياسات، ومخرجات مساعد الذكاء الاصطناعي الموقعة، وعزل وقت التشغيل (runtime sandboxing) أن تقلل من خطر الاختراقات الصامتة.
توضح حالة Mandiant أنه بمجرد اختراق مساعد الذكاء الاصطناعي، يحصل المهاجم على خط مباشر إلى سلسلة توريد البرمجيات. سيكون التعامل مع اقتراحات الذكاء الاصطناعي كجزء من نموذج التهديد — وليس كإذن مفتوح — أمراً ضرورياً للحفاظ على سلامة قواعد الكود.
الخلاصة: التوصية المولدة بواسطة الذكاء الاصطناعي ليست أكثر موثوقية من أي كود آخر من طرف ثالث. تحقق منها، وحدد صلاحياتها، وراقبها بصرامة، وإلا ستخاطر بتحويل مساعد مفيد إلى قناة لاختراق واسع النطاق لسلسلة التوريد.