تسريب GitHub الخاص بـ CISA هو تذكير بأن إدارة الأسرار هي ثقافة

DevOps and CI/CD pipeline automation concept صورة داعمة: مفهوم DevOps، خط أنابيب CI/CD، ونشر السحابة، ملف Adobe Stock رقم 1747170611.

في 22 مايو 2026، ذكرت KrebsOnSecurity أن المشرعين الأمريكيين كانوا يطالبون بالحصول على إجابات من CISA بعد أن أفاد كريبس بأن أحد المتعاقدين قد نشر مفاتيح AWS GovCloud وغيرها من الأسرار الداخلية للوكالة على حساب عام في GitHub. وأفاد كريبس لاحقًا أن الخبراء الذين قاموا بمراجعة المستودع ذكروا أن الحماية المدمجة للأسرار في GitHub قد تم تعطيلها، وأن CISA لا تزال تعمل على إبطال واستبدال المفاتيح المكشوفة.

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

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

لماذا هذا مهم

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

يكون الخطر مرتفعًا بشكل خاص عندما تصل بيانات الاعتماد المسربة إلى بيئات السحابة أو تطبيقات GitHub أو مشغلات CI/CD أو مستودعات الكود الداخلية أو خطوط نشر التطبيقات. يمكن لمفتاح واحد مكشوف أن يصبح طريقًا للوصول إلى الكود المصدري والأسرار وأنظمة البناء وإمكانية الوصول إلى الإنتاج.

ذكر كريبس أن ديلان آيري من TruffleHog حذر من أن مفتاح تطبيق GitHub الخاص المكشوف يمكن أن يسمح لمهاجم بقراءة المستودعات الخاصة، وتسجيل مشغلات مستقلة وهمية، والتدخل في خطوط CI/CD، وتعديل إعدادات إدارة المستودعات. هذا هو الخطر الحقيقي لأسرار استضافة الشيفرة: فالتأثير يمكن أن يتحرك من "شخص ما رأى مفتاحًا" إلى "شخص ما يمكنه تعديل سلسلة توريد البرمجيات".

لماذا هذه حادثة CI/CD

عندما تُكشف الأسرار في نظام التحكم بالمصدر، يتعين على المنظمة المتضررة الإجابة عن أكثر من مجرد "هل تم استخدام المفتاح؟" يجب عليها الإجابة عن:

ما هي المستودعات التي يمكن أن يصل إليها الاعتماد؟
هل يمكنه قراءة الكود المصدري، القضايا، طلبات السحب، أو الأسرار؟
هل يمكنه تسجيل أو التحكم في المشغلين؟
هل يمكنه تغيير حماية الفروع، مفاتيح النشر، أو وحدات الويب (Webhooks)؟
هل يمكن أن تكون مخرجات البناء أو عناصر النشر قد تم العبث بها؟
هل كانت أي أنظمة تابعة تثق بالعناصر المبنية خلال فترة التعرض؟

ما الذي يجب أن تفعله الفرق

حظر الالتزامات العامة التي تحتوي على أسرار على مستوى المنصة.
منع المستخدمين من تعطيل مسح الأسرار أو حماية الدفع دون موافقة.
استخدام بيانات اعتماد قصيرة الأمد وهوية عبء العمل بدلاً من المفاتيح الثابتة طويلة الأمد.
تدوير الأسرار المكشوفة فورًا والتحقق من الإلغاء.
تدقيق تطبيقات GitHub والمفاتيح المستخدمة والنُظم الآلية (webhooks) والمشغلات المستضافة ذاتيًا وأذونات CI/CD.
تدريب المقاولين والموظفين على سير العمل المعتمد للملاحظات المؤقتة وبيانات الاختبار والتكوين.
اعتبار كل تسرب أسرار حادثًا حتى يتم إثبات نطاقه.

ما يجب استخلاصه

إدارة الأسرار لا تُحل بمجرد وجود خزنة. تُحل عندما تجعل المنظمة التعامل غير الآمن مع الأسرار صعباً ومرئياً وغير مقبول ثقافياً.

لماذا هذا مهم

لماذا هذه حادثة CI/CD

ما الذي يجب أن تفعله الفرق

ما يجب استخلاصه

مصادر