أحد مخاطر سلسلة توريد البرامج هو تسرب الأسرار. الأسرار موجودة في كل مكان حول سلسلة توريد البرمجيات؛ يحتاج المطورون وخطوط أنابيب CI\CD إلى استخدام الأسرار للوصول إلى SCM وخطوط الأنابيب وسجلات العناصر والبيئات السحابية والخدمات الخارجية. وعندما تكون الأسرار في كل مكان، فهي مسألة وقت حتى تتسرب.
لقد تم تحديد هذا الخطر جيدًا، والعديد من أطر عمل سلسلة توريد البرامج تعالجه من خلال المطالبة بالمسح السري وانتهاء الصلاحية السري الذاتي.
لذا، ما الخطأ الذي يمكن أن يحدث إذا قمت، بصفتك ممارسًا أمنيًا، بوضع حواجز الحماية هذه في مكانها الصحيح؟
هذا الأسبوع، أثناء بحثي عن أدوات المسح السرية، وجدت إجابة واحدة. هذه الإجابة بسيطة: بما أن الماسحات الضوئية السرية تبحث عن أنماط الأسرار، فعندما يتغير التنسيق السري، قد يفشل الكشف. وهذا هو بالضبط ما حدث عندما قدم GitHub ميزة أمان جديدة - الرموز الدقيقة. تعد هذه الميزة التجريبية إحدى طرق GitHub لتقليل مخاطر تسرب المعلومات السرية؛ كما أن الحد من أذونات رموز الوصول الشخصية يحد أيضًا من المخاطر في حالة اختراق هذه الأسرار.
اتضح أن تنسيق الرموز الجديدة مختلف قليلاً، في حين أن تنسيق الرموز القديمة كان كالتالي:
ghp_123456789012345678901234567890123456
تنسيق الرمز المميز الجديد يشبه:
github_pat_123456789012345678901234567890123456789012345678901234567890…
تختلف كل من البادئة وطول السر.
وبالفعل، تفشل بعض الماسحات الضوئية السرية في اكتشاف التنسيق الجديد؛
للتجربة، قمت بإنشاء ريبو باستخدام ملف Dockerfile بسر وسير عمل يقوم بتشغيل إجراء Trivy. هذه هي الطريقة التي يبدو بها ملف Dockerfile في بداية التجربة:
فيما يلي لقطة من GitHub Secret Scanner، الذي يكتشف السر المنسق حديثًا:
كما نرى، يكتشف الماسح السري لـ GitHub السر، ولكن لا تظهر أي تنبيهات في قسم فحص الكود.
للتحقق من تعيين الأدوات بشكل صحيح، سأضيف الآن سرًا كلاسيكيًا إلى ملف Dockerfile (انظر أدناه) وأجري الفحص مرة أخرى. الآن نحصل على تنبيه لمسح الكود (فقط على السر الكلاسيكي!)
من ناحية أخرى، يكتشف ماسح Github الآن سرين:
لقد قمت بفتح مشكلة أمنية لـ Trivy؛ رد فريق Trivy بأن هذه ليست ثغرة أمنية ولا مشكلة أمنية. وما بقي إلا أن نفتح قضية.
تثير هذه التجربة العديد من المخاوف؛
- لماذا يجب أن يشك مستخدم GitHub في أنه سيتم تعديل تنسيق الرمز المميز بسبب ميزة جديدة؟
- نظرًا لأن الأسرار من المفترض أن تبدو كسلاسل عشوائية، فلماذا يجب على مستخدم GitHub أن يهتم بتنسيق الأسرار؟
- هل يجب أن يكون GitHub مسؤولاً عن إطلاع عملائه على مثل هذا التغيير؟
- هل يعد هذا الفشل في اكتشاف السر بمثابة ثغرة أمنية في أسرار GitHub الدقيقة، أو ثغرة أمنية في Trivy، أو، كما ترى Aqua Security، ليست ثغرة أمنية على الإطلاق؟
- هل يجب أن تكون شركة Aqua Security، الشركة التي تقف وراء Trivy، مسؤولة عن تحديثه؟
- نظرًا لأن Trivy هو مشروع مفتوح المصدر، ويتم توفيره كما هو، فهل سيكون أي شخص مسؤولاً إذا تسربت أسرار من خط أنابيب محمي بواسطة Trivy؟ من سيكون يا ترى؟ جيثب؟ أكوا الأمن؟ المستخدم تريفي؟
- ماذا تعلمنا هذه التجربة عن الثقة في أدوات الأمان المثبتة لحماية سلاسل توريد البرامج؟
وسأترك هذه الأسئلة مفتوحة.
شيء واحد واضح، وإن كان؛ إن حماية سلسلة توريد البرامج أمر معقد ونحن بحاجة إلى مجتمع محترف للغاية لتحقيق النجاح الدائم في هذه المهمة.
شارك في تأليف هذا المنشور آفي واكسمان، متدرب في Scribe Security
يتم تقديم هذا المحتوى إليك بواسطة Scribe Security، وهي شركة رائدة في مجال توفير حلول أمان سلسلة توريد البرامج الشاملة - حيث توفر أحدث الأمان لعناصر التعليمات البرمجية وعمليات تطوير التعليمات البرمجية وتسليمها عبر سلاسل توريد البرامج. تعرف على المزيد.
الوظائف ذات الصلة
