مستويات سلسلة الإمداد للمنتجات البرمجية، SLSA، وتُنطق «سالسا»، إطار أمني طورته Google وتتولى صيانته الآن OpenSSF، ويحدد مجموعة متدرجة من المتطلبات لحماية سلامة المنتجات البرمجية طوال عملية البناء والتوزيع. ويعالج SLSA متجه هجوم محددًا يتزايد استغلاله: اختراق البرمجيات بين مستودع الشيفرة المصدرية والمنتج البرمجي الذي يصل إلى المستخدمين النهائيين، أي مسار البناء ومستودع المنتجات وقناة التوزيع. وقد استغلت هجمات SolarWinds وXZ Utils وهجوم سلسلة الإمداد على 3CX جميعها هذه الفجوة. ويوفر SLSA إطارًا منظمًا لسدها.
نظام مستويات SLSA هو المفتاح المفاهيمي. إذ يحدد SLSA أربعة مستويات من الضمان المتزايد قوةً بشأن مصدر البرمجيات وسلامة البناء. يتطلب المستوى 1 أن تُولّد عملية البناء بيانات المصدر، أي توثيق كيفية بناء المنتج. وهو مستوى الدخول ويوفر حدًا أدنى من الضمان الأمني: إذ يمكن تزوير بيانات المصدر، وعملية البناء غير معزولة، ولا يُشترط أي تحقق. ويضيف المستوى 2 أن خدمة البناء هي التي تولّد بيانات المصدر لا المطوّر، مما يجعلها أكثر مصداقية. ويتطلب المستوى 3 أن تولّد خدمة البناء بيانات مصدر لا يستطيع المطوّر تزويرها، لأنها موقّعة من خدمة البناء. ويضيف المستوى 4 عمليات بناء محكمة العزل وقابلة لإعادة الإنتاج، إذ يكون البناء معزولًا تمامًا عن الشبكة، والاعتماديات محددة بالكامل، والمدخلات نفسها تُنتج المخرجات نفسها بشكل قابل للتحقق.
تكمن الأهمية العملية لمستويات SLSA بالنسبة لـTPRM في أن ادعاءات الامتثال لـSLSA دون تحديد المستوى عديمة المعنى في جوهرها. فالمورّد الممتثل للمستوى 1 من SLSA قد وثّق عملية البناء لديه، أما المورّد الممتثل للمستوى 3 من SLSA فلديه بيانات مصدر للبناء غير قابلة للتزوير صادرة عن خدمة بناء معزولة. وهاتان وضعيتان أمنيتان مختلفتان جوهريًا. وفريق TPRM الذي يسأل «هل أنتم ممتثلون لـSLSA؟» ويتلقى «نعم» دون أن يسأل «بأي مستوى؟» يكون قد حصل على تأكيد قد يصف أي شيء، من مستند نصي عن عملية البناء إلى مسار بناء معزول تم التحقق منه تشفيريًا.
يوضح منظور المهاجم سبب أهمية المستوى. فقد اخترق هجوم SolarWinds مسار البناء، أي العملية الواقعة بين الشيفرة المصدرية والمنتج المُجمَّع. وفي المستوى 1 من SLSA، يمر هذا الهجوم دون اكتشاف إلى حد كبير: إذ تُولَّد بيانات المصدر بالعملية نفسها التي يتحكم فيها المهاجم، وتعكس بيانات المصدر المزوّرة المنتج الخبيث. أما في المستوى 3 من SLSA، فإن خدمة البناء تولّد بيانات مصدر غير قابلة للتزوير، وبالتالي لا يمكن لمنتج خبيث لم تبنِه خدمة البناء الموثّقة إنتاج بيانات مصدر صالحة من المستوى 3. وكلما ارتفع مستوى SLSA، ازداد ما يتعين على المهاجم اختراقه لإنتاج منتج صالح ببيانات مصدر صالحة.
واقع التبني هو سياق الحوكمة. فالمستوى 4 من SLSA، وهو أعلى مستويات الضمان، بالغ الصعوبة في تحقيقه على نطاق واسع. وكثير من كبار موردي البرمجيات في المستوى 1 أو 2. والمستوى 3 قابل للتحقيق بالاستثمار في البنية التحتية للبناء، أما المستوى 4 فالتزام معماري كبير. ولأغراض TPRM، فإن السؤال ذا الصلة ليس ما إذا كان المورّد قد بلغ المستوى 4، بل ما إذا كان يتقدم بفاعلية عبر مستويات SLSA وما إذا كان مستواه الحالي مناسبًا لمخاطر البرمجيات التي يقدمها.
لماذا يهم هذا
يكتسب SLSA أهمية بالنسبة لـTPRM لأن هجمات سلاسل إمداد البرمجيات، وتحديدًا اختراق مسارات البناء وتوزيع المنتجات، من بين أشد متجهات الهجوم المستغلة حاليًا أثرًا وأصعبها اكتشافًا. والمؤسسة التي تؤكد امتثال المورّد لـSLSA دون معرفة المستوى لم تؤكد ضمانًا ذا مغزى لسلامة البناء. أما المؤسسة التي تفهم مستويات SLSA فيمكنها طرح الأسئلة الصحيحة ووضع توقعات مناسبة للبرمجيات التي تنشرها.
نطاق التأثير اللاحق هو الشاغل المحدد في سلسلة الإمداد. فالبرمجيات التي تُخترق في مسار البناء تحتوي على شيفرة المهاجم في كل منتج مُجمَّع يُوزَّع على كل عميل. واختراق واحد لمسار البناء يصل إلى كل مؤسسة تنشر تلك البرمجيات، كما أثبتت SolarWinds على نطاق واسع. وتجعل متطلبات المستويين 3 و4 من SLSA تنفيذ هذا الهجوم دون اكتشاف أصعب بكثير.
أين تخطئ معظم الفرق
الإخفاق الأكثر تكرارًا هو قبول تأكيد الامتثال لـSLSA دون السؤال عن المستوى، أي معاملة SLSA على أنه شهادة بنعم أو لا بدلًا من إطار متدرج. والإخفاق الثاني هو عدم وجود متطلب لحد أدنى من مستوى SLSA لموردي البرمجيات الحرجة، أي قبول أي مستوى بصرف النظر عن ملف مخاطر البرمجيات.
- تأكيد SLSA دون تحديد المستوى، فسؤال الامتثال بنعم أو لا يُنتج إجابة عديمة الفائدة
- عدم وجود متطلب لحد أدنى من المستوى لموردي البرمجيات الحرجة
- قبول المستوى 1 من SLSA لبرمجيات عالية الأهمية ذات نطاق تأثير كبير
- عدم فهم ما يمنعه كل مستوى، وعدم تطبيق منظور المهاجم
- عدم وجود متطلب للتقدم في SLSA، إذ لا يُتوقع من الموردين التحسن بمرور الوقت
كيف تبدو الممارسة الجيدة
تسأل برامج سلاسل إمداد البرمجيات الناضجة تحديدًا عن مستوى SLSA، وتضع توقعات لحد أدنى من المستوى تتدرج مع أهمية البرمجيات، وتطلب شهادات المصدر دليلًا بدلًا من الاكتفاء بالردود على الاستبيانات.
- السؤال تحديدًا عن مستوى SLSA، لا عن الامتثال بنعم أو لا
- تحديد الحد الأدنى للمستوى حسب الأهمية، المستوى 2 حدًا أدنى لمعظم البرمجيات التجارية، والمستوى 3 للبرمجيات الحرجة
- طلب شهادة المصدر دليلًا إلى جانب ادعاء المستوى
- طلب خارطة طريق SLSA، أي المستوى الذي يستهدفه المورّد والجدول الزمني
- التحقق من مصدر المنتجات البرمجية الحرجة باستخدام الأدوات
الأدوات
التحقق من SLSA، Sigstore/cosign للتحقق من المصدر؛ وأدوات إطار SLSA على slsa.dev
توفر أداة cosign من Sigstore الآلية اللازمة للتحقق من شهادات مصدر SLSA، أي التأكد من أن ادعاء المصدر لمنتج برمجي صالح ومطابق للمنتج. وبالنسبة لممارسي TPRM، فإن مطالبة المورّد بتقديم شهادة مصدر SLSA لإصدار محدد والتحقق منها باستخدام cosign هو الاختبار العملي الذي يؤكد ما إذا كان مستوى SLSA المُدّعى يُنتج منتجات قابلة للتحقق.
أنظمة البناء، GitHub Actions مع مولّد SLSA، وGoogle Cloud Build مع دعم SLSA
باتت منصات CI/CD الكبرى تتضمن توليد بيانات مصدر SLSA ميزةً مدعومة. إذ يُنتج مولّد SLSA في GitHub Actions بيانات مصدر متوافقة مع المستوى 3 لعمليات البناء في GitHub Actions. وبالنسبة لتقييمات TPRM، فإن السؤال عمّا إذا كان نظام البناء لدى المورّد يدعم توليد بيانات مصدر SLSA وبأي مستوى يمثل سؤالًا محددًا حول البنية التحتية للبناء.
تحديات الحوكمة
يتمثل تحدي الحوكمة في SLSA ضمن TPRM في فجوة الخبرة. فـSLSA معيار تقني يتطلب فهمًا للبنية التحتية للبناء لتقييمه تقييمًا ذا مغزى. وقد تواجه فرق TPRM التي لا تملك خبرة في أمن البناء صعوبة في تقييم ادعاءات مستوى SLSA دون دعم من المطوّرين. ويكمن حل الحوكمة في إعداد دليل مرجعي لمستويات SLSA يمكّن محللي TPRM من طرح الأسئلة الصحيحة وتفسير الردود تفسيرًا مناسبًا، مع استشارة فريق المطوّرين بشأن موردي البرمجيات الحرجة.
- تحديد متطلبات مستوى SLSA حسب فئة أهمية البرمجيات
- السؤال عن مستوى SLSA وشهادة المصدر، لا عن الامتثال بنعم أو لا
- طلب خارطة طريق SLSA من الموردين في المستويات الأدنى
- التحقق من شهادات المصدر للمنتجات البرمجية الحرجة
- بناء فهم محللي TPRM لمستويات SLSA، أي ما يمنعه كل مستوى
إذا كنت فريقًا صغيرًا
بالنسبة لأهم ثلاثة موردي برمجيات لديك، أي المنتجات التي سيكون اختراق سلسلة إمدادها الأشد ضررًا، اطرح سؤالين محددين. الأول: بأي مستوى من SLSA تمتثل عملية البناء لديكم، وهل يمكنكم تقديم شهادة مصدر لأحدث إصدار لكم؟ والثاني: هل نظام البناء لديكم متكامل مع Sigstore أو إطار مكافئ للتحقق من المصدر، وهل يمكننا التحقق من الشهادة بشكل مستقل؟ سيخبرك هذان السؤالان بأكثر بكثير عن السلامة الفعلية للبناء مما يخبرك به تأكيد امتثال لـSLSA بنعم أو لا.
- السؤال تحديدًا عن مستوى SLSA لدى أهم ثلاثة موردي برمجيات حرجة
- طلب شهادة مصدر لإصدار حديث
- السؤال عمّا إذا كان يمكن التحقق من المصدر بشكل مستقل
- تحديد متطلب الحد الأدنى لمستوى SLSA للبرمجيات الحرجة
ما الذي ينبغي اشتراطه
اسأل مباشرةً:
«بأي مستوى من SLSA تمتثل عملية البناء لديكم، وهل يمكنكم تقديم شهادة مصدر قابلة للتحقق لأحدث إصدار رئيسي لكم تؤكد أن المنتج بُني من الشيفرة المصدرية المذكورة بواسطة خدمة بناء موثّقة الهوية؟»
ما تتوقعه دليلًا
- مستوى SLSA المحدد، لا امتثال بنعم أو لا
- شهادة مصدر لإصدار حديث
- طريقة التحقق من الشهادة
- خارطة طريق SLSA إذا كان المستوى أدنى من المستهدف
ينبغي أن يُسأل المورّد الذي يؤكد امتثاله لـSLSA عن المستوى. فالامتثال للمستوى 1 والامتثال للمستوى 3 لا يقدمان الضمان نفسه، والمستوى هو ما يحدد معنى تأكيد الامتثال.
كيف تُثبت ذلك
- متطلبات مستوى SLSA حسب أهمية البرمجيات
- سجلات شهادات المصدر
- التحقق من المصدر للبرمجيات الحرجة
- تتبّع خارطة طريق SLSA لدى المورّد
الخلاصة الرئيسية
الامتثال لـSLSA: مؤكَّد. المستوى: 1. معنى المستوى 1: عملية البناء موثّقة. ما يمنعه: لا شيء يكترث له المهاجم. المستوى 1 من SLSA توثيق، والمستوى 3 بيانات مصدر غير قابلة للتزوير من خدمة بناء معزولة، والمستوى 4 عمليات بناء محكمة العزل وقابلة لإعادة الإنتاج. وهجوم SolarWinds، الذي اخترق مسار البناء لإدخال شيفرة خبيثة في منتجات موقّعة، يمنعه المستوى 3 لأن البناء الخبيث لا يستطيع إنتاج بيانات مصدر صالحة من المستوى 3. والمستوى هو ما يحدد معنى تأكيد الامتثال. وأسئلة الامتثال لـSLSA بنعم أو لا تُنتج إجابات بنعم أو لا لا تصف شيئًا مفيدًا عن سلامة البناء.