أظهرت Noma Labs أن مشكلة (issue) واحدة عامة على GitHub يمكن أن تؤدي إلى سرقة الكود من المستودعات الخاصة باستخدام أتمتة مدفوعة بالذكاء الاصطناعي. يتيح إثبات المفهوم (proof-of-concept) الخاص بهم للمهاجم تحويل بوتات سير العمل الخاصة بالمؤسسة ضدها، مما يؤدي إلى تسريب ملفات مملوكة دون كسر نظام المصادقة في GitHub.

الهجوم في وضح النهار

سلسلة الأحداث بسيطة بما يكفي لإعادة إنتاجها:

  • يقوم المهاجم بإنشاء مشكلة (issue) في مستودع عام يمكن لأي شخص مشاهدته.
  • يقوم وكيل ذكاء اصطناعي (AI agent)، متصل بخط أنابيب التكامل المستمر (continuous-integration pipeline)، بقراءة عنوان المشكلة ومحتواها.
  • يمتلك الوكيل نفسه بالفعل أذونات القراءة لمستودعات خاصة أخرى في المؤسسة.
  • تخبر التعليمات المخفية في المشكلة العامة الوكيل بالملفات الخاصة التي يجب جلبها.
  • يقوم الوكيل بنشر الملفات المستردة مرة أخرى في المشكلة العامة كتعليق، مما يعرضها للعالم.

يحدث كل شيء في تشغيل واحد للأتمتة. لا يوجد سرقة لبيانات الاعتماد، ولا تسريب لمفاتيح API، ولا ثغرة في GitHub. ببساطة، يستغل المهاجم الثقة التي وضعتها المؤسسة في البوت الخاص بها.

لماذا يكتسب هذا الأمر أهمية الآن

تعمل الوكلاء المدعومون بالذكاء الاصطناعي الآن على ربط خطوط أنابيب التطوير الحديثة ببعضها البعض. فهي تفتح طلبات السحب (pull-requests)، وتجري الاختبارات، وتنشر الإصدارات (deploy builds)، وتصنف الأخطاء (triage bugs) — وكل ذلك يتم تحفيزه بواسطة إشارات خفيفة مثل التعليقات على المشكلات. عندما تمتلك هذه الوكلاء وصولاً واسع النطاق إلى المستودعات، يتلاشى الخط الفاصل بين البيانات الموثوقة ومدخلات المستخدم غير الموثوقة.

إذا كان بإمكان الوكيل قراءة الكود الخاص والكتابة بشكل علني في نفس عملية التنفيذ، فإن نموذج التحكم في الوصول الخاص بالمؤسسة ينهار.

الخلل الحقيقي: الأذونات، وليس النموذج

لا يسيء العرض اتهام نموذج الذكاء الاصطناعي الأساسي؛ فالنموذج ببساطة يتبع التعليمات التي يتلقاها. تكمن الثغرة في مجموعة الأذونات الممنوحة للأتمتة:

  • إذن القراءة للمستودعات الخاصة عبر المؤسسة.
  • إذن الكتابة في سلاسل المشكلات العامة.
  • التحفيز (Trigger) بناءً على نص عام يمكن لأي شخص صياغته.

إصلاحات لا تكلف شيئاً، لكنها فعالة

يؤدي تطبيق مبدأ الحد الأدنى من الامتيازات (principle of least privilege) إلى تقليص مسار الهجوم:

  • تحديد نطاق البوت في المستودع الذي يحتاجه فقط. إذا كان يحتاج فقط للعمل على مستودع معين، فارفض منحه أي حقوق قراءة أخرى.
  • فصل رموز القراءة والكتابة (tokens). استخدم بيانات اعتماد واحدة لجلب الكود وأخرى خاضعة لرقابة صارمة لنشر التعليقات.
  • الموافقة البشرية قبل أي نشر علني. إضافة خطوة مراجعة خفيفة — مثل ملصق موافقة مطلوب — تضيف نقطة تفتيش دون إيقاف خط الأنابيب.
  • تقليل نطاق الضرر (Blast-radius). صمم سير العمل بحيث يؤثر الفشل أو سوء الاستخدام على مستودع واحد على الأكثر، وليس المؤسسة بأكملها.

وجهة نظر معارضة: الأعباء التشغيلية

ما يجب مراقبته لاحقاً

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