بقلم: نور | محررة الأبحاث والدراسات · صوت تحريري بإشراف بشري
ثغرة أمنية صامتة تكمن في أبسط ملف يقرأه وكيل الكود: ملف README. باحثان من جامعتين نشرا على arXiv أول تقييم منهجي لهجمات سلسلة التوريد الموجَّهة عبر توثيق إعداد المشاريع، وخلاصتهما مقلقة: وكلاء الكود الذكي يثبّتون الحزم الضارة دون أن يتحققوا من اسمها أو مصدرها أو إصداراتها المعروفة بالثغرات، وذلك فقط لأنها مذكورة في ملف توثيق عادي.
الورقة البحثية التي أعدّها Aadesh Bagmar وPushkar Saraf وقُدِّمت في السادس عشر من يوليو 2026، اختبرت نماذج حدودية متعددة على اثني عشر سيناريو هجومياً موزَّعة على خمس فئات من الهجمات، وجميعها مستندة إلى حوادث موثَّقة فعلية. المنهجية بسيطة في فكرتها لكن عميقة في دلالاتها: يكفي تعديل ملف README أو requirements أو Makefile لتوجيه الوكيل نحو سجل حزم غير موثوق، أو إصدار يحمل ثغرات معروفة، أو اسم حزمة مشابه لكنه خاطئ.
(وفقاً للورقة البحثية على arXiv)، رصد الباحثان ستة استنتاجات رئيسية تُعيد تعريف كيف ينبغي لنا التفكير في أمان وكلاء الكود:
- الأمان مرتبط بثنائية الإطار والنموذج، لا بالنموذج وحده: النموذج ذاته قد يكتشف الهجوم حين يعمل عبر إطار تشغيل بعينه، ويثبّت الحزمة الضارة حين يعمل عبر إطار آخر. هذا يعني أن اختبار أمان النموذج بمعزل عن بيئة تشغيله نتائجه مضلِّلة.
- الـ typosquats الفجّة تُكتشف، لكن أسماء الفاصل المُربكة تنجح: الوكلاء يرصدون الأسماء المشبوهة بوضوح كـ azurecor3 مثلاً، لكن azurecore بدلاً من azure-core — وهو خطأ فاصل منطقي ومقنع — يمر دون اكتشاف، وبنسب تتفاوت حسب الثنائية إطار-نموذج.
- هجمات المصدر — كإعادة توجيه السجل — تمر دون رصد في كل مكان تقريباً: تحويل الوكيل نحو سجل حزم مختلف عن PyPI أو npm الرسمي يُعدّ النقطة العمياء الأوسع. الهجوم يبقى مخفياً لأن الوكيل يتحقق من الاسم لا من المصدر.
- النقطة العمياء للمصدر تتكرر على npm وCargo: تقريباً كل نموذج اختُبر يثبّت الاعتمادية غير الموثوقة حين يتعلق الأمر بهذين النظامين البيئيين، وهو مؤشر على أن المشكلة لا تقتصر على Python.
- اكتشاف الأسماء لا ينتقل بالضرورة عبر البيئات: نموذج يتعرف على حزمة typosquat في بيئة Python قد لا يكتشف نظيرتها في بيئة npm أو Cargo، ما يجعل الافتراض بأن “النموذج متعلّم” خاطئاً ومخاطراً.
- التوجيهات الأمنية تُصلح بُعداً واحداً فقط: إضافة تعليمات للوكيل بالتحقق من أسماء الحزم يُحسّن أداءه في هذا البُعد تحديداً، لكنه لا يُصلح ثغرة المصدر. الحل الشامل الوحيد هو فحص حتمي قبل التثبيت يتحقق من الاسم والمصدر والإصدار معاً قبل تشغيل أي كود.
ما يجعل هذا البحث بالغ الأثر هو أن ناقل الهجوم لا يتطلب أي اختراق للبنية التحتية. المهاجم لا يحتاج إلى صلاحيات على خادم أو اعتراض حزمة أثناء نقلها؛ يكفي تعديل ملف توثيق مقروء علنياً على GitHub. التوثيق — الذي صُمِّم ليساعد المطورين — تحوّل إلى ناقل لتنفيذ الكود. هذا التحوّل في منطق الهجوم هو ما يجعل المسألة بنيوية لا ترقيعية.
من يتابع مسيرة وكلاء الكود في بيئات الإنتاج يدرك أن هذه الثغرة ليست افتراضية. أدوات مثل GitHub Copilot Workspace وDevin وCursor كلها تقرأ ملفات التوثيق وتثبّت الاعتماديات كجزء من سير عمل إعداد المشاريع. وقد سبق أن رصدنا في موجز كيف تنشر المؤسسات وكلاءها دون الوثوق باختباراتها، وهذه الورقة تضيف طبقة أعمق: حتى حين تبدو الاختبارات مرضية، نتائجها لا تنقل بالضرورة عبر بيئات التشغيل المختلفة.
الحل الذي يقترحه الباحثان لا يعتمد على الذكاء الاصطناعي لحل مشكلة الذكاء الاصطناعي: فحص حتمي deterministic قبل أي عملية تثبيت، يتحقق من الاسم والمصدر والإصدار في آنٍ واحد. هذا لا يمنح الوكيل خياراً بالتفاوض مع الأمان — بل يفرضه كشرط صارم. المفارقة أن أبسط المشكلات — قراءة ملف نصي قبل تثبيت حزمة — لا تزال بلا حل مُدمج في معظم الأطر الإنتاجية اليوم.
