يمكن اختطاف GitHub Actions المدعومة بالذكاء الاصطناعي من خلال تعليق واحد فقط، مما يؤدي إلى تسريب مفاتيح API ورموز السحابة (cloud tokens) وأسرار أخرى. كشف باحث أمني عن 22 مستودعاً مفتوح المصدر حيث يؤدي وجود محفز عام، وأداة ذكاء اصطناعي تعمل مع علم "skip prompts"، وأسرار مكشوفة إلى إنشاء مسار مباشر لتسريب البيانات.
كيف تعمل هذه الثغرة
تقوم المشاريع الآن بدمج وكلاء الذكاء الاصطناعي — مثل Claude Code و GitHub Copilot CLI وأدوات مماثلة — مباشرة في خطوط أنابيب التكامل المستمر (CI pipelines). تقوم خطوة في سير العمل (workflow step) بتشغيل أمر shell وغالباً ما تضيف علماً (flag) يخبر الأداة بتجاهل طلبات الإذن التفاعلية. عندما يبدأ سير العمل بناءً على أي مدخلات عامة — مثل مشكلة (issue)، أو تعليق، أو عنوان طلب سحب (pull-request title) — يحتاج المهاجم فقط إلى نشر سطر نصي سيعامله الذكاء الاصطناعي كأمر.
يحصل الذكاء الاصطناعي، الذي مُنح بالفعل وصولاً غير مقيد إلى shell بواسطة علم "skip prompts"، على قراءة أي متغير بيئة (environment variable) أو ملف يكشفه سير العمل. إذا كانت المهمة (job) تقوم أيضاً بتحميل أسرار — مثل مفاتيح API، أو رموز خدمات السحابة، أو بيانات اعتماد حساب الخدمة الكاملة — فإن الذكاء الاصطناعي يقوم بتمرير هذه القيم إلى خادم يتحكم فيه المهاجم. لا يتطلب الأمر تغيير الكود، ولا إضافة تبعية (dependency) جديدة، مجرد تعليق يبدو غير ضار.
أمثلة من الواقع
أكد الباحث وجود ثلاثة مستودعات معرضة للخطر تم إصلاحها بالفعل:
- pymc-labs/pymc-marketing – يمكن استخدام مشكلة (issue) عامة للوصول إلى مفتاح Anthropic API من خلال حقن الأوامر (prompt injection).
- MadAppGang/dingo – منح سير العمل أداة Claude Code وصولاً كاملاً إلى Bash وكشف عن سرين في نفس المهمة.
- MadAppGang/claudish – أعاد استخدام نفس القالب المعرض للخطر المستخدم في مشروع dingo.
تضمن أحد الاكتشافات مفتاح حساب خدمة سحابية نشط، والذي أبلغ عنه الباحث مباشرة إلى الفريق الأمني لمزود خدمة ذكاء اصطناعي رئيسي. وهناك اثنا عشر تقريراً إضافياً قيد الانتظار لدى القائمين على الصيانة؛ ويتم حجب أسماء المستودعات حتى يتم نشر الإصلاحات.
ما هي المخاطر
عندما يستخرج المهاجم سراً، يمكن أن يكون الضرر فورياً ومكلفاً. يمنح مفتاح حساب الخدمة السحابية وصولاً غير مقيد إلى موارد الحوسبة، وحاويات التخزين (storage buckets)، والخدمات المدفوعة الأخرى. كما يمكن لمفتاح API لمزود نموذج لغوي كبير (LLM) تشغيل استعلامات غير محدودة، مما قد يؤدي إلى تراكم تكاليف تصل إلى آلاف الدولارات. ولأن الاستغلال يتم داخل بيئة CI، يمكن أن ينتشر الاختراق إلى مراحل لاحقة: أي منتج (artifact) يتم بناؤه على المشغل (runner) المخترق قد يحمل كوداً ضاراً، مما يحول مستودعاً واحداً إلى ناقل لهجمات سلاسل التوريد (supply-chain vector).
بالنسبة للفرق التي تعتمد على التكامل المستمر (CI) بمساعدة الذكاء الاصطناعي، فإن المقايضة واضحة. يجب موازنة سهولة الكود المولد تلقائياً، أو التدقيق (linting)، أو التوثيق، مقابل خطر تحول تعليق عام إلى باب خلفي خفي.
لماذا من السهل إغفال هذه الثغرة
قدم الباحث في البداية ستة تقارير تم سحبها لاحقاً. نتج السحب عن افتراضات حول فحوصات الأذونات في GitHub Actions، وليس عن مراجعة الكود المصدري لـ Action سطراً بسطر. يمكن للوثائق والحدس أن يكونا مضللين؛ فالطريقة الوحيدة الموثوقة لتأكيد الوضع الأمني لخطوة مدعومة بالذكاء الاصطناعي هي فحص الكود الذي يشغل الأداة وملف YAML الخاص بسير العمل الذي يربطها معاً.
قائمة التحقق من التخفيف من المخاطر
إذا كنت تشغل AI CLI أو أداة مماثلة داخل سير عمل GitHub Actions، فأجب عن هذين السؤالين قبل الدمج:
من يمكنه تحفيز سير العمل؟ قم بقصر المحفزات على الأحداث الموثوقة (مثل عمليات الدفع "pushes" إلى الفروع المحمية) أو تطلب موافقة صريحة للتشغيل الذي يبدأه مساهمون خارجيون. تجنب استخدام
on: issue_commentأوon: issuesدون وجود ضوابط إضافية.ما هي الأسرار التي يتم تحميلها في نفس المهمة؟ لا تكشف أبداً عن مفاتيح API، أو رموز السحابة، أو بيانات اعتماد حساب الخدمة في مهمة تقوم أيضاً بتشغيل وكيل ذكاء اصطناعي مع وصول غير مقيد إلى shell. افصل الخطوات التي تحتوي على أسرار كثيرة في مهام أو مشغلات (runners) معزولة لا تستدعي أدوات الذكاء الاصطناعي.
خطوات تقوية إضافية:
- قم بإزالة العلم (flag) الذي يتخطى مطالبات الإذن، مما يجبر أداة الذكاء الاصطناعي على طلب تأكيد صريح قبل تنفيذ أوامر shell.
- أضف خطوة تقوم بتنقية (sanitizes) أو حجب (redacts) أي متغير بيئة يمكن لأداة الذكاء الاصطناعي قراءته.
- استخدم مشغلات مستضافة ذاتياً (self-hosted runners) مع ضوابط على حركة المرور الصادرة (network egress controls) لمنع تسريب البيانات إلى نقاط نهاية عشوائية.
وجهة نظر معارضة: فائدة الذكاء الاصطناعي في CI
يجادل المؤيدون بأن مكاسب الإنتاجية تفوق المخاطر. فالاقتراحات البرمجية المؤتمتة تقلل وقت المراجعة، والاختبار المدفوع بالذكاء الاصطناعي يكشف الأخطاء في وقت مبكر. ومع ذلك، فإن نفس هذه السهولة تزيد من سطح الهجوم. المفتاح ليس التخلي عن الذكاء الاصطناعي، بل التعامل مع أي أداة تتمتع بامتيازات على مستوى shell كمتجه هجوم محتمل.
ما يجب مراقبته لاحقاً
أثارت هذه النتائج بالفعل نقاشات في منتديات الأمان الخاصة بـ GitHub حول فرض أذونات افتراضية أكثر صرامة لـ GitHub Actions المدعومة بالذكاء الاصطناعي. قد تتضمن تحديثات المنصة المستقبلية ما يلي:
- علامة (flag) تجبر أدوات الذكاء الاصطناعي على العمل في بيئة معزولة (sandboxed environment) دون وصول مباشر إلى الـ shell.
- كشف مدمج لأنماط حقن الأوامر (prompt-injection) في محتوى الـ issues أو التعليقات.
- تنبيهات تلقائية عندما يمزج سير العمل (workflow) بين مشغلات عامة (public triggers) ومهام تحتوي على أسرار (secret-laden jobs).
في الوقت الحالي، تقع المسؤولية على عاتق مديري المستودعات (repository maintainers). تُظهر المستودعات الـ 22 التي تم تحديدها أن المشكلة ليست حالة معزولة؛ فأي مشروع يتبع نفس نمط سير العمل (workflow pattern) يكون عرضة للخطر. يمكن لعملية تدقيق سريعة لتكوينات الـ CI أن تكشف المشكلة قبل أن يكتشفها المهاجم.
الخلاصة: سطر واحد من النص في GitHub issue عام يمكن أن يمنح وكيل ذكاء اصطناعي (AI agent) سيطرة كاملة على بيئة الـ CI الخاصة بك ويسرق الأسرار التي تخزنها هناك. تحقق من الأشخاص الذين يمكنهم تشغيل سير العمل (workflows) الخاص بك، وأبقِ الأسرار بعيدة عن الخطوات التي يقودها الذكاء الاصطناعي، وراجع بدقة كل علامة (flag) تمنح أذونات غير مقيدة. إن تكلفة الاختراق تتجاوز بكثير الجهد المبذول في إجراء مراجعة منضبطة.