التحقق من مصدر البرمجيات

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

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

يمثّل ارتباط البناء القابل لإعادة الإنتاج آلية التحقق من المصدر. فالمخرَج البرمجي يكون مصدره قابلًا للتحقق إذا: وُجدت شهادة مصدر (أنشأها نظام البناء لا المطوّر) تسجّل عملية إيداع الشيفرة المصدرية ومدخلات البناء وبيئة البناء؛ وأمكن إعادة بناء المخرَج بشكل مستقل من عملية الإيداع تلك فينتج ملفًا تنفيذيًا مطابقًا؛ وكانت شهادة المصدر موقّعة من نظام البناء ومسجلة في سجل شفافية غير قابل للتغيير. وعند استيفاء هذه الشروط، يستطيع المستهلك التحقق من أن المخرَج الذي تلقاه يطابق المخرَج الذي أنتجته عملية البناء المعلنة من الشيفرة المصدرية المعلنة، فيكشف اختراقات بنية التوزيع التي تنتج مخرجات مختلفة.

لماذا يهم هذا

يهمّ التحقق من مصدر البرمجيات TPRM لأن اختراقات بنية التوزيع ناقل هجوم موثّق، وهي الآلية المستخدمة في هجوم NotPetya (عبر بنية تحديثات M.E.Doc)، وهجوم ASUS Live Update، وحوادث مماثلة في سلسلة التوريد. والمؤسسة التي تتحقق من التوقيعات دون التحقق من المصدر تكون قد تأكدت من أن مفتاح التوقيع قد استُخدم، لا من أن عملية البناء المشروعة أنتجت ما وقّعه المفتاح.

• قبول التحقق من التوقيع بوصفه تأكيدًا للمصدر
• عدم مراعاة اختراق بنية التوزيع في نموذج أمن تسليم البرمجيات
• عدم طلب شهادات المصدر أو التحقق منها لتحديثات البرمجيات
• عدم تقييم قابلية إعادة الإنتاج للبرمجيات الحيوية
• غياب التحقق عبر سجل الشفافية من عملية نشر البرمجيات

كيف تبدو الممارسة الجيدة

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

• طلب شهادة مصدر SLSA لتحديثات البرمجيات الحيوية
• التحقق عبر سجل الشفافية قبل النشر: Sigstore Rekor أو ما يعادله
• التحقق من قابلية إعادة الإنتاج للبرمجيات الأعلى أهمية: تأكيد حتمية البناء
• تقييم أمن بنية التوزيع ضمن مراجعة أمن البناء لدى المورّد
• الإخطار بالتحديثات عبر قناة مستقلة: التحقق من التحديثات عبر قناة منفصلة عن بنية التسليم

الأدوات

المصدر: cosign للتحقق من شهادات مصدر SLSA؛ وRekor للاستعلام في سجل الشفافية

تتحقق أداة cosign من Sigstore من شهادات مصدر SLSA مقابل سجل الشفافية Rekor، فتؤكد أن شهادة مصدر المخرَج البرمجي صالحة وأنها سُجّلت في الوقت المتوقع ببيانات اعتماد نظام البناء المتوقعة. وبالنسبة لتحديثات البرمجيات الحيوية، فإن إجراء التحقق عبر cosign قبل النشر هو فحص المصدر المحدد الذي يتطلبه كشف اختراق بنية التوزيع.

قابلية إعادة الإنتاج: بنية مشروع Reproducible Builds؛ وrebuilderd للتحقق الآلي عبر إعادة البناء

يوفر مشروع Reproducible Builds أدوات وبنية مجتمعية للتحقق من أن عمليات بناء البرمجيات حتمية، أي أن الشيفرة المصدرية نفسها تنتج الملف التنفيذي نفسه. وبالنسبة لبرمجيات البنية التحتية الحيوية، فإن المشاركة في التحقق من البناء القابل لإعادة الإنتاج توفر التأكيد المستقل بأن المخرَج الموزَّع يطابق الشيفرة المصدرية المنشورة.

تحديات الحوكمة

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

• اطلب شهادات مصدر SLSA لتحديثات البرمجيات الحيوية
• تحقّق من الشهادات باستخدام cosign قبل نشر التحديثات الحيوية
• قيّم أمن بنية التوزيع ضمن مراجعة أمن البناء لدى المورّد
• اشترط التسجيل في سجل الشفافية لأحداث التوقيع
• طبّق التحقق من التحديثات عبر قناة مستقلة للبرمجيات الحيوية

إذا كنت فريقًا صغيرًا

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

• اطلب شهادة مصدر SLSA قبل نشر التحديثات الحيوية
• تحقّق من الشهادات باستخدام cosign قبل النشر
• قيّم أمن بنية التوزيع ضمن مراجعة المورّد
• طبّق التحقق من التحديثات عبر قناة مستقلة للبرمجيات الحيوية

ما الذي ينبغي اشتراطه

اسأل مباشرةً:

"هل تنتجون شهادات مصدر SLSA لإصدارات برمجياتكم؟ وهل يمكنني التحقق من الشهادة لإصدار محدد باستخدام cosign مقابل سجل الشفافية Sigstore Rekor للتأكد من أن المخرَج الموزَّع يطابق ما أنتجه نظام البناء لديكم؟"

ما تتوقعه دليلًا

• شهادة مصدر SLSA لإصدارات محددة
• عملية التحقق من قيود سجل الشفافية
• مستوى SLSA وخارطة الطريق
• وصف أمن بنية التوزيع

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

كيف تُثبت ذلك

• سجلات التحقق من شهادات المصدر للتحديثات الحيوية
• تطبيق التحقق من سجل الشفافية
• تقييم أمن بنية التوزيع
• اشتراط مصدر SLSA لمستوى البرمجيات الحيوية

الخلاصة الرئيسية

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