أمان سلسلة توريد البرمجيات: دليل شامل لفرق الهندسة

بقلم

مقدمة: لماذا يُعدّ أمان سلسلة توريد البرمجيات مهمًا

في ديسمبر 2020، اكتشف العالم أن SolarWinds — وهي منصة إدارة تقنية المعلومات الموثوقة على نطاق واسع — قد تعرضت للاختراق. قام المهاجمون بحقن كود خبيث في عملية build لبرنامج Orion، ووزّعوا تحديثًا ملوثًا على ما يقارب 18,000 مؤسسة، بما في ذلك وكالات حكومية أمريكية وشركات مدرجة في Fortune 500. لم يكن الهجوم موجهًا ضد مستودع الكود المصدري لـ SolarWinds مباشرة، بل ضد pipeline الخاص بـ build. أعاد هذا الحادث الفردي تعريف كيفية تفكير الصناعة في أمان البرمجيات.

ثم جاء Log4Shell في أواخر 2021. ثغرة تنفيذ كود عن بُعد حرجة في Apache Log4j — مكتبة تسجيل Java المنتشرة في كل مكان — كشفت عمليًا كل مؤسسة على هذا الكوكب. تسابقت المؤسسات لتحديد ما إذا كانت تستخدم Log4j أصلاً، مما كشف عن نقص جوهري في الرؤية تجاه تبعيات البرمجيات. كان الدرس واضحًا: لا يمكنك تأمين ما لا يمكنك رؤيته.

وفي الآونة الأخيرة، أظهر الباب الخلفي في XZ Utils (CVE-2024-3094) في أوائل 2024 ناقل هجوم أكثر خبثًا. سمحت حملة هندسة اجتماعية صبورة وطويلة الأمد لمساهم خبيث بإدراج باب خلفي في مكتبة ضغط حرجة مستخدمة في جميع توزيعات Linux تقريبًا. استهدف الهجوم نظام build تحديدًا، ولم يُفعَّل إلا في ظروف build معينة — هجوم على سلسلة التوريد بتعقيد استثنائي.

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

يغطي هذا الدليل الشامل كل بُعد من أبعاد أمان سلسلة توريد البرمجيات — من إدارة التبعيات إلى سلامة build، وتوقيع القطع البرمجية، والمصدر، وSBOM، وأطر الامتثال. سواء كنت مهندس DevOps أو مهندس أمان أو قائد هندسي، يوفر هذا الدليل خارطة طريق عملية وشاملة لتقوية سلسلة توريد البرمجيات الخاصة بك.

فهم نموذج سلسلة توريد البرمجيات

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

1. الكود المصدري

هذا هو المكان الذي يكتب فيه المطورون الكود ويراجعونه ويُرسلونه. تشمل مرحلة المصدر أنظمة التحكم في الإصدارات (Git)، وعمليات مراجعة الكود، وقواعد حماية الفروع، وتوقيع commits. تشمل التهديدات في هذه المرحلة حسابات المطورين المخترقة، والـ commits الخبيثة، والتغييرات غير المصرح بها على ملفات تكوين CI/CD (تسميم الـ pipeline).

2. التبعيات

تعتمد التطبيقات الحديثة بشكل كبير على المكتبات والحزم من جهات خارجية. قد يسحب تطبيق Node.js نموذجي مئات أو آلاف التبعيات المتعدية. تشمل مرحلة التبعيات سجلات الحزم (npm، PyPI، Maven Central)، وملفات القفل، وتحليل الإصدارات، وفحص الثغرات الأمنية. هذه واحدة من أكثر مراحل سلسلة التوريد استغلالًا.

3. الـ Build

تحوّل مرحلة build الكود المصدري والتبعيات إلى قطع برمجية قابلة للنشر. يشمل ذلك التجميع، والتحزيم، وبناء صور الحاويات، وتنفيذ الاختبارات. أنظمة build — سواء كانت Jenkins أو GitHub Actions أو GitLab CI أو غيرها — هي أهداف عالية القيمة لأن اختراق عملية build يمكن أن يحقن كودًا خبيثًا في كل قطعة برمجية يتم إنتاجها.

