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

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

ما حقيقة أمن سلسلة توريد البرمجيات؟

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

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

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

يتوزع سطح الهجوم على خمس طبقات لا تفحصها معظم تقييمات المخاطر أبدًا:

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

لماذا يهم هذا

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

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

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

أين تخطئ معظم الفرق

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

أنماط شائعة تترك المؤسسات معرّضة للخطر:

• عدم وجود اشتراط تعاقدي يُلزم الموردين بتقديم قائمة مكونات البرمجيات (SBOM)، وهي مخزون منظم لكل مكوّن يتضمنه منتجهم
• قبول تحديثات البرمجيات من الموردين دون أي تحقق من سلامتها
• مسارات بناء ونشر مؤتمتة تعمل ببيانات اعتماد واسعة وطويلة الأمد لا يراجعها أحد
• التعامل مع مخاطر التبعيات مفتوحة المصدر بوصفها مشكلة هندسية لا مسألة من مسائل مخاطر الأطراف الثالثة

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

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

ستجد في الممارسة العملية:

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

الأدوات

ترتبط الأدوات أدناه مباشرةً بضوابط المخاطر التي ينبغي لممارس TPRM أن يسأل الموردين عنها.

توليد SBOM: Anchore، وSyft، وTern

تنتج هذه الأدوات مخزونات منظمة للمكونات بصيغ قياسية (CycloneDX وSPDX). وحين يُكشف عن ثغرة جديدة، يمكنك الاستعلام في مخزون SBOM لدى الموردين في دقائق بدلًا من انتظار رد المورّد أيامًا.

SLSA & مصدر البناء: SLSA GitHub Actions، وTekton Chains، وin-toto

تولّد هذه الأدوات شهادات موقّعة توثّق بدقة كيف بُنيت البرمجيات. وسؤال المورّد عن مستوى SLSA الذي حققه سؤال أدق بكثير من سؤاله عمّا إذا كان يتبع دورة حياة تطوير آمنة.

توقيع المخرجات: Sigstore، وNotary v2

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

تحليل مكونات البرمجيات: Snyk، وBlack Duck، وSonatype Nexus

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

أمن مسار البناء: HashiCorp Vault، وAWS Secrets Manager، وAzure Key Vault

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

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

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

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

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

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

• استخدم أداة SCA مجانية، مثل الفئة المجانية من Snyk أو أداتي Syft وGrype مفتوحتي المصدر، على أي برمجيات تُدار داخليًا
• اشترط الإخطار خلال 72 ساعة بأي تحديث يؤثر في مكونات موجودة في بيئتك
• اسأل تحديدًا عن بيانات الاعتماد التي تملك صلاحية بناء البرمجيات المسلّمة إليك ونشرها

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

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

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

"هل يمكنكم تقديم قائمة مكونات برمجيات حديثة للمنتج الذي تسلّمونه لنا، تُحدَّث مع كل إصدار؟"

"كيف تضمنون سلامة مسار البناء لديكم، وتحديدًا ما يتعلق بتوقيع المخرجات وحوكمة بيانات الاعتماد المستخدمة في عملية CI/CD؟"

"ما مستوى نضج SLSA الذي حققتموه أو تعملون بنشاط على تحقيقه؟"

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

• SBOM قابلة للقراءة آليًا بصيغة CycloneDX أو SPDX، محدّثة حتى آخر إصدار
• توثيق ممارسات توقيع المخرجات وإدارة المفاتيح
• دليل على أن بيانات اعتماد مسار البناء قصيرة الأمد ومحدودة النطاق، لا ثابتة وواسعة
• عملية محددة لإخطار العملاء حين يتأثر مكوّن بثغرة جديدة

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

كيف تُثبت ذلك

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

• احتفظ بمخزون لموردي البرمجيات يتضمن مستويات المخاطر وحالة جمع SBOM
• وثّق طلبات SBOM المعلقة والجداول الزمنية لمعالجة الفجوات
• أدرج ضوابط مسار البناء وCI/CD بنودًا صريحة في تقييمات الموردين
• سجّل أحداث تحديث البرمجيات من الموردين الحيويين وأي خطوات تحقق اتُّخذت قبل النشر

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

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

في عام 2020، أوصل تحديث برمجي روتيني من مورّد موثوق لبرمجيات مراقبة الشبكات بابًا خلفيًا خفيًا إلى آلاف المؤسسات، بما فيها وكالات اتحادية أمريكية. كان المورّد هو SolarWinds. وكان التحديث موقّعًا ومرقّمًا بإصدار وصادرًا من مصدر وافق عليه كل فريق أمني. لم يكن أحد مهملًا، ولم يُغفل أحد علامة تحذير واضحة..... مقال رؤى الجمعية.

#TPRM #DoNoBeLarry #VerisqAi #LiveThreat #SupplyChainRisk # #SupplyChainSoftwareRisk #Cybersecurity #TPRM #VendorRisk #ThreatIntel