يدمج نهج DevSecOps قرارات وأدلة الأمان في عملية تسليم البرمجيات بدلاً من التعامل معها كمرحلة مراجعة نهائية. وفي مسار التكامل المستمر والتسليم المستمر (CI/CD) الذي يعتمد على سحابات متعددة، لا يتمحور السؤال الرئيسي حول السحابة التي تشغّل التطبيق، بل حول المكون القادر على تعديل الكود المصدري، أو تنفيذ كود البناء (build code)، أو نشر نتاج برمجي (artifact)، أو استدعاء واجهة برمجة تطبيقات (API) للنشر خاصة بمزود الخدمة؛ فهذه القدرات هي التي تحدد النطاق الأمني.
في هذه الدورة، تشمل قائمة مزودي الخدمة كلاً من AWS وMicrosoft Azure وGoogle Cloud. يمتلك كل مزود حدوداً خاصة بموارده وهويات المستخدمين لديه، بينما تتولى “لوحة تحكم CI” مركزية تنسيق تعريفات المسار، وجدولة المهام، وعمليات الموافقة، وتسجيل النتائج. يحدد هذا الدرس نطاقاً واحداً لحمل العمل (workload) ليتسنى لاحقاً تقييم ضوابط الأمان استناداً إلى هويات ونتاجات برمجية وأهداف نشر محددة وملموسة.
لا يمكن البدء في مراجعة أمنية لمسار يعمل عبر سحابات متعددة ما لم تتضح الأجزاء المشمولة في النطاق؛ إذ يمكن لأداة تنفيذ (runner) أو سجل (registry) يقع خارج هذا النطاق تعديل إصدار برمجي دون خضوعه للمراجعة. وتُعرَّف حدود المسار بأنها مجموعة المستودعات، وخدمات لوحة التحكم، وأدوات التنفيذ، والهويات، ومخازن النتاجات البرمجية، وواجهات النشر التي تشترك في تحويل التغيير البرمجي إلى إصدار نهائي. تبدأ هذه الحدود عند النقطة التي يمكن فيها لتغيير في المستودع أن يؤثر على سلوك المسار، وتمتد لتشمل إجراءات واجهة برمجة تطبيقات المزود التي تنشئ حمل العمل أو تعدله. أما طلبات التشغيل (runtime requests) الموجهة للتطبيق المنشور فتقع خارج هذه الحدود، وإن كان من الممكن لاحقاً ربط الإصدار البرمجي بسلوك التشغيل الفعلي.
لا تقع لوحة التحكم المركزية -المسماة ci-control- تلقائياً داخل بيئة AWS أو Azure أو Google Cloud؛ إذ تقوم أدوات التنفيذ التابعة لها بتنفيذ مهام البناء والنشر، ثم تُجري عملية المصادقة بشكل منفصل مع كل من حساب AWS المسمى dev واشتراك Azure المسمى dev ومشروع Google Cloud المسمى orders-dev. وتصبح أداة التنفيذ جزءاً من حدود مزود الخدمة فقط عند استضافتها ذاتياً داخل بيئته؛ فموقعها يغير مستوى التعرض للشبكة وآليات الهوية المتاحة، لكنه لا يلغي الحاجة إلى الحصول على صلاحيات محددة النطاق من مزود الخدمة.
يمكننا الآن تتبع المكونات التي تتجاوز حدود كل مزود خدمة.
يقلل مسار العمل (pipeline) المركزي من التكرار فقط عند تطبيق ضوابطه بشكل متسق. تحدث ظاهرة انتشار بيانات الاعتماد (credential sprawl) عندما تحتفظ العديد من المهام أو المستودعات أو بيئات المزودين ببيانات اعتماد منفصلة ذات صلاحيات واسعة وعمر افتراضي طويل. يمكن لبيانات اعتماد النشر المسربة أن تظل صالحة حتى بعد انتهاء المهمة التي احتاجتها، كما أن استخدام بيانات اعتماد مشتركة يجعل سجلات التدقيق عاجزة عن التمييز بين عمليات تشغيل المسار المختلفة. في المقابل، تحد بيانات الاعتماد قصيرة العمر -التي تُنشأ لكل عملية تشغيل- من كل من العمر الافتراضي للاستخدام ونطاق مسار النشر المتأثر.
يمكن أن يحدث تباين (أو انحراف) في ضوابط الفحص أيضاً؛ فإجراء فحص للثغرات الأمنية باستخدام حد معين للفشل في مسار خاص بـ AWS، وحد مختلف في مسار خاص بـ Azure أو Google Cloud، لا يمثل قراراً أمنياً موحداً، حتى وإن استخدم كل مسار أداة الفحص ذاتها. يجب أن يسجل مسار العمل العنصر البرمجي (artifact) الذي تم تقييمه، ومجموعة القواعد المطبقة، والنتيجة، ومخرجات مرحلة التحقق (gate). إن سجل المهمة الناجحة يثبت فقط أن المهمة أبلغت عن نجاحها خلال الفترة الزمنية المسجلة؛ لكنه لا يثبت بمفرده أن جميع الموارد لدى المزود تطابق الآن الحالة المقصودة.
تضيف عملية النسخ عبر السحابات المختلفة حداً أو فاصلاً إضافياً؛ إذ يمكن استبدال الصورة المنسوخة بين السجلات (registries)، أو نسخها بشكل غير مكتمل، أو ترقيتها (نقلها لمرحلة تالية) تحت وسم (tag) مألوف. تحدد الوسوم مرجعاً قابلاً للتغيير، بينما تحدد “البصمة الرقمية” (digest) محتوى الصورة المحدد. وتتمثل القاعدة القابلة لإعادة الاستخدام في تفويض كل إجراء خاص بالمزود بشكل مستقل، ونقل أدلة تثبت هوية العنصر البرمجي الدقيق عبر كل مرحلة تسليم.
عبء العمل قيد التشغيل هو orders-api، وهي خدمة تستمع للطلبات عبر المنفذ 8080. يوجد المصدر البرمجي للتطبيق في المستودع orders-api-repo، بينما توجد تعريفات البنية التحتية في المستودع orders-infra-repo. تنتج عملية البناء صورة حاوية (container image) افتراضية باسم orders-api:1.0؛ ويتم تقييم تغييرات البنية التحتية باعتبارها حزمة Terraform باسم orders-infra. يتيح الفصل بين مستودعات المصدر ومستودعات البنية التحتية للضوابط اللاحقة تعيين أذونات مختلفة للمراجعة والتنفيذ والنشر لكل نوع من أنواع التغيير.
تُنقل الصورة (تتم ترقيتها) إلى aws-ecr/orders-api و azure-acr/ordersapi و gcp-ar/orders-api، ثم تُنشر عبر إجراءات API خاصة بكل مزود في نطاقات التطوير المحددة لديهم. تعني عملية النقل هذه نسخ نفس البصمة الرقمية (digest) للصورة التي تم التحقق منها إلى كل سجل، وليس إعادة البناء من المصدر لكل سحابة؛ فإعادة البناء ستؤدي إلى إنشاء عناصر برمجية منفصلة قد تختلف محتوياتها وأدلة التحقق الخاصة بها رغم اشتراكها في الوسم orders-api:1.0.
يمكننا فحص مسارات العناصر البرمجية والبنية التحتية التي يبرزها عبء العمل هذا بوضوح.