4. القطع البرمجية

مخرجات build — صور الحاويات والملفات الثنائية والحزم — تُخزَّن في سجلات القطع البرمجية (Docker Hub، Amazon ECR، Artifactory، إلخ). تشمل مرحلة القطع البرمجية التوقيع والتحقق وإرفاق البيانات الوصفية والتحكم في الوصول. بدون ضوابط سلامة مناسبة، يمكن التلاعب بالقطع البرمجية بعد build.

5. النشر

تسلّم المرحلة الأخيرة القطع البرمجية إلى بيئات الإنتاج. يشمل deploy منصات التنسيق (Kubernetes)، ومتحكمات القبول، وإنفاذ السياسات، والتحقق أثناء التشغيل. هذا هو خط الدفاع الأخير — النقطة التي تتحقق فيها من أن ما تقوم بـ deploy هو بالضبط ما تم build.

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

مخاطر التبعيات والدفاعات

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

هجمات التبعيات الشائعة

يستغل dependency confusion (يُعرف أيضًا بارتباك مساحة الأسماء) الطريقة التي تحلّ بها مديرات الحزم التبعيات. عندما تستخدم مؤسسة حزمًا داخلية بأسماء غير موجودة في السجلات العامة، يمكن للمهاجم نشر حزمة خبيثة بنفس الاسم على السجل العام. إذا كانت مديرة الحزم مُعدَّة بشكل خاطئ، فقد تسحب حزمة المهاجم بدلاً من الداخلية. أُثبت ناقل الهجوم هذا بشكل شهير من قبل الباحث الأمني Alex Birsan في 2021، مما أثر على Apple وMicrosoft وشركات كبرى أخرى.

يستهدف typosquatting المطورين الذين يرتكبون أخطاء إملائية عند تحديد أسماء الحزم. ينشر المهاجمون حزمًا خبيثة بأسماء تشبه المكتبات الشائعة — على سبيل المثال، reqeusts بدلاً من requests، أو lodash-utils تقليدًا لـ lodash. غالبًا ما تحتوي هذه الحزم على كود لسرقة البيانات أو تعدين العملات المشفرة.

تسمح حسابات المشرفين المخترقة للمهاجمين بدفع تحديثات خبيثة إلى حزم مشروعة ومستخدمة على نطاق واسع. حادثة event-stream في 2018 واختراق ua-parser-js في 2021 أمثلة بارزة. لأن الحزم مشروعة وموثوقة، ينتشر الكود الخبيث بسرعة.

للتعمق في ناقلات الهجوم هذه والدفاعات العملية، انظر دليلنا المفصل: Dependency Confusion وتسميم القطع البرمجية: الهجمات والدفاعات.

استراتيجيات الدفاع

ملفات القفل وتثبيت الإصدارات: قم دائمًا بإرسال ملفات القفل (package-lock.json، Pipfile.lock، go.sum، Cargo.lock) إلى نظام التحكم في الإصدارات. تسجّل ملفات القفل الإصدارات الدقيقة وتجزئات السلامة لكل تبعية، مما يضمن عمليات تثبيت قابلة للتكرار. ثبّت التبعيات على إصدارات دقيقة بدلاً من استخدام نطاقات الإصدارات لمنع التحديثات غير المتوقعة.

تكوين السجل الخاص: قم بتكوين مديرات الحزم لتحليل الحزم الداخلية حصريًا من سجلك الخاص. استخدم الحزم ذات النطاق (مثل @yourcompany/package-name) وقم بتكوين تعيينات السجل لمنع هجمات dependency confusion. يمكن لأدوات مثل Artifactory وNexus أن تعمل كوكيل للسجلات العامة مع توفير طبقة إضافية من الفحص والتحكم.

فحص الثغرات الأمنية: قم بدمج أدوات تحليل تركيب البرمجيات (SCA) في pipeline الـ CI/CD الخاص بك. تفحص أدوات مثل Trivy وGrype وSnyk وDependabot التبعيات مقابل قواعد بيانات الثغرات (NVD، OSV، GitHub Advisory Database) ويمكنها حظر عمليات build التي تُدخل ثغرات معروفة. لمقارنة أدوات الفحص المتاحة، انظر أدلة مقارنة أدوات أمان CI/CD.

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

