قدمت Google إطار عمل SLSA (مستويات سلسلة التوريد للبرامج)، والذي يلخص الخبرة الحالية في حماية البنية التحتية للتطوير من الهجمات التي يتم تنفيذها في مرحلة كتابة التعليمات البرمجية واختبار المنتج وتجميعه وتوزيعه.
أصبحت عمليات التطوير معقدة بشكل متزايد وتعتمد على أدوات الطرف الثالث، مما يخلق ظروفًا مواتية لتقدم الهجمات المتعلقة ليس بتحديد نقاط الضعف في المنتج النهائي واستغلالها، ولكن بتعريض عملية التطوير نفسها للخطر (هجمات سلسلة التوريد، التي تهدف عادةً إلى إدخال تغييرات ضارة في عملية كتابة التعليمات البرمجية واستبدال المكونات الموزعة والتبعيات).
يأخذ الإطار في الاعتبار 8 أنواع من الهجمات المتعلقة بالتهديد بإجراء تغييرات ضارة في مرحلة تطوير التعليمات البرمجية وتجميعها واختبارها وتوزيع المنتج.
- أ. بما في ذلك التغييرات في الكود المصدري التي تحتوي على أبواب خلفية أو أخطاء مخفية تؤدي إلى ثغرات أمنية.
مثال على الهجوم: "Commits Hypocrite" - محاولة للترويج للتصحيحات التي تحتوي على ثغرات أمنية في نواة Linux.
طريقة الأمان المقترحة: مراجعة مستقلة لكل تغيير بواسطة مطورين اثنين.
- ب. اختراق منصة التحكم في التعليمات البرمجية المصدر.
مثال على الهجوم: إدخال عمليات ارتكاب ضارة باستخدام باب خلفي في مستودع Git لمشروع PHP بعد تسرب كلمات مرور المطورين.
طريقة الحماية المقترحة: زيادة أمان منصة إدارة التعليمات البرمجية (في حالة PHP، تم تنفيذ الهجوم من خلال واجهة HTTPS قليلة الاستخدام، مما سمح بإرسال التغييرات عند تسجيل الدخول باستخدام كلمة مرور دون التحقق من مفتاح SSH، على الرغم من حقيقة أنه تم استخدام MD5 غير الموثوق به لتجزئة كلمات المرور).
- ج. إجراء تغييرات في مرحلة نقل الكود إلى نظام البناء أو التكامل المستمر (يتم بناء الكود الذي لا يتطابق مع الكود من المستودع).
مثال على الهجوم: إدخال باب خلفي في Webmin عن طريق إجراء تغييرات على البنية التحتية للبناء، مما يؤدي إلى استخدام ملفات التعليمات البرمجية التي تختلف عن الملفات الموجودة في المستودع.
طريقة الحماية المقترحة: التحقق من السلامة وتحديد مصدر التعليمات البرمجية على خادم التجميع.
- د. تسوية منصة التجميع.
مثال على الهجوم: هجوم SolarWinds، الذي تم خلاله تثبيت باب خلفي في منتج SolarWinds Orion خلال مرحلة التجميع.
طريقة الحماية المقترحة: تنفيذ إجراءات أمنية متقدمة لمنصة التجميع.
- هـ. الترويج للتعليمات البرمجية الضارة من خلال التبعيات منخفضة الجودة.
مثال على الهجوم: إدخال باب خلفي في مكتبة تدفق الأحداث الشهيرة عن طريق إضافة تبعية غير ضارة ثم تضمين تعليمات برمجية ضارة في أحد تحديثات هذه التبعية (لم ينعكس التغيير الضار في مستودع git، ولكن تم موجود فقط في حزمة MNP النهائية).
طريقة الحماية المقترحة: تطبيق متطلبات SLSA بشكل متكرر على جميع التبعيات (في حالة تدفق الأحداث، سيكشف الفحص عن تجميع التعليمات البرمجية التي لا تتوافق مع محتويات مستودع Git الرئيسي).
- F. تحميل العناصر التي لم يتم إنشاؤها في نظام CI/CD.
مثال على الهجوم: إضافة تعليمات برمجية ضارة إلى البرنامج النصي CodeCov، مما سمح للمهاجمين باستخراج المعلومات المخزنة في بيئات نظام التكامل المستمر للعملاء.
طريقة الحماية المقترحة: التحكم في مصدر وسلامة القطع الأثرية (في حالة CodeCov، يمكن الكشف عن أن البرنامج النصي Bash Uploader المرسل من موقع codecov.io لا يتوافق مع الكود من مستودع المشروع).
- G. تسوية مستودع الحزمة.
مثال على الهجوم: تمكن الباحثون من نشر مرايا لبعض مستودعات الحزم الشائعة لتوزيع الحزم الضارة من خلالها.
طريقة الحماية المقترحة: التحقق من تجميع القطع الأثرية الموزعة من أكواد المصدر المعلنة.
- ح. إرباك المستخدم لتثبيت الحزمة الخاطئة.
مثال على الهجوم: استخدام typosquatting (NPM، RubyGems، PyPI) لوضع الحزم في مستودعات تشبه في الكتابة التطبيقات الشائعة (على سبيل المثال، coffe-script بدلاً من Coffee-script).
لحظر التهديدات التي تم الإبلاغ عنها، يقدم SLSA مجموعة من التوصيات، بالإضافة إلى أدوات لأتمتة إنشاء بيانات تعريف التدقيق. يلخص SLSA أساليب الهجوم الشائعة ويقدم مفهوم طبقات الأمان. يفرض كل مستوى متطلبات معينة للبنية التحتية لضمان سلامة القطع الأثرية المستخدمة في التطوير. كلما ارتفع مستوى SLSA المدعوم، تم تنفيذ المزيد من الحماية وتمت حماية البنية التحتية بشكل أفضل من الهجمات الشائعة.
- يتطلب SLSA 1 أن تكون عملية الإنشاء مؤتمتة بالكامل وأن يتم إنشاء بيانات تعريف ("المصدر") حول كيفية إنشاء العناصر، بما في ذلك معلومات حول المصادر والتبعيات وعملية الإنشاء (يتم توفير مثال لمولد بيانات التعريف للتدقيق لإجراءات GitHub). لا يتضمن SLSA 1 عناصر الحماية ضد التعديلات الضارة، ولكنه يحدد ببساطة التعليمات البرمجية ويوفر بيانات التعريف لإدارة الثغرات الأمنية وتحليل المخاطر.
- SLSA 2 - يمتد المستوى الأول من خلال طلب استخدام التحكم في الإصدار وخدمات التجميع التي تولد بيانات التعريف المصادق عليها. يتيح لك استخدام SLSA 2 تتبع أصل الكود ومنع التغييرات غير المصرح بها على الكود في حالة خدمات البناء الموثوقة.
- SLSA 3 - يؤكد أن الكود المصدري ومنصة البناء تلبي متطلبات المعايير التي تضمن القدرة على تدقيق الكود والتأكد من سلامة البيانات الوصفية المقدمة. من المفترض أن المدققين يمكنهم التصديق على المنصات وفقًا لمتطلبات المعايير.
- SLSA 4 هو المستوى الأعلى، ويكمل المستويات السابقة بالمتطلبات التالية:
- مراجعة إلزامية لجميع التغييرات من قبل مطورين مختلفين.
- يجب الإعلان عن جميع خطوات البناء والتعليمات البرمجية والتبعيات بشكل كامل، ويجب استخراج جميع التبعيات والتحقق منها بشكل منفصل، ويجب تنفيذ عملية الإنشاء دون اتصال بالإنترنت.
- يتيح لك استخدام عملية الإنشاء القابلة للتكرار تكرار عملية الإنشاء بنفسك والتأكد من إنشاء الملف القابل للتنفيذ من كود المصدر المقدم.
المصدر: opennet.ru