السكربتات المخفية في المستودعات قد تستولي على جلسات البرمجة بالذكاء الاصطناعي

تحذير جديد لسلسلة التوريد في التطوير بمساعدة الذكاء الاصطناعي

وصف باحثو الأمن في 0DIN، منصة مكافآت الثغرات في الذكاء الاصطناعي التوليدي التابعة لـ Mozilla، مسار هجوم يحوّل مستودع GitHub يبدو عادياً إلى فخ لاختراق أجهزة المطورين الذين يستخدمون وكلاء برمجة بالذكاء الاصطناعي. المشكلة الأساسية ليست استغلالاً لامعاً داخل النموذج نفسه، بل هي مزيج من حقن التعليمات غير المباشر، وسلوك الإعداد الآلي، ومسار عمل داخل المستودع يمكنه تنفيذ تعليمات تُجلب وقت التشغيل.

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

هذه التفصيلة تجعل النتيجة بالغة الأهمية. لقد قضى المطورون سنوات وهم يتعلمون تفحص المستودعات بحثاً عن السكربتات المشبوهة أو الحمولة المضمّنة صراحة أو العلامات الواضحة على العبث. في هذه الحالة، يقول الباحثون إن المستودع قد يبقى نظيفاً ظاهرياً بينما يسحب تعليمات يسيطر عليها المهاجم من خارج المستودع في اللحظة التي تحتاجها.

كيف يعمل الهجوم

تعتمد الطريقة المبلغ عنها على سكربت إعداد داخل المستودع. أثناء التنفيذ، يسترجع ذلك السكربت أمراً من سجل DNS ثم يشغله. وبما أن الأمر يُجلب ديناميكياً، فلا حاجة لوجود أكثر الشيفرات ضرراً داخل المستودع نفسه. ويقول الباحثون إن هذا يجعل الهجوم أصعب في الاكتشاف بالنسبة للماسحات والمراجعين البشريين، وحتى لوكيل الذكاء الاصطناعي الذي يساعد في عملية الإعداد.

يقول ملخص The Decoder لبحث 0DIN إن وكيل البرمجة يواجه ما يبدو وكأنه خطأ إعداد روتيني، ثم يستجيب بتشغيل السكربت، وبعدها يفتح reverse shell عائداً إلى المهاجم. ومن هناك يمكن للمهاجم أن ينتقل من تنفيذ لمرة واحدة إلى السيطرة الكاملة على الجهاز. وتشمل العواقب المبلغ عنها الوصول إلى مفاتيح API وبيانات تسجيل الدخول، والحصول على موطئ قدم للوصول الدائم.

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

لماذا تغيّر أدوات البرمجة بالذكاء الاصطناعي ملف المخاطر

صُممت مساعدين البرمجة بالذكاء الاصطناعي لتقليل الاحتكاك. فهي تفحص قواعد الشفرة، وتستنتج بنية المشروع، وتساعد المستخدمين على التحرك أسرع عبر التثبيت والتصحيح وإعداد البيئة. وهذه الراحة بالذات يمكن أن توسّع نطاق الضرر عندما يفهم المهاجم كيفية تصرف الأداة تجاه السكربتات وأخطاء الإعداد.

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

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

والنتيجة هي نموذج تهديد أكثر خداعاً. يمكن للمستودع أن يبدو مقبولاً وهو ساكن، لكنه يتصرف بشكل مختلف عند التنفيذ، خاصة عندما يُخوّل مساعد ذكاء اصطناعي بالتصرف نيابة عن المستخدم.

ما الذي يوصي به الباحثون

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

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

بالنسبة للفرق التي تعتمد أدوات البرمجة بالذكاء الاصطناعي، فالدرس الأوسع هو الحوكمة. الأدوات التي يمكنها فحص مستودع، وتفسير التعليمات، وتنفيذ الأوامر تحتاج إلى ضوابط تتناسب مع صلاحياتها. ويشمل ذلك معاينات واضحة لما سيُشغّل، وصلاحيات مقيدة، وسياسات تحدد متى يمكن للوكيل العمل تلقائياً ومتى يجب أن يتوقف للمراجعة.

لا يزعم اكتشاف 0DIN أن مساعدين البرمجة بالذكاء الاصطناعي غير آمنين بطبيعتهم. لكنه يوضح أن طبقة الأتمتة تغيّر مكان اتخاذ قرارات الثقة. وإذا كانت هذه القرارات مخفية داخل مسار استكشاف الأخطاء لدى الوكيل، فقد يمنح المطورون صلاحيات تنفيذ أكثر مما يدركون.

تحذير قد يتجاوز أداة واحدة

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

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

بالنسبة للمطورين وفرق الأمن، يذكّر هذا الاكتشاف بأن راحة الإعداد بمساعدة الذكاء الاصطناعي لا ينبغي الخلط بينها وبين الأمان. إذا جاء المستودع من مصدر غير معروف، فإن كل خطوة إعداد تظل قراراً أمنياً، سواء ضغط على زر التشغيل إنسان أم وكيل ذكاء اصطناعي.

هذه المقالة تستند إلى تقرير The Decoder. اقرأ المقال الأصلي.