سلامة الـ Build: عمليات Build قابلة للتكرار ومحكمة الإغلاق

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

عمليات Build القابلة للتكرار

الـ build القابل للتكرار هو الذي ينتج مخرجات متطابقة عند إعطائه نفس الكود المصدري والتبعيات وبيئة build وتعليمات build. تُعدّ القابلية للتكرار خاصية أمنية قوية لأنها تتيح التحقق المستقل: يمكن لأي شخص إعادة build من نفس المدخلات والتأكد من تطابق المخرجات. إذا اختلفت المخرجات، فهذا يشير إلى التلاعب.

يتطلب تحقيق عمليات build قابلة للتكرار القضاء على مصادر عدم الحتمية:

  • الطوابع الزمنية: تتسبب الطوابع الزمنية المضمنة في اختلاف مخرجات build بين التشغيلات. استخدم SOURCE_DATE_EPOCH لتطبيع الطوابع الزمنية.
  • ترتيب الملفات: يمكن أن يختلف ترتيب تعداد نظام الملفات. تأكد من ترتيب حتمي للملفات في الأرشيفات وطبقات نظام الملفات.
  • العشوائية: تضمّن بعض الأدوات قيمًا عشوائية (UUIDs، nonces) في المخرجات. استخدم بذورًا حتمية أو أزل العناصر العشوائية.
  • التبعيات العائمة: تأكد من تثبيت جميع التبعيات على إصدارات دقيقة مع التحقق من تجزئات السلامة أثناء التثبيت.

عمليات Build محكمة الإغلاق

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

صُممت أنظمة build مثل Bazel وBuck2 وPants لعمليات build محكمة الإغلاق من الأساس. لعمليات build الحاويات، توفر أدوات مثل BuildKit مع عزل الشبكة وko لتطبيقات Go إمكانيات build محكمة الإغلاق.

للحصول على شرح كامل لتطبيق عمليات build قابلة للتكرار ومحكمة الإغلاق في pipeline الـ CI/CD الخاص بك، انظر: سلامة الـ Build: عمليات Build قابلة للتكرار في CI/CD.

أمان منصة الـ Build

بعيدًا عن عملية build نفسها، تتطلب منصة build التقوية:

  • بيئات build مؤقتة: استخدم runners جديدة ومؤقتة لكل عملية build لمنع الهجمات القائمة على الاستمرارية. لا تُعد استخدام بيئات build بين المهام.
  • صلاحيات الحد الأدنى من الامتيازات: يجب أن تمتلك مهام build الحد الأدنى من الصلاحيات المطلوبة فقط. استخدم رموزًا مؤقتة ومحددة النطاق بدلاً من الأسرار طويلة الأمد.
  • حماية Pipeline-as-code: يجب حماية ملفات تكوين CI/CD (.github/workflows/، .gitlab-ci.yml، Jenkinsfile) بقواعد حماية الفروع وتتطلب مراجعة الكود للتغييرات.
  • تدقيق سجلات Build: احتفظ بسجلات build غير قابلة للتغيير تلتقط جميع المدخلات والمخرجات وتفاصيل البيئة للتحليل الجنائي.

توقيع القطع البرمجية والتحقق منها باستخدام Sigstore وCosign

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

تحدي التوقيع التقليدي

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

Sigstore: توقيع بدون مفاتيح لسلسلة توريد البرمجيات

