الأمن لخط CI/CD الخاص بكم

من خلال Top 10 CI/CD Security Risks (v1.0، 2022) فهرست OWASP Foundation بشكل منهجي الثغرات الأمنية النموذجية لبيئات البناء والنشر: «Insufficient Flow Control Mechanisms» (CICD-SEC-1)، و«Inadequate Identity and Access Management» (CICD-SEC-2)، و«Dependency Chain Abuse» (CICD-SEC-3)، و«Poisoned Pipeline Execution» (CICD-SEC-4)، و«Insufficient PBAC (Pipeline-Based Access Controls)» (CICD-SEC-5)، و«Insufficient Credential Hygiene» (CICD-SEC-6)، و«Insecure System Configuration» (CICD-SEC-7)، و«Ungoverned Usage of 3rd Party Services» (CICD-SEC-8)، و«Improper Artifact Integrity Validation» (CICD-SEC-9)، و«Insufficient Logging and Visibility» (CICD-SEC-10). ويصلح هذا الكتالوج إطارًا للفحص في تقييم منظّم لمنظومة خطوط الإنتاج الخاصة بكم – بصرف النظر عمّا إذا كنتم تستخدمون GitHub Actions أو GitLab CI/CD أو Jenkins.

في Poisoned Pipeline Execution يتلاعب مهاجم لديه وصول إلى نظام الشيفرة المصدرية بعملية البناء، دون الحاجة إلى اختراق بيئة البناء نفسها. وتميّز OWASP بين ثلاثة متغيرات: في Direct PPE (D-PPE) يعدّل المهاجم ملف إعدادات CI مباشرة، وفي Indirect PPE (I-PPE) يدسّ الشيفرة في ملفات مُشار إليها مثل Makefiles أو نصوص الاختبار البرمجية، أما Public PPE (3PE) فيستغل طلبات السحب من مساهمين مجهولين في المستودعات العامة. الإجراءات المضادة الفعالة: تنفيذ الشيفرة غير المُراجَعة على مُشغّلات معزولة فقط دون وصول إلى الأسرار، وعدم تشغيل خطوط المساهمين الخارجيين إلا بعد موافقة يدوية، وتحميل إعدادات CI من فروع محمية.

يجمع «Dependency Chain Abuse» الهجمات عبر سلسلة توريد الحزم: Dependency Confusion وDependency Hijacking وTyposquatting وBrandjacking. في Dependency Confusion ينشر المهاجم في سجل عام حزمة تحمل اسم حزمة داخلية برقم إصدار أعلى – فإذا حلّ مدير الحزم التبعية مفضّلًا المصدر العام، تصل الشيفرة الخبيثة إلى عملية البناء. وقد أثبت الباحث الأمني Alex Birsan هذه التقنية في عام 2021 في أنظمة البناء لدى أكثر من 35 مؤسسة، من بينها Apple وMicrosoft وPayPal. وتشمل الإجراءات المضادة وسيط سجل داخليًا كمصدر وحيد للحصول على الحزم، وتثبيت إصدارات الحزم عبر ملفات القفل مع التحقق من المجاميع الاختبارية والتوقيعات، ونطاقات المؤسسة للحزم الخاصة، وتنفيذ نصوص التثبيت في سياقات معزولة دون وصول إلى الأسرار.

تحتاج خطوط الإنتاج إلى الوصول إلى السجلات والبيئات السحابية وأهداف النشر – وبالتالي تتراكم فيها بيانات الاعتماد. ويصف «Insufficient Credential Hygiene» (CICD-SEC-6) العواقب: أسرار طويلة الأمد وواسعة الصلاحيات قد ينتهي بها المطاف في السجلات أو المخرجات أو المستودعات المتفرعة. والرافعة الأكثر فعالية هي الانتقال إلى بيانات اعتماد اتحادية قصيرة الأمد: فعبر OpenID Connect (OIDC) تُصدر منصة CI لكل مهمة رمز هوية موقّعًا، يتحقق منه مزوّد الخدمة السحابية مقابل علاقة ثقة محددة مسبقًا ويستبدله برمز وصول قصير الأمد يسري لهذه المهمة وحدها وتنتهي صلاحيته تلقائيًا. وبذلك يُستغنى إلى حد كبير عن بيانات الاعتماد السحابية المخزنة بشكل ثابت وعن التدوير اليدوي؛ ويظل فحص الأسرار والإدارة المركزية للأسرار ضروريين كإجراءات مساندة.

ينطبق مبدأ أقل الصلاحيات (Least Privilege) على بيئة التنفيذ أيضًا: ينبغي أن تحصل المُشغّلات لكل خط على الحد الأدنى الضروري من الصلاحيات فقط، وأن تُشغَّل بشكل مؤقت في الحالة المثلى، أي يُتخلّص منها بعد كل مهمة. وتمنع قواعد حماية الفروع مع المراجعات الإلزامية وفحوصات الحالة وصول التغييرات غير المُراجَعة – بما في ذلك إعدادات CI المُتلاعب بها – إلى الفرع الرئيسي؛ وتضمن الإيداعات الموقّعة إثبات مصدر التغييرات. وتتيح المخرجات الموقّعة وشهادات المنشأ التحقق تشفيريًا قبل النشر من أن المخرَج صادر فعلًا عن خط الإنتاج المتوقع – ومع Sigstore/Cosign أيضًا بأسلوب «keyless» عبر شهادات قصيرة الأمد مرتبطة بهوية OIDC وسجل الشفافية العام Rekor. وبذلك تعالجون في الوقت نفسه «Improper Artifact Integrity Validation» (CICD-SEC-9)؛ أما في مواجهة «Insufficient Logging and Visibility» (CICD-SEC-10) فيساعد التسجيل الشامل والمُحلَّل مركزيًا لجميع أنشطة خطوط الإنتاج.

إن Supply-chain Levels for Software Artifacts (SLSA) مواصفة عابرة للقطاعات تحت مظلة OpenSSF (Linux Foundation)، تترجم إجراءات التحصين إلى مستويات قابلة للتحقق. ويحدد Build Track المستويات من L1 إلى L3: بدءًا من منشأ مُولَّد تلقائيًا يوثّق كيفية بناء المخرَج (L1)، مرورًا بمنشأ موقّع من منصة بناء مستضافة (L2)، وصولًا إلى عمليات بناء محصّنة ومعزولة عن بعضها تبقى فيها مادة التوقيع بعيدة عن متناول خطوات البناء التي يحددها المستخدم (L3). ويضيف الإصدار الحالي 1.2 (الحالة «Approved»، 11/2025) لأول مرة Source Track يتناول سلامة إدارة الشيفرة المصدرية. ويقدم NIST SP 800-204D (02/2024) إرشادات تنفيذ تكميلية؛ وتجدون تصنيفًا أعمق في مقالنا المعرفي حول SLSA-Supply-Chain-Security.