العملاء يشدّدون DevSecOps: المقاولون تحت الفحص في كل خطوة من خطوات البناء

في ديسمبر 2020 وصل تحديث SolarWinds Orion المحمَّل ببرمجية تروجان إلى نحو 18 000 عميل للشركة. وأعادت هذه الحادثة تذكير القطاع بأن الضعف قد لا يكمن في المنتج نفسه، بل في الطريق الذي يسلكه إلى العميل. والسوق الروسية تصل إلى الاستنتاج نفسه. فبحسب مادة TAdviser، يتعمّق العملاء أكثر فأكثر في مبدأ انعدام الثقة تجاه مقاولي تقنية المعلومات، ويطالبون بـ«خط إنتاج معقَّم» للتطوير مع فحص متكرر للشيفرة. وأساس هذا النهج هو DevSecOps، أي دورة تطوير البرمجيات التي يكون الأمن فيها جزءًا من كل مرحلة، لا إجراءً يُضاف قبل الإصدار.

من أين ينبع انعدام الثقة

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

والأمثلة معروفة. فقد أظهرت ثغرة Log4Shell في أواخر عام 2021 كيف تجد مكتبة تسجيل واحدة طريقها إلى آلاف المنتجات دون أن يعلم أصحابها بذلك. أما الباب الخلفي في أداة الأرشفة XZ Utils (CVE-2024-3094)، الذي اكتُشف في 2024، فقد دُسّ عبر هندسة اجتماعية طويلة استهدفت القائم على صيانة المشروع. ويقضي مبدأ انعدام الثقة، الذي صيغ رسميًا في NIST SP 800-207، بالتحقق من كل طرف ومن كل إجراء. واليوم يُطبَّق هذا المبدأ على التطوير.

كيف يبدو «خط الإنتاج المعقَّم»

تتناول مادة TAdviser اتجاهًا عامًا لا معيارًا موحدًا، ولذلك تختلف مجموعة الإجراءات من عميل إلى آخر. وتبدو البنية النموذجية على النحو التالي:

• بيئة بناء معزولة بلا اتصال بالإنترنت، مع مجموعة محدودة من الاعتماديات الخارجية؛
• تحليل ساكن للشيفرة (SAST) عند كل commit، وتحليل ديناميكي (DAST) على بيئات الاختبار؛
• تحليل تركيبي (SCA): جرد للمكونات الخارجية وبحث عن الثغرات المعروفة؛
• SBOM، أي قائمة بجميع مكونات البناء، كعنصر إلزامي ضمن التسليم؛
• فحص المستودعات بحثًا عن الأسرار: المفاتيح والرموز المميزة وكلمات المرور؛
• مراجعة إلزامية للشيفرة من شخص ثانٍ، وتوقيع العناصر المبنية؛
• إعادة فحص الشيفرة المصدرية والبناء لدى العميل.

والكلمة المفتاحية هنا هي «المتكرر». فالشيفرة نفسها تُحلَّل لدى المنفِّذ، ثم لدى العميل، وأحيانًا لدى مختبر مستقل أيضًا. وكل طبقة تلتقط ما فاتته الطبقة السابقة. وهي تنطلق كذلك من أن السابقة ربما تعرضت للاختراق.

الكلفة على المقاول

يعني ذلك للمنفِّذ ارتفاعًا في التكاليف وإعادة بناء للعمليات. فهو يحتاج إلى بيئات بناء مخصصة، وتراخيص لأدوات التحليل، ومختصين في التطوير الآمن، وانضباطٍ كثيرًا ما تفتقر إليه الفرق الصغيرة. ويستفيد المتكاملون الناضجون الذين يدمجون DevSecOps أصلًا في إنتاجهم. أما الاستوديوهات الصغيرة فسيتعين عليها إما اللحاق بالمستوى المطلوب، وإما التوجه إلى قطاعات أقل صرامة في متطلباتها.

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

من أين نبدأ

ينبغي للعميل أن يثبّت متطلبات التطوير الآمن في العقد: صيغة SBOM، ودورية الفحص، وحق التدقيق، وآلية الاستجابة للثغرات المكتشفة. ومن المعقول تصنيف المقاولين بحسب أهمية الأنظمة، وعدم فرض أقصى درجات الرقابة على الجميع بالتساوي.

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