Sigstore هو مشروع مفتوح المصدر يُبسّط توقيع القطع البرمجية جذريًا عن طريق إلغاء الحاجة إلى مفاتيح طويلة الأمد. يتكون Sigstore من عدة مكونات:

  • Cosign: أداة لتوقيع والتحقق من صور الحاويات وقطع OCI البرمجية الأخرى. يدعم Cosign كلاً من سير عمل التوقيع القائم على المفاتيح والتوقيع بدون مفاتيح.
  • Fulcio: سلطة شهادات تصدر شهادات توقيع قصيرة الأمد بناءً على رموز هوية OpenID Connect (OIDC). بدلاً من إدارة المفاتيح، تقوم بالمصادقة مع مزود الهوية الخاص بك (GitHub، Google، إلخ) وتتلقى شهادة مؤقتة.
  • Rekor: سجل شفافية مقاوم للتلاعب يسجل جميع أحداث التوقيع. يوفر Rekor سجلاً دائمًا وقابلاً للتدقيق لكل توقيع قطعة برمجية، مما يتيح التحقق حتى بعد انتهاء صلاحية الشهادة قصيرة الأمد.

التوقيع بدون مفاتيح في CI/CD

في pipeline الـ CI/CD، يعمل التوقيع بدون مفاتيح مع Sigstore كالتالي:

  1. يكتمل نظام build وينتج قطعة برمجية (مثل صورة حاوية).
  2. يطلب Cosign شهادة توقيع من Fulcio، مع المصادقة باستخدام رمز OIDC الخاص بمنصة CI/CD (مثل رمز OIDC الخاص بـ GitHub Actions).
  3. يتحقق Fulcio من الهوية ويصدر شهادة قصيرة الأمد تضمّن ادعاءات الهوية (المستودع، سير العمل، commit SHA).
  4. يوقّع Cosign القطعة البرمجية بالمفتاح المؤقت ويسجل التوقيع في Rekor.
  5. يُتخلَّص من المفتاح المؤقت — لا أسرار طويلة الأمد لإدارتها.

في وقت deploy، تتحقق من التوقيع عن طريق فحص سجل شفافية Rekor والتحقق من أن هوية التوقيع تتطابق مع سير عمل CI/CD المتوقع.

للحصول على دليل عملي حول تطبيق Sigstore وCosign في pipeline الخاص بك، انظر: توقيع صور الحاويات والتحقق منها باستخدام Sigstore وCosign.

المصدر والتصديقات: SLSA وin-toto

يخبرك التوقيع بمن أنتج القطعة البرمجية، لكنه لا يخبرك بكيفية إنتاجها. يجيب المصدر (Provenance) على الأسئلة الحرجة: ما الكود المصدري المستخدم؟ ما عملية build التي تم تشغيلها؟ ما التبعيات المضمنة؟ ما الـ builder المستخدم؟ يوفر المصدر سجلاً قابلاً للتحقق لأصل القطعة البرمجية وعملية build الخاصة بها.

مصدر SLSA

SLSA (Supply-chain Levels for Software Artifacts، تُنطق “سالسا”) هو إطار عمل طوّرته Google وOpenSSF يحدد مستويات متزايدة من أمان سلسلة التوريد. في جوهره، يحدد SLSA تنسيقًا قياسيًا للمصدر يلتقط:

  • هوية الـ Builder: أي منصة build أنتجت القطعة البرمجية.
  • مرجع المصدر: المستودع الدقيق والفرع والـ commit.
  • وصفة الـ Build: تكوين الـ build (ملف سير العمل، أمر build).
  • المواد: جميع مدخلات الـ build (التبعيات، الصور الأساسية).
  • البيانات الوصفية: الطوابع الزمنية ومعلومات القابلية للتكرار وإصدار الـ builder.

يتم إنشاء مصدر SLSA بواسطة منصة build (وليس سكربت الـ build)، وهذا أمر حاسم — يعني أن سكربت build مخترق لا يمكنه تزوير مصدره الخاص. تمتلك منصات مثل GitHub Actions وGoogle Cloud Build مولّدات مصدر SLSA أصلية.

تصديقات in-toto

in-toto هو إطار عمل لتأمين سلامة سلسلة توريد البرمجيات بأكملها. بينما يركز SLSA بشكل أساسي على مصدر الـ build، يوفر in-toto إطار تصديق أكثر عمومية يمكنه التقاط أي خطوة في سلسلة التوريد — مراجعة الكود، والاختبار، والفحص، والموافقة، وdeploy.

