الضمان المستمر: ممارسة متكاملة لأمن سلسلة توريد البرمجيات

هذه هو المقال الثاني في سلسلة من المقالات التي تدرس إرشادات NIST SP 800-218 الجديدة. يمكن العثور على المادة الأولى هنا.

الضمان المستمر:
ممارسة متكاملة لأمن سلسلة توريد البرمجيات

كما ناقشنا في مقالتنا السابقة، فإن المبادئ التوجيهية التي وضعها المعهد الوطني الأمريكي للمعايير والتكنولوجيا (NIST) سوف تغير بشكل كبير الطريقة التي يتم بها توفير المنتجات والخدمات البرمجية لحكومة الولايات المتحدة. 

على وجه التحديد، نيست SP 800-218 ينشئ مجموعة من ممارسات تطوير البرمجيات الآمنة عالية المستوى والتي سيتم دمجها في كل دورة حياة لتطوير البرمجيات (SDLC). ومن المتوقع أن يؤدي دمج هذه الممارسات في جميع أنحاء سلسلة توريد البرامج إلى الترويج لمنتجات وخدمات أكثر أمانًا لتقديمها ليس فقط إلى حكومة الولايات المتحدة، ولكن في النهاية عبر الصناعات وفي جميع أنحاء العالم. 

في هذه المقالة، نلقي نظرة على الدور الحاسم للتأكيد المستمر (CA) في تلبية هذه المتطلبات الجديدة. 

نظرة عامة: ما هو الضمان المستمر وكيف يعمل؟ 

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

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

إن النتيجة المباشرة لـ CA هي وسيلة لضمان عدم التلاعب بمنتجات البرمجيات وإجراء الاختبارات الهامة المتعلقة بالأمن أثناء التطوير، ولكن هناك الكثير الذي يمكن كسبه منه.

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

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

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

لماذا المستمر؟

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

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

كل هذه العوامل مجتمعة تفرض علينا اختبار المكونات بشكل مستمر وفقًا لمعايير الأمان المحددة للتحقق من أن العمليات المستخدمة لا تزال متوافقة مع سياسة الأمان. 

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

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

رفع مستوى أمان البرمجيات

تؤدي هجمات سلسلة توريد البرامج إلى تغيير السلوك المتوقع لمكونات البرامج. تعتمد هذه الهجمات اليوم على عدم قدرة مستهلكي البرامج ومنتجيها على التحقق من سلامة مكونات البرامج. 

ومع ذلك، من خلال التوقيع على الأدلة من كل جزء من دورة حياة التطوير - بدءًا من التبعيات مفتوحة المصدر وحتى المنتج النهائي - والمقارنة المستمرة لهذه الأدلة بما هو متوقع، سيواجه المهاجمون صعوبة أكبر عند محاولة التلاعب بالملفات أو الأدوات أو البيانات. السلوك المتوقع لخط أنابيب CI/CD الخاص بك.     

جمع الأدلة: أمثلة وتوصيات

فيما يلي بعض الأمثلة على الأدلة التي يمكن جمعها عبر SDLC:

وإليك أنواع السياسات التي يمكن الاستفادة منها باستخدام هذه الأدلة:

مستقبل ضمان الكود المستمر

في فبراير 2022 إطار تطوير البرمجيات الآمنة (قوات دفاع جنوب السودان)، يقترح NIST أن تنفيذ أدوات الأمان عبر عملية التطوير يجب أن يعتمد بشكل كبير على الأتمتة. ويتوافق نهجنا في التأكيد المستمر مع هذه التوصية. 

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

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