فهم إطار عمل الأمن السيبراني SLSA

كيف يساعد SLSA في الدفاع ضد هجمات سلسلة توريد البرامج

أكثر من مجرد مجموعة من القواعد، فإن إطار عمل أمان SLSA هو إطار عمل قياسي يمكنه تعزيز سلامة مكونات البرنامج. يعمل هذا المبدأ التوجيهي الشامل كمجموعة من الإجراءات الدفاعية التي تمنع بشكل متزايد التلاعب أو أي نوع من التعديلات غير المصرح بها لحزم البرامج التي تشكل منتج البرنامج. يمكن أن يساعد اعتماد إطار عمل SLSA في حماية برنامجك من البرامج الشائعة هجمات سلسلة التوريد مثل ما يلي:

PHP'S ارتكاب هجمات مستودعات ضارة

في مارس 2021، أعلن نيكيتا بوبوف أن الجهات الفاعلة الخبيثة حاولت مهاجمة كود مصدر PHP عن طريق إنشاء باب خلفي يسمح لهم بالوصول غير المصرح به إلى النظام الأساسي للتعليمات البرمجية. إذا نجح الهجوم، فسيكون مدمرًا، حيث أن PHP تعمل على تشغيل حوالي 80٪ من مواقع الويب على الإنترنت. ولحسن الحظ، تم اكتشاف الهجوم في الوقت المحدد، ولكن هذا الحادث لا يزال يوضح كيف يمكن لضوابط SLSA أن تساعد في منع مثل هذه الهجمات في المستقبل. إن اتباع بروتوكولات SLSA مثل المراجعة الثنائية والمصادقة الثنائية كان من شأنه حماية منصة الكود المصدري وجعلها هدفًا أكثر صعوبة للمهاجمين.

خرق المترجم الضار لشركة Apple

في عام 2015، قام مطورو البرامج الذين يقومون بتصميم تطبيقات لمنتجات Apple بتنزيل إصدار من Xcode (أداة لكتابة التعليمات البرمجية لأجهزة Apple) من منصة استضافة لم يتم التحقق منها. تم إصابة إصدار Xcode المعروف باسم XcodeGhost بتعليمات برمجية ضارة تم نقلها سرًا إلى التطبيقات المضمنة بها. لقد أنشأت بابًا خلفيًا للعديد من التطبيقات التي تهربت من عملية مراجعة كود Apple والتطبيقات المقدمة في متجر التطبيقات. يحتوي إطار عمل SLSA على بروتوكولات أمان متعلقة بالإنشاء والتي كان من شأنها أن تمنع هجومًا كهذا أو تجعله أكثر صعوبة. أحد هذه الإجراءات هو متطلبات البناء المحكم التي من شأنها أن تجبر المطورين على الإعلان عن جميع مصادرهم بما في ذلك الأداة المبنية التي استخدموها.

العناصر الضارة التي تم تحميلها

في 1 أبريل 2021، كشف فريق Codecov عن هجمات أثرت على برامج تحميل Bash، والتي تضمنت Codecov GitHub Action وThe Codecov CircleCI Orb وCodecov Bitrise Step. حصل المهاجم على وصول غير مصرح به من خلال استخراج مفتاح HMAC الذي يوفر الوصول إلى حساب خدمة Google Cloud Storage لطبقة وسيطة لإحدى صور Codecov العامة ذاتية الاستضافة Docker. سمح لهم هذا المفتاح بتعديل Bash Uploader لتحميل الرموز الضارة مباشرةً إلى المستخدمين النهائيين. كان من الممكن أن يلتقط إطار عمل SLSA هذا الإجراء من خلال إظهار متى يتم إنشاء القطع الأثرية بطريقة مختلفة عن الشكل المتوقع في مستودع المصدر الخاص بها.

تبعية سيئة لتدفق الأحداث

في عام 2018، نشر المتسللون حزمة خبيثة من flatmap-stream إلى npm وتمت إضافتها لاحقًا باعتبارها تبعية لحزمة دفق الأحداث المستخدمة على نطاق واسع في النظام الأساسي. بعد إضافة التبعية، قام المهاجمون بتحديثها بسلوك ضار. نظرًا لأن التحديث لم يتطابق مع الكود الذي تم إرساله إلى GitHub، فإن إطار عمل SLSA كان سيكتشف الهجوم ويمنع المتجه. كان من الممكن أن يكشف تتبع مصدر التعليمات البرمجية الضارة أنها لم تأت من GitHub أو من المنشئ المناسب. وفي كلتا الحالتين، كان من الممكن منع الهجوم.

مستويات الأمان الأربعة لإطار عمل الأمن السيبراني SLSA

إطار عمل SLSA هو بروتوكول تزايدي وقابل للتنفيذ. ويتكون من أربعة مستويات، حيث يمثل المستوى 4 الحالة النهائية المثالية للنظام الآمن. إن القطع الأثرية على أعلى مستوى تفي بجميع المتطلبات لكسب ثقة المستهلك بأنها لم يتم العبث بها بأي شكل من الأشكال وأن جميع مكوناتها يمكن إرجاعها إلى مصادرها. القطع الأثرية في المستويات الأدنى هي تلك التي حققت أيضًا مراحل تدريجية مع ضمانات نزاهة محددة اعتمادًا على رتبتها.

المستوى 1 - وضع الأساس

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

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

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

المستوى 2 - تأكد من أن عملية الإنشاء الخاصة بك مقاومة للتلاعب

المستوى 2 من إطار عمل SLSA هو المكان الذي تبدأ فيه بوضع التدابير اللازمة لضمان أن تكون عملية الإنشاء الخاصة بك مقاومة للتلاعب قدر الإمكان. كما أن تحقيق المستوى 2 من إطار عمل SLSA يمنح المستهلك المزيد من الثقة حول أصل البرنامج.

مرة أخرى، يتم ذلك في خطوتين، الأولى هي استخدام التحكم في الإصدار والثانية تتضمن استخدام خدمة بناء مستضافة لمصادقة المصدر. في الخطوة الأولى، يتم استخدام GitHub أو GitLab أو أي خدمة أخرى مماثلة لتخزين الكود وتسجيل أي تغييرات يتم إجراؤها عليه. يؤدي تتبع أي تغييرات في الإصدار بهذه الطريقة إلى تسهيل فهم أي تعديلات يتم إجراؤها على القطعة الأثرية أثناء عملية بنائها.

على الرغم من أن المستوى 2 يتطلب توثيق المصدر تمامًا مثل المستوى 1، إلا أن الفرق هنا هو أن قطعة البرنامج يجب أن تتم مصادقتها بواسطة خدمة بناء مستضافة. تعمل الخدمة المستضافة كطرف ثالث موثوق به يمكنه التأكد من دقة عملية الإنشاء المفصلة في مستند المصدر الأولي. GitHub Actions هو نوع من خدمات الاستضافة التي يمكن أن توفر مصدرًا موثقًا.

 المستوى 3 — ضوابط الأمان الخاصة بـ SLSA

المستوى 3 هو المكان الذي تبدأ فيه تنفيذ التحكم الأمني ​​المحدد كما هو موضح في إطار عمل SLSA. ولتحقيق هذا المستوى، يجب أن يستوفي المصدر ومنصات البناء الخاصة بالعناصر البرمجية الخاصة بك معايير محددة تضمن أن المصدر قابل للتدقيق ويمكن الوثوق بمصدر التعليمات البرمجية. يوفر المستوى 3 من SLSA ضمانًا أقوى بكثير بأن المنتج محمي بشكل جيد ضد العبث وفئات محددة من التهديدات.

تتضمن بعض المتطلبات المحددة للمستوى 3 ما يلي:

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

المستوى الرابع – ثقة المستهلك

يهدف المستوى 4 من إطار عمل SLSA إلى ضمان عدم العبث بالبرنامج بأي شكل من الأشكال. يمكن فقط للعناصر البرمجية التي استوفت المتطلبات التالية تحقيق المستوى 4 من إطار العمل:

مراجعة شخصين لجميع التغييرات

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

عملية بناء محكم وقابلة للتكرار

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

المتطلبات الفنية لتلبية مستويات SLSA

يحتوي إطار عمل SLSA على متطلبات فنية محددة للمستويات المختلفة. يتم تصنيف هذه المتطلبات إلى خمس فئات رئيسية: متطلبات المصدر، ومتطلبات عملية البناء، والمتطلبات المشتركة، ومتطلبات محتوى المصدر، ومتطلبات إنشاء المصدر. يتم تسليط الضوء على كل فئة من فئات المتطلبات هذه أدناه.

متطلبات المصدر

يشير هذا إلى المتطلبات التي تهدف إلى ضمان سلامة كود المصدر الخاص بك. يؤدي اتباع هذه المجموعات من البروتوكولات إلى منع التلاعب والتغييرات الضارة في التعليمات البرمجية الخاصة بك. كما أنه يضمن عدم مرور أي أعمال شائنة دون أن يلاحظها أحد. متطلبات المصدر موضحة في الجدول أدناه.

متطلبات البناء

يسلط إطار عمل SLSA الضوء على متطلبات البناء التي تهدف إلى تحسين سلامة منصة البناء والحفاظ على سلامة عملية البناء.

متطلبات إنشاء المصدر

تهدف هذه المتطلبات إلى التحقق من مصدر جميع مكونات أصل البرنامج. تم توضيح متطلبات إنشاء المصدر في الجدول أدناه.

متطلبات محتوى المصدر

تتحقق متطلبات محتوى المصدر من هوية ومصدر كافة العناصر والتبعيات وقيود البناء التي تم استخدامها في عملية الإنشاء. وقد تم تسليط الضوء عليها في الجدول أدناه.

المتطلبات المشتركة

تنطبق المتطلبات العامة على عناصر البرامج في المستوى 4 من SLSA. ومن المتوقع أن تلبي كل قطعة أثرية موثوقة هذه المتطلبات. وهي تتضمن متطلبات الأمان الأساسية والسجلات التي توضح بالتفصيل كافة عمليات الوصول الفعلي وعن بعد. تنص المتطلبات المشتركة أيضًا على عدد صغير من مسؤولي النظام الأساسي الذين يمكنهم تجاوز الشروط الواردة في وثائق SLSA.