يتبع تصديق in-toto تنسيق DSSE (Dead Simple Signing Envelope) ويتكون من:

  • الموضوع: القطعة البرمجية (القطع البرمجية) التي يشير إليها التصديق (محددة بالتجزئة).
  • نوع المسند: نوع التصديق (مصدر SLSA، نتيجة فحص الثغرات، SBOM، إلخ).
  • المسند: بيانات التصديق الفعلية.

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

للحصول على دليل مفصل حول إنشاء والتحقق من المصدر والتصديقات، انظر: مصدر القطع البرمجية والتصديقات: SLSA وin-toto.

قوائم مكونات البرمجيات (SBOM)

SBOM (قائمة مكونات البرمجيات) هي جرد شامل لجميع المكونات والمكتبات والتبعيات في قطعة برمجية. فكّر فيها كملصق المعلومات الغذائية للبرمجيات — تخبر المستهلكين بالضبط ما بداخلها. أصبحت SBOM متطلبًا تنظيميًا في العديد من السياقات وهي ضرورية لإدارة الثغرات والاستجابة للحوادث.

لماذا تُعدّ SBOM مهمة

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

تخدم SBOM أغراضًا متعددة:

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

تنسيقات SBOM

يهيمن تنسيقان رئيسيان لـ SBOM على الصناعة:

  • SPDX (Software Package Data Exchange): معيار ISO/IEC (ISO/IEC 5962:2021) تحتفظ به مؤسسة Linux. يدعم SPDX تنسيقات تسلسل متعددة (JSON، RDF، tag-value، YAML) ويُستخدم على نطاق واسع لامتثال التراخيص.
  • CycloneDX: مشروع OWASP مصمم خصيصًا لحالات الاستخدام الأمنية. يدعم CycloneDX جرد المكونات ومراجع الثغرات وتعريفات الخدمات وعلاقات التكوين. متوفر بتنسيقات JSON وXML.

إنشاء SBOM

يجب إنشاء SBOM كجزء من pipeline الـ CI/CD، في أقرب وقت ممكن من خطوة build. تشمل الأدوات الشائعة لإنشاء SBOM:

  • Syft: أداة مفتوحة المصدر من Anchore تنشئ SBOM من صور الحاويات وأنظمة الملفات والأرشيفات. تدعم تنسيقي SPDX وCycloneDX.
  • Trivy: ماسح Aqua Security الشامل يمكنه إنشاء SBOM بالإضافة إلى فحص الثغرات، مما يوفر أداة موحدة لكلتا الوظيفتين.
  • cdxgen: مولّد CycloneDX يدعم مجموعة واسعة من اللغات ومديرات الحزم.

تصديق SBOM

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

cosign attest --predicate sbom.spdx.json --type spdxjson <image>

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

للحصول على مختبر عملي حول إنشاء SBOM وفحصها وتصديقها، انظر مختبر SBOM في سلسلة أمان CI/CD.

الأطر والمعايير

توفر العديد من الأطر والمعايير مناهج منظمة لأمان سلسلة التوريد. يساعد فهم هذه الأطر المؤسسات على تحديد أولويات الاستثمارات وإثبات الامتثال.

SLSA (Supply-chain Levels for Software Artifacts)

يحدد SLSA أربعة مستويات من نضج أمان سلسلة التوريد المتزايد:

  • SLSA المستوى 1 — وجود المصدر: تنشئ عملية build مصدرًا يصف كيفية بناء القطعة البرمجية. هذا هو الأساس — مجرد وجود المصدر يُعدّ تحسينًا كبيرًا مقارنة بعدم وجوده.
  • SLSA المستوى 2 — build مستضاف، مصدر موقّع: يعمل build على خدمة build مستضافة، والمصدر موقّع من قبل منصة build. يمنع هذا المطورين من تزوير المصدر على أجهزتهم المحلية.
  • SLSA المستوى 3 — عمليات build مُقوَّاة: توفر منصة build عزلاً قويًا بين مهام build، وبيئات مؤقتة، وإنشاء مصدر مقاوم للتلاعب. هذا هو المستوى الذي يمنع معظم هجمات سلسلة التوريد العملية.
  • SLSA المستوى 4 — محكم وقابل للتكرار: يكون build محكم الإغلاق بالكامل (بدون وصول للشبكة، بدون مدخلات غير معلنة) ومثاليًا قابل للتكرار. هذا هو المعيار الذهبي، يوفر أعلى مستوى من الضمان.

للحصول على قائمة تحقق امتثال عملية وإرشادات تطبيق لكل مستوى SLSA، انظر: شرح مستويات SLSA: قائمة تحقق امتثال عملية.

NIST SSDF (إطار تطوير البرمجيات الآمن)

يوفر SSDF (SP 800-218) مجموعة من الممارسات عالية المستوى والمحايدة تقنيًا لتطوير البرمجيات الآمن. يتم تنظيمه في أربع مجموعات:

  • إعداد المؤسسة (PO): وضع سياسات الأمان والأدوار والتدريب.
  • حماية البرمجيات (PS): حماية الكود المصدري وبيئات build والقطع البرمجية من الوصول غير المصرح به والتلاعب.
  • إنتاج برمجيات آمنة (PW): تصميم وتطبيق واختبار البرمجيات مع مراعاة الأمان.
  • الاستجابة للثغرات (RV): تحديد وتحليل ومعالجة الثغرات في البرمجيات المُصدَرة.

يُعدّ SSDF ذا صلة خاصة بالمؤسسات التي توفر البرمجيات للحكومة الفيدرالية الأمريكية، حيث يُشار إليه في الأمر التنفيذي 14028 ومذكرات OMB ذات الصلة.

OWASP SCVS (معيار التحقق من مكونات البرمجيات)

يوفر OWASP SCVS إطار عمل يركز تحديدًا على تحليل مكونات البرمجيات وإدارة مخاطر سلسلة التوريد. يحدد متطلبات التحقق عبر ست فئات: BOM، هوية البرمجيات، المصدر، سلامة الحزم، تحليل المكونات، والنسب. يُعدّ SCVS مفيدًا كقائمة تحقق مفصلة لتقييم ممارسات أمان سلسلة التوريد في مؤسستك.

OpenSSF Scorecard

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

خارطة طريق التطبيق

تأمين سلسلة توريد البرمجيات هو رحلة وليس مشروعًا واحدًا. توفر خارطة الطريق المرحلية التالية مسارًا عمليًا من النظافة الأساسية إلى المواقف الأمنية المتقدمة.

المرحلة 1: الأساس (الأسابيع 1-4)

التركيز على الرؤية والضوابط الأساسية:

  • جرد سلسلة التوريد: ارسم خريطة لجميع المستودعات وأنظمة build وسجلات القطع البرمجية وأهداف deploy. حدد جميع تبعيات الجهات الخارجية عبر مشاريعك.
  • تمكين فحص التبعيات: ادمج Trivy أو Grype أو Dependabot في جميع pipelines الـ CI/CD. قم بتكوين التنبيهات التلقائية للثغرات الحرجة وعالية الخطورة.
  • إرسال ملفات القفل: تأكد من أن جميع المشاريع تستخدم وتُرسل ملفات القفل. ثبّت التبعيات على إصدارات دقيقة.
  • فرض حماية الفروع: اطلب مراجعة الكود وفحوصات الحالة لجميع عمليات الدمج في الفروع الرئيسية. احمِ ملفات تكوين CI/CD.
  • إنشاء SBOM: أضف إنشاء SBOM إلى pipelines الـ build الخاصة بك. خزّن SBOM بجانب القطع البرمجية في سجلك.

المرحلة 2: السلامة (الأسابيع 5-12)

إضافة ضوابط السلامة التشفيرية:

  • تطبيق توقيع القطع البرمجية: انشر Cosign مع التوقيع بدون مفاتيح باستخدام هوية OIDC لمنصة CI/CD الخاصة بك. وقّع جميع صور الحاويات والقطع البرمجية الحرجة.
  • إنشاء مصدر الـ build: فعّل إنشاء مصدر SLSA في pipelines الـ build الخاصة بك. يمكن لمستخدمي GitHub Actions استخدام سير عمل slsa-github-generator القابل لإعادة الاستخدام.
  • تكوين السجلات الخاصة: قم بإعداد Artifactory أو Nexus كوكيل للسجلات العامة. قم بتكوين مديرات الحزم للتحليل من السجلات الخاصة أولاً لمنع dependency confusion.
  • تحقيق SLSA المستوى 2: مع عمليات build المستضافة والمصدر الموقّع، يمكن لمعظم الفرق الوصول إلى SLSA المستوى 2 بنهاية هذه المرحلة.

المرحلة 3: التحقق (الأسابيع 13-20)

فرض السياسات في وقت deploy:

  • نشر متحكمات القبول: استخدم متحكمات القبول في Kubernetes (Kyverno، OPA Gatekeeper، Sigstore Policy Controller) لفرض التحقق من التوقيع والمصدر قبل deploy.
  • تصديق SBOM: وقّع SBOM وأرفقها بالقطع البرمجية كتصديقات in-toto. تحقق من تصديقات SBOM كجزء من سياسات deploy.
  • تقوية بيئات Build: انتقل إلى runners مؤقتة ومعزولة للـ build. قلّل امتيازات بيئة build. حقق SLSA المستوى 3.
  • أتمتة الامتثال: استخدم أدوات policy-as-code للتحقق المستمر من الامتثال لـ SLSA وSSDF وسياسات الأمان المؤسسية.

المرحلة 4: المتقدم (مستمر)

السعي نحو الدفاع المتعمق والتحسين المستمر:

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

المختبرات العملية

النظرية مهمة، لكن الممارسة العملية ضرورية. توفر المختبرات التالية خبرة عملية مع الأدوات والتقنيات المغطاة في هذا الدليل:

الأدوات والمقارنات

اختيار الأدوات المناسبة أمر حاسم لأمان سلسلة التوريد الفعال. تساعدك أدلة المقارنة التالية في تقييم الخيارات عبر الفئات الرئيسية:

الفئة الأدوات حالة الاستخدام
ماسحات الثغرات Trivy، Grype، Snyk، Clair فحص التبعيات وصور الحاويات بحثًا عن الثغرات المعروفة
توقيع القطع البرمجية Cosign، Notation، GPG التوقيع التشفيري للقطع البرمجية لضمان السلامة والأصالة
إنشاء SBOM Syft، Trivy، cdxgen، CycloneDX CLI إنشاء جرد لمكونات البرمجيات بتنسيق SPDX أو CycloneDX
المصدر SLSA GitHub Generator، Witness، in-toto إنشاء مصدر build قابل للتحقق وتصديقات
إنفاذ السياسات Kyverno، OPA Gatekeeper، Sigstore Policy Controller إنفاذ سياسات سلسلة التوريد في وقت deploy عبر قبول Kubernetes
إدارة التبعيات Dependabot، Renovate، Socket.dev تحديثات التبعيات التلقائية والمراقبة واكتشاف الحزم الخبيثة

للحصول على مقارنات مفصلة لهذه الأدوات، بما في ذلك مصفوفات الميزات وإرشادات التوصية، انظر سلسلة أدوات ومقارنات أمان CI/CD.

الخاتمة

لم يعد أمان سلسلة توريد البرمجيات اختياريًا — إنه متطلب أساسي لأي مؤسسة تبني وتنشر البرمجيات. أظهرت الهجمات ضد SolarWinds وLog4j وXZ Utils أن الأمان التقليدي القائم على المحيط غير كافٍ عندما تكون سلسلة التوريد نفسها هي ناقل الهجوم.

الخبر السار هو أن منظومة الأدوات والمعايير نضجت بسرعة. جعل Sigstore توقيع القطع البرمجية متاحًا لكل فريق. يوفر SLSA إطار نضج واضح وتدريجي. أصبحت SBOM ممارسة قياسية. يمكن لمحركات السياسات فرض متطلبات سلسلة التوريد تلقائيًا في وقت deploy.

المبادئ الرئيسية التي يجب تذكرها:

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

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