تهديدات وهجمات CI/CD: ما يستهدفه المهاجمون وكيفية الدفاع

يعتمد تسليم البرمجيات الحديث على خطوط أنابيب التكامل المستمر والتسليم المستمر (CI/CD) لبناء الكود واختباره ونشره على نطاق واسع. وقد أصبحت هذه الـ pipelines العمود الفقري لـ DevOps، إذ تمكّن المؤسسات من إطلاق الميزات بسرعة وموثوقية أكبر من أي وقت مضى. لكن هذه القوة تأتي بمقايضة حاسمة: فقد باتت أنظمة CI/CD واحدة من أكثر أسطح الهجوم جاذبية في بيئات المؤسسات.

على عكس البنية التحتية التقليدية، تقع خطوط أنابيب CI/CD عند تقاطع الكود وبيانات الاعتماد وأنظمة الإنتاج. فخط أنابيب واحد مخترَق قد يمنح المهاجم كل ما يحتاجه — الوصول إلى مستودعات الكود المصدري، وبيانات اعتماد السحابة، ومفاتيح التوقيع، والقدرة على دفع artifacts خبيثة مباشرةً إلى الإنتاج. وهذا ليس قلقًا نظريًا. فقد شهدت السنوات الخمس الماضية تصاعدًا حادًا في الهجمات التي تستهدف سلاسل توريد البرمجيات عبر بنية CI/CD التحتية، من SolarWinds إلى XZ Utils.

يقدّم هذا الدليل تصنيفًا شاملاً لتهديدات وهجمات CI/CD، ويربطها بالأطر الصناعية مثل OWASP CI/CD Top 10، ويستعرض حوادث واقعية، ويحدّد استراتيجيات دفاعية يمكنك تطبيقها اليوم. وسواء كنت مهندس أمن، أو ممارس DevOps، أو قائد فريق منصة، فإن فهم متجهات الهجوم هذه هو الخطوة الأولى نحو بناء pipelines صامدة.

لماذا يستهدف المهاجمون خطوط أنابيب CI/CD

لفهم مشهد التهديدات، عليك أن تفكّر في خطوط أنابيب CI/CD بالطريقة التي يفكّر بها المهاجم. فالـ pipelines ليست مجرد أتمتة — بل هي بيئات تنفيذ ذات امتيازات تتمتع بخصائص فريدة تجعلها أهدافًا بالغة القيمة.

وصول ذو امتيازات إلى كل شيء

تحتفظ خطوط أنابيب CI/CD بشكل روتيني ببيانات اعتماد لمزوّدي السحابة (AWS وGCP وAzure)، وسجلات الحاويات، ومستودعات الحزم، وقواعد البيانات، وعناقيد Kubernetes الإنتاجية. وغالبًا ما يمتلك مشغّل pipeline واحد (runner) وصولاً أوسع من أي مطوّر بمفرده. والمهاجمون الذين يخترقون pipeline يرثون كل هذه الامتيازات على الفور.

الأتمتة كسلاح

صُمّمت الـ pipelines لتنفيذ الكود تلقائيًا استجابةً للمحفّزات — دفع إلى فرع، أو pull request، أو وسم (tag)، أو cron مجدول. وهذه الأتمتة، التي هي جوهر CI/CD بالكامل، تتحوّل إلى سلاح عندما يستطيع المهاجم التأثير على ما يُنفَّذ. فعلى عكس المراجع البشري، سيقوم الـ pipeline بأمانة بتشغيل أي تعليمات تُعطى له، بما فيها الخبيثة.

افتراضات الثقة الضمنية

تُبنى معظم بنى CI/CD على أساس من الثقة الضمنية. فالمؤسسات تثق بأن ملفات تكوين الـ pipeline لم يُعبَث بها. وتثق بأن التبعيات التي تُحَل أثناء وقت البناء (build) شرعية. وتثق بأن GitHub Actions من أطراف ثالثة أو قوالب الـ pipeline المشتركة آمنة. وكل افتراض من افتراضات الثقة هذه يمثّل متجه هجوم محتملاً.

وضعية أمنية ضعيفة

كثيرًا ما توجد أنظمة CI/CD في نقطة عمياء أمنيًا. فهي تُدار من قبل فرق الهندسة بدلاً من فرق الأمن، وتفتقر إلى المراقبة والتسجيل اللذين تحظى بهما أنظمة الإنتاج، وتُراكم ديونًا تقنية في صورة تكوينات مفرطة في السماحية، وبيانات اعتماد قديمة، وrunners غير مُرقَّعة. وهذا يجعلها أهدافًا سهلة مقارنةً بالبنية التحتية الإنتاجية المُقوّاة.

تضخيم سلسلة التوريد

ربما يكون الجانب الأخطر في هجمات CI/CD هو قدرتها على التضخيم. فاختراق pipeline واحد يبني مكتبة أو خدمة واسعة الاستخدام قد ينشر كودًا خبيثًا إلى آلاف أو ملايين المستهلكين في المصبّ. وتأثير تضخيم سلسلة التوريد هذا هو ما يجعل حوادث مثل SolarWinds وXZ Utils مدمّرة إلى هذا الحد.

تصنيف هجمات CI/CD: الربط مع OWASP CI/CD Top 10

يوفّر OWASP CI/CD Top 10 إطارًا منظمًا لفهم أكثر المخاطر حرجًا في بيئات CI/CD. وتمثّل كل فئة خطر صنفًا من متجهات الهجوم التي يستغلها الخصوم بنشاط. وفيما يلي كيفية ربط أنواع الهجوم الرئيسية بهذا الإطار:

خطر OWASP CI/CD	فئة الهجوم	الشاغل الرئيسي
CICD-SEC-1	ضبط تدفق غير كافٍ	غياب الموافقات، لا حماية للفروع
CICD-SEC-2	إدارة هوية ووصول غير ملائمة	حسابات خدمة مفرطة السماحية
CICD-SEC-3	إساءة استغلال سلسلة التبعيات	خلط التبعيات، انتحال الأخطاء المطبعية
CICD-SEC-4	تنفيذ pipeline مسموم	تكوين pipeline خبيث في PRs/الفروع
CICD-SEC-5	PBAC غير كافٍ	غياب ضوابط الوصول المستندة إلى الـ Pipeline
CICD-SEC-6	نظافة بيانات اعتماد غير كافية	أسرار مضمّنة، tokens غير مُدوَّرة
CICD-SEC-7	تكوين نظام غير آمن	تكوينات افتراضية، خوادم CI غير مُرقَّعة
CICD-SEC-8	استخدام غير محكوم لخدمات الأطراف الثالثة	Actions مخترقة، تكاملات غير مفحوصة
CICD-SEC-9	تحقق غير سليم من سلامة الـ Artifacts	artifacts غير موقّعة، تحوير الوسوم
CICD-SEC-10	تسجيل ورؤية غير كافيين	لا سجل تدقيق، نقاط عمياء في المراقبة

للتعمّق في كل خطر من هذه المخاطر مع أمثلة واقعية، راجع دليلنا المفصّل: شرح مخاطر OWASP CI/CD العشرة الأولى مع أمثلة واقعية.

تستكشف الأقسام أدناه فئات الهجوم الأكثر تأثيرًا بالتفصيل، متناولةً آليتها وأمثلتها الواقعية واستراتيجيات كشفها لكل منها.

تنفيذ الـ Pipeline المسموم (PPE)

يُعد تنفيذ الـ Pipeline المسموم (Poisoned Pipeline Execution — PPE) أحد أخطر أصناف هجمات CI/CD وأكثرها انتشارًا. ويحدث عندما يتلاعب المهاجم بتكوين خط أنابيب CI/CD أو بتعليمات البناء لتنفيذ كود خبيث داخل بيئة الـ pipeline. ويستغل الهجوم حقيقة أن الـ pipelines تنفّذ تلقائيًا التعليمات المحدّدة في ملفات التكوين — وهذه الملفات كثيرًا ما يمكن للمساهمين تعديلها.

PPE المباشر (D-PPE)

في PPE المباشر، يمتلك المهاجم صلاحية الكتابة إلى المستودع ويعدّل مباشرةً ملف تكوين الـ pipeline (مثل .github/workflows/*.yml، أو .gitlab-ci.yml، أو Jenkinsfile، أو azure-pipelines.yml). ويحقن المهاجم خطوات خبيثة تُشغَّل بكامل امتيازات الـ pipeline. وقد يشمل ذلك تسريب الأسرار، أو حقن أبواب خلفية في artifacts البناء، أو تأسيس استمرارية في بيئة CI/CD.

يكون D-PPE فعّالاً بشكل خاص عندما:

تكون قواعد حماية الفروع ضعيفة أو غائبة
تُحفَّز تشغيلات الـ pipeline عند أحداث الدفع (push) إلى أي فرع
تُستخدم runners ذاتية الاستضافة ذات حالة مستمرة
لا تحمي ملفات CODEOWNERS تكوين الـ pipeline

PPE غير المباشر (I-PPE)

PPE غير المباشر أكثر مكرًا وأصعب في الكشف. فبدلاً من تعديل تكوين الـ pipeline مباشرةً، يعدّل المهاجم الملفات التي يستهلكها الـ pipeline أثناء التنفيذ. ويشمل ذلك:

سكربتات البناء المشار إليها في الـ pipeline (مثل Makefile، أو build.sh، أو سكربتات package.json)
بيانات التبعيات (manifests) التي تسحب حزمًا خبيثة أثناء البناء
ملفات التكوين التي تستهلكها أدوات البناء (مثل .npmrc، أو setup.py، أو build.gradle)
ملفات اختبار ثابتة أو ملفات بيانات تُعالَج بواسطة خطوات الـ pipeline

يكون I-PPE خطيرًا بشكل خاص لأن عمليات مراجعة الكود تركّز عادةً على تغييرات كود التطبيق، لا على الآثار الأمنية لسكربتات البناء أو ملفات التبعيات المعدّلة. فبإمكان المهاجم إخفاء تعليمات خبيثة في تغيير يبدو بريئًا على Makefile يُنفَّذ بكامل امتيازات الـ pipeline.

PPE عبر Pull Requests

كثير من أنظمة CI/CD مُهيّأة لتشغيل الـ pipelines على pull requests القادمة من forks — وهي ميزة ضرورية للمشاريع مفتوحة المصدر. لكن هذا يخلق متجه هجوم مباشرًا: إذ يمكن لمساهم خارجي تقديم pull request يعدّل تكوين الـ pipeline أو سكربتات البناء، فيقوم الـ pipeline بتنفيذ الكود الخبيث قبل حدوث أي مراجعة بشرية. ومع أن بعض المنصات تقيّد الوصول إلى الأسرار في PRs القادمة من forks، فإن سوء التكوين كثيرًا ما يكشف الأسرار، أو أن بيئة الـ pipeline نفسها توفّر قيمة كافية للمهاجم.

لاستكشاف تقنيات هجوم PPE عمليًا وتعلّم الإجراءات المضادة الدفاعية، اعمل على مختبرنا المخصّص: مختبر: استغلال تنفيذ الـ Pipeline المسموم (PPE) والدفاع ضده.

خلط التبعيات وتسميم الـ Artifacts

تستغل هجمات خلط التبعيات وتسميم الـ artifacts الثقة التي تضعها أنظمة البناء في سجلات الحزم وآليات حل التبعيات. وتستهدف هذه الهجمات سلسلة التوريد عند مستواها الأكثر جوهرية — المكوّنات التي تُسحَب إلى برمجياتك أثناء وقت البناء.

خلط التبعيات

يستغل خلط التبعيات (المعروف أيضًا بخلط أسماء المجالات أو هجمات الاستبدال) الطريقة التي تحل بها مديرو الحزم التبعيات عندما تُهيّأ سجلات عامة وخاصة معًا. فينشر المهاجم حزمة خبيثة إلى سجل عام (npm أو PyPI أو RubyGems) باستخدام الاسم نفسه لحزمة داخلية/خاصة تستخدمها المؤسسة المستهدَفة. وإذا لم يكن مدير الحزم مُهيّأ لإعطاء الأولوية للسجل الخاص، فقد يسحب النسخة العامة الخبيثة بدلاً منها — خصوصًا إذا نشر المهاجم رقم إصدار أعلى.

وقد برهن باحث الأمن Alex Birsan على هذا الهجوم بشكل شهير في عام 2021، حين استخدم خلط التبعيات لتنفيذ كود داخل أنظمة بناء Apple وMicrosoft وPayPal وعشرات المؤسسات الكبرى الأخرى. ولم يتطلب الهجوم أي وصول إلى المؤسسة المستهدَفة — بل مجرد معرفة أسماء الحزم الداخلية، التي يمكن اكتشافها أحيانًا عبر ملفات القفل المسرَّبة، أو خرائط مصدر JavaScript، أو رسائل الخطأ.

انتحال الأخطاء المطبعية (Typosquatting)

وثيق الصلة بخلط التبعيات، يتضمن انتحال الأخطاء المطبعية نشر حزم خبيثة بأسماء شديدة الشبه بحزم شرعية شائعة (مثل lodahs بدلاً من lodash، أو reqeusts بدلاً من requests). وعندما يرتكب مطوّر أو سكربت بناء خطأً مطبعيًا في إعلان تبعية، تُثبَّت الحزمة الخبيثة بدلاً منها.

تسميم الـ Artifacts

يتّبع تسميم الـ artifacts نهجًا مختلفًا، إذ يستهدف الـ artifacts التي تنتجها خطوط أنابيب البناء بدلاً من مدخلاتها. فالمهاجمون الذين يحصلون على وصول إلى تخزين الـ artifacts (سجلات الحاويات، ومستودعات الحزم، وتخزين الملفات الثنائية) يمكنهم استبدال artifacts شرعية بنسخ تحوي أبوابًا خلفية. وهذا فعّال بشكل خاص ضد صور الحاويات المخزّنة في سجلات ذات وسوم قابلة للتغيير — فالمهاجم الذي يحصل على صلاحية الكتابة يستطيع استبدال الصورة خلف وسم :latest أو :v1.2.3 دون تغيير الوسم نفسه.

لاستكشاف شامل لمتجهات الهجوم هذه ودفاعاتها، راجع: خلط التبعيات وتسميم الـ Artifacts: الهجمات والدفاعات.

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

خطوط أنابيب CI/CD كنوز من بيانات الاعتماد. فهي تحتاج إلى وصول إلى مستودعات الكود المصدري، ومزوّدي السحابة، وسجلات الحاويات، وقواعد البيانات، وأهداف النشر، والخدمات الخارجية. وهذه البيانات — مفاتيح API، وtokens، وكلمات المرور، والشهادات، ومفاتيح التوقيع — هي الهدف الأساسي لكثير من هجمات CI/CD.

تقنيات تسريب الأسرار الشائعة

يستخدم المهاجمون مجموعة متنوعة من التقنيات لسرقة الأسرار من بيئات CI/CD:

إفراغ متغيرات البيئة: يحقن كثير من أنظمة CI/CD الأسرار كمتغيرات بيئة. فأمر env أو printenv بسيط في خطوة pipeline مخترقة يكشف كل الأسرار المتاحة.
مسح نظام الملفات: قد تُكتب الأسرار إلى القرص كملفات (مثل ~/.docker/config.json، أو ~/.aws/credentials، أو ~/.kube/config). ويمسح المهاجمون نظام الملفات بحثًا عن ملفات بيانات الاعتماد.
فحص الذاكرة: على الـ runners ذاتية الاستضافة، يمكن للمهاجمين فحص ذاكرة العمليات أو /proc للعثور على أسرار فُكّ تشفيرها أثناء وقت التشغيل.
اعتراض الشبكة: إذا تواصلت الـ pipelines مع الخدمات عبر قنوات غير مشفّرة، يمكن للمهاجمين الذين يملكون وصولاً إلى الشبكة اعتراض بيانات الاعتماد أثناء نقلها.
تسريب السجلات: الأسرار التي تظهر عرَضًا في سجلات البناء (وهو أمر شائع بشكل محبط) يمكن استخراجها من قبل أي شخص يملك وصولاً إلى السجلات.
التسريب عبر DNS/HTTP: في البيئات المقيّدة حيث تكون الاتصالات الصادرة محدودة، يرمّز المهاجمون الأسرار المسروقة في استعلامات DNS أو ترويسات HTTP لتجاوز ضوابط الخروج.

مشكلة انتشار بيانات الاعتماد المتفاقمة

من التحديات الرئيسية في أمن CI/CD انتشار بيانات الاعتماد — أي ميل الأسرار إلى التراكم بمرور الوقت عبر تكوينات الـ pipeline، ومتغيرات البيئة، ومخازن الأسرار، وملفات التكوين. فبيانات الاعتماد طويلة العمر التي لا تُدوَّر أبدًا، وحسابات الخدمة المفرطة السماحية، والأسرار المشتركة عبر عدة pipelines، كلها تزيد من نطاق التأثير في حادثة سرقة بيانات اعتماد.

الحل هو نهج منضبط لإدارة الأسرار يجمع بين بيانات اعتماد قصيرة العمر، ووصول بأقل امتياز، وتدوير الأسرار، والحقن أثناء وقت التشغيل من خزنة مركزية (vault). وللحصول على إرشادات تنفيذ مفصّلة، راجع دليلنا حول إدارة الأسرار في خطوط أنابيب CI/CD: أنماط مع Vault.

ولممارسة كشف تسريبات الأسرار ومنعها في بيئة مضبوطة، اعمل على مختبرنا العملي: مختبر: كشف تسريبات الأسرار ومنعها في خطوط أنابيب CI/CD.

العبث بالـ Artifacts وهجمات السجلات

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

هجمات تحوير الوسوم

تسمح سجلات الحاويات بالكتابة فوق وسوم الصور افتراضيًا. فالمهاجم الذي يملك صلاحية الكتابة إلى سجل يمكنه استبدال الصورة خلف أي وسم قابل للتغيير (مثل :latest، أو :stable، أو حتى وسم إصدار يبدو محدّدًا مثل :v2.1.0) بنسخة تحوي بابًا خلفيًا. والأنظمة في المصبّ التي تسحب ذلك الوسم ستتلقى الصورة المخترقة بصمت.

ولهذا تُعد الوسوم غير القابلة للتغيير والمراجع المستندة إلى البصمة (image@sha256:abc123...) ضوابط أمنية حاسمة. وتوفّر آليات الثقة بالمحتوى مثل Docker Content Trust (DCT) وSigstore/cosign تحققًا تشفيريًا من منشأ الصورة.

اختراق السجل

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

التلاعب بعملية البناء

بدلاً من العبث بالـ artifacts بعد بنائها، يعدّل المهاجمون المتطورون عملية البناء نفسها لإنتاج artifacts مخترقة. وقد يتضمن ذلك التلاعب بملفات Dockerfile، أو حقن طبقات خبيثة في عمليات البناء متعددة المراحل، أو تعديل رايات التجميع (flags) لإدراج أبواب خلفية. وهذه الهجمات ماكرة بشكل خاص لأن الـ artifacts الناتجة تبدو منتجات شرعية لخط أنابيب CI/CD.

يتطلب الدفاع ضد العبث بالـ artifacts مزيجًا من التخزين غير القابل للتغيير، والتوقيع التشفيري، وشهادة المنشأ (مثل SLSA)، والتحقق المستمر. ولممارسة كشف العبث بالـ artifacts في بيئة عملية، راجع: مختبر: كشف العبث بالـ Artifacts — استبدال صور الحاويات في سجل.

Actions وتكاملات الأطراف الثالثة المخترقة

خطوط أنابيب CI/CD الحديثة ليست متجانسة — بل تُجمَّع من عشرات مكوّنات الأطراف الثالثة: GitHub Actions، وقوالب GitLab CI، وإضافات Jenkins، ومزوّدي Terraform، وتكاملات SaaS متنوعة. وكل مكوّن من هذه المكوّنات يمثّل حدود ثقة يمكن للمهاجمين استغلالها.

هجمات سلسلة توريد GitHub Actions

تُعد GitHub Actions هدفًا رئيسيًا لأنها تنفّذ كودًا اعتباطيًا ضمن سياق الـ workflow الذي يستدعيها. وتشمل متجهات الهجوم:

مستودعات Actions مخترقة: المهاجم الذي يحصل على وصول إلى مستودع action شائع يمكنه دفع كود خبيث يُنفَّذ في كل workflow يستخدم ذلك الـ action. وقد أظهرت حادثة tj-actions/changed-files في 2023 ذلك على نطاق واسع.
التلاعب بالوسوم: الـ actions المشار إليها بوسوم قابلة للتغيير (مثل @v3) يمكن استبدالها بصمت. إذ يحرّك المهاجم الوسم ليشير إلى commit خبيث.
انتحال الأخطاء المطبعية: actions خبيثة تُنشر بأسماء شبيهة بالشائعة لاستغلال الأخطاء المطبعية للمطوّرين.
الاستيلاء على action مهجور: عندما يهجر مشرفو action مشاريعهم، يمكن للمهاجمين أحيانًا المطالبة باسم المجال ودفع تحديثات خبيثة.

مخاطر الإضافات والامتدادات

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

الاستراتيجية الدفاعية هي تثبيت كل مكوّنات الأطراف الثالثة على مراجع غير قابلة للتغيير (commit SHAs بدلاً من الوسوم)، وتدقيق التبعيات بانتظام، واستخدام أدوات تكشف الـ actions المعروفة بخبثها. وللممارسة العملية على كشف GitHub Actions الخبيثة، اعمل على: مختبر: كشف GitHub Actions الخبيثة بالتحليل الساكن.

خط زمني لهجمات CI/CD الواقعية

يتتبع الخط الزمني التالي أبرز هجمات CI/CD وسلسلة توريد البرمجيات من 2020 إلى 2024. وتوضّح كل حادثة متجهات هجوم مختلفة وتعزّز سبب استحقاق أمن CI/CD اهتمامًا مخصّصًا.

SolarWinds / SUNBURST (ديسمبر 2020)

يظل هجوم SolarWinds الاختراق التعريفي لسلسلة توريد CI/CD. فقد تسلل المهاجمون (المنسوبون إلى جهاز الاستخبارات الروسي SVR) إلى بنية البناء التحتية لـ SolarWinds وحقنوا الباب الخلفي SUNBURST في عملية تحديث برنامج Orion. وأنتج خط البناء المخترق تحديثات مُحصَّنة بحصان طروادة وُزّعت على نحو 18,000 مؤسسة، شملت وكالات حكومية أمريكية، وشركات Fortune 500، ومشغّلي بنية تحتية حرجة.

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

أداة رفع Codecov Bash (يناير–أبريل 2021)

اخترق المهاجمون سكربت Bash Uploader الخاص بـ Codecov — وهو مكوّن تستخدمه آلاف خطوط أنابيب CI/CD لرفع تقارير تغطية الكود. وطوال ثلاثة أشهر، سرّب السكربت المعدّل متغيرات البيئة (بما فيها أسرار CI/CD وtokens والمفاتيح) من كل pipeline نفّذه. وطالت الهجمة شركات منها Twitch وHashiCorp وConfluent وكثير غيرها.

الدروس الرئيسية: يجب التحقق من سلامة سكربتات الأطراف الثالثة المنفَّذة في الـ pipelines (مثلاً عبر checksums). ولا ينبغي أن تكون الأسرار متاحة على نطاق واسع كمتغيرات بيئة. وكان بإمكان مراقبة الخروج على runners الـ CI/CD كشف التسريب.

اختطاف ua-parser-js (أكتوبر 2021)

حزمة npm المسماة ua-parser-js، التي تُنزَّل أكثر من 7 ملايين مرة أسبوعيًا، اختُطفت عندما اخترِق حساب npm الخاص بالمشرف. ونُشرت نسخ خبيثة ثبّتت مُعدّني عملات وبرمجيات لسرقة بيانات الاعتماد. ولأن هذه الحزمة تبعية لآلاف الحزم الأخرى وعمليات بناء CI/CD، كان نطاق التأثير هائلاً.

الدروس الرئيسية: حتى الحزم الموثوقة وواسعة الاستخدام قد تُخترق. وملفات القفل، وفحص السلامة، وفحص التبعيات الآلي في CI/CD أمور جوهرية. وأمن حساب npm (المصادقة الثنائية، وتحديد نطاق الـ tokens) شاغل من شواغل سلسلة التوريد.

حادثة أمن CircleCI (يناير 2023)

كشفت CircleCI، إحدى أكبر منصات CI/CD، أن مهاجمًا حصل على وصول إلى بيانات العملاء بما فيها متغيرات البيئة والمفاتيح والـ tokens المخزّنة في CircleCI. ونشأ الاختراق من برمجية خبيثة على حاسوب محمول لأحد المهندسين سرقت token جلسة SSO صالحًا، استُخدم بعدها للوصول إلى الأنظمة الداخلية. وحثّت CircleCI جميع العملاء على تدوير كل سرّ مخزّن في المنصة فورًا.

الدروس الرئيسية: مزوّدو منصات CI/CD أهداف بالغة القيمة. وينبغي للمؤسسات تطبيق الدفاع المتعمّق وعدم الاعتماد كليًا على أمن منصة CI/CD وحدها. وبيانات الاعتماد قصيرة العمر والمحدّدة النطاق تحدّ من أثر اختراقات المنصة. ووجود خطة استجابة للحوادث لتدوير الأسرار أمر حاسم.

اختراق tj-actions/changed-files (مارس 2023)

الـ GitHub Action الشائع tj-actions/changed-files (المستخدَم في أكثر من 23,000 مستودع) اختُرق عندما حصل مهاجم على وصول إلى حساب المشرف ودفع كودًا خبيثًا. وأفرغ الـ action المخترق أسرار CI/CD إلى سجلات الـ workflow، حيث أمكن حصادها. ولأن كثيرًا من الـ workflows أشار إلى الـ action باستخدام وسوم إصدار قابلة للتغيير، سُحب الكود الخبيث تلقائيًا إلى آلاف تشغيلات الـ pipeline.

الدروس الرئيسية: ثبّت GitHub Actions دائمًا على commit SHAs، لا على وسوم الإصدار. وراقب تبعيات الـ actions بحثًا عن تغييرات غير متوقعة. وطبّق صلاحيات الـ workflow وفق مبدأ أقل امتياز.

الباب الخلفي في XZ Utils (مارس 2024)

كان الباب الخلفي في XZ Utils (CVE-2024-3094) هجومًا متطورًا وممتدًا لسنوات على سلسلة التوريد. فمساهم بنى ثقة داخل مشروع XZ على مدى عامين أدخل تدريجيًا بابًا خلفيًا في نظام البناء. وأُخفي الكود الخبيث في ملفات اختبار ثابتة وفُعِّل عبر سكربتات بناء مصاغة بعناية — وهو مثال نموذجي على تنفيذ الـ Pipeline المسموم غير المباشر. واستهدف الباب الخلفي خادم SSH على أنظمة Linux، وكان سيطال فعليًا كل توزيعة Linux لولا أنه اكتُشف بالمصادفة.

الدروس الرئيسية: الهندسة الاجتماعية والتسلل طويل الأمد إلى المشاريع مفتوحة المصدر تهديدات حقيقية. وسلامة نظام البناء لا تقل أهمية عن سلامة الكود المصدري. وقد أثبت الهجوم أن تقنيات I-PPE قد تكون بالغة المكر والصبر.

الأنماط الدفاعية وإجراءات التخفيف

يتطلب الدفاع ضد هجمات CI/CD نهجًا متعدد الطبقات يعالج كل فئة هجوم. وتشكّل الأنماط التالية أساس وضعية أمنية قوية لـ CI/CD.

تكوين الـ Pipeline ككود مع ضوابط صارمة

احمِ ملفات تكوين الـ pipeline بـ CODEOWNERS وقواعد حماية الفروع
اشترط مراجعة الكود لكل تغييرات تكوين CI/CD
استخدم قوالب pipeline مُدارة مركزيًا بدلاً من التكوينات لكل مستودع حيثما أمكن
افصل تعريفات الـ pipeline عن كود التطبيق في المستودعات الحساسة

تقوية بيانات الاعتماد

استخدم بيانات اعتماد قصيرة العمر ومحدّدة النطاق (اتحاد OIDC مع مزوّدي السحابة)
طبّق حقن الأسرار في الوقت المناسب (just-in-time) من خزنة مركزية
لا تكشف الأسرار كمتغيرات بيئة أبدًا عندما يكون الحقن المستند إلى الملفات متاحًا
دوّر كل بيانات الاعتماد وفق جدول محدّد، وفورًا بعد أي حادثة
طبّق فحص الأسرار في سجلات CI/CD ومخرجات الـ artifacts

ضوابط التبعيات وسلسلة التوريد

ثبّت كل التبعيات على إصدارات دقيقة مع بصمات سلامة (hashes)
استخدم وكلاء سجل خاصة مع تحديد نطاق المجالات لمنع خلط التبعيات
ثبّت GitHub Actions وغيرها من مكوّنات الـ pipeline من الأطراف الثالثة على commit SHAs
طبّق فحصًا آليًا لثغرات التبعيات في كل pipeline
أنشئ قوائم مكوّنات البرمجيات (SBOMs) وتحقق منها

سلامة الـ Artifacts

وقّع كل artifacts البناء تشفيريًا (Sigstore/cosign للحاويات، وGPG للحزم)
استخدم وسومًا غير قابلة للتغيير ومراجع مستندة إلى البصمة لصور الحاويات
طبّق شهادة منشأ SLSA للتحقق من أصل الـ artifact
انشر ضوابط قبول (مثل Kyverno وOPA Gatekeeper) تتحقق من التواقيع قبل النشر

المراقبة والكشف

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

للتعمّق الشامل في كل نمط من هذه الأنماط الدفاعية مع أمثلة تنفيذ، راجع: الأنماط الدفاعية وإجراءات التخفيف لهجمات خطوط أنابيب CI/CD.

نمذجة التهديدات لـ CI/CD

يبدأ أمن CI/CD الفعّال بنمذجة التهديدات — أي التحديد المنهجي لحدود الثقة، وتدفقات البيانات، ومسارات الهجوم داخل بنية الـ pipeline. فبدون فهم واضح لنموذج تهديدات CI/CD لديك، تميل الجهود الدفاعية إلى أن تكون تفاعلية وناقصة.

حدود الثقة الرئيسية التي ينبغي تقييمها

لكل نظام CI/CD حدود ثقة يحاول المهاجمون عبورها:

من محطة عمل المطوّر إلى المستودع: هل يستطيع جهاز مطوّر مخترق دفع كود خبيث؟
من المستودع إلى الـ pipeline: ما التغييرات التي تحفّز تنفيذ الـ pipeline، وبأي امتيازات؟
من الـ pipeline إلى مخزن الأسرار: أي pipelines يمكنها الوصول إلى أي أسرار، وتحت أي شروط؟
من الـ pipeline إلى سجل الـ artifacts: من يمكنه دفع الـ artifacts، وهل يُتحقَّق منها قبل الاستخدام؟
من سجل الـ artifacts إلى النشر: هل يُتحقَّق من الـ artifacts المنشورة مقابل منشأ بنائها؟
من خدمات الأطراف الثالثة إلى الـ pipeline: ما الوصول الذي تملكه التكاملات الخارجية؟

تحليل مسارات الهجوم

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

حقن كود خبيث في عمليات النشر الإنتاجية
تسريب بيانات الاعتماد للحركة الجانبية
تأسيس استمرارية في بنية CI/CD التحتية
تعطيل تسليم البرمجيات (تخريب/حجب الخدمة)
اختراق المستهلكين في المصبّ عبر انتشار سلسلة التوريد

للحصول على دليل كامل لنمذجة تهديدات CI/CD مع أطر وقوالب عملية، راجع: نمذجة تهديدات CI/CD: حدود الثقة ومسارات الهجوم.

مختبرات عملية: مارس الهجوم والدفاع

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

مختبر: استغلال تنفيذ الـ Pipeline المسموم (PPE) والدفاع ضده — مارس هجمات PPE المباشرة وغير المباشرة، ثم طبّق حماية الفروع وCODEOWNERS وضوابط تكوين الـ pipeline للدفاع ضدها.
مختبر: خلط التبعيات وتسميم الـ Artifacts — نفّذ هجوم خلط تبعيات ضد تكوين بناء ضعيف، ثم طبّق تحديد نطاق المجالات، والتحقق من السلامة، وضوابط السجل الخاص.
مختبر: كشف تسريبات الأسرار ومنعها في خطوط أنابيب CI/CD — اكتشف أسرارًا مكشوفة عبر متغيرات البيئة والسجلات والـ artifacts، ثم طبّق الكشف بأدوات مثل gitleaks وtruffleHog وحرّاس pipeline مخصّصين.
مختبر: كشف العبث بالـ Artifacts — استبدال صور الحاويات في سجل — نفّذ هجوم تحوير وسم ضد سجل حاويات، ثم طبّق الثقة بالمحتوى، وتثبيت البصمة، والتحقق عبر ضابط القبول.
مختبر: كشف GitHub Actions الخبيثة بالتحليل الساكن — حلّل GitHub Actions بحثًا عن أنماط خبيثة، وطبّق تثبيت SHA، وابنِ كشفًا آليًا ضمن عملية الموافقة على الـ workflow لديك.

يتضمن كل مختبر تعليمات خطوة بخطوة، وبيئة مُهيّأة مسبقًا، وسيناريوهات هجوم ودفاع معًا. وهي مصمّمة لإكمالها بشكل مستقل، رغم أن العمل عليها بالترتيب المذكور أعلاه سيبني فهمًا شاملاً لأمن CI/CD.

الخلاصة: بناء بنية CI/CD قابلة للدفاع

أصبحت خطوط أنابيب CI/CD أكثر أسطح الهجوم أهميةً في المؤسسات البرمجية الحديثة. والحوادث المُوثَّقة في هذا الدليل — من SolarWinds إلى XZ Utils — تثبت أن المهاجمين أدركوا هذا الواقع ويستثمرون موارد ضخمة في تقنيات استغلال CI/CD.

لكن الصورة ليست قاتمة بالكامل. فقد استجاب مجتمع أمن CI/CD بأطر (OWASP CI/CD Top 10، وSLSA)، وأدوات (Sigstore، وgitleaks، وStepSecurity)، وأنماط معمارية يمكنها أن تقلّص تعرّضك بشكل كبير. والمبادئ الأساسية التي ينبغي تذكّرها هي:

عامِل الـ pipelines كبنية تحتية إنتاجية. طبّق على CI/CD الصرامة الأمنية نفسها التي تطبّقها على أنظمة الإنتاج: الوصول بأقل امتياز، والمراقبة، والترقيع، والاستجابة للحوادث.
ألغِ الثقة الضمنية. تحقق من كل شيء — التبعيات، وactions الأطراف الثالثة، والـ artifacts، وتكوينات الـ pipeline. ثبّت على مراجع غير قابلة للتغيير. ووقّع وتحقق في كل مرحلة.
قلّص نطاق التأثير. استخدم بيانات اعتماد قصيرة العمر، وصلاحيات محدّدة النطاق، وrunners معزولة، وتجزئة الشبكة للحدّ مما يمكن للمهاجم تحقيقه من أي اختراق منفرد.
استثمر في الرؤية. لا يمكنك الدفاع عمّا لا تراه. فالتسجيل الشامل، والمراقبة، والتنبيه لأنظمة CI/CD أمور غير قابلة للتفاوض.
مارس استجابتك. استخدم المختبرات المرتبطة عبر هذا الدليل لبناء ذاكرة عضلية لكل من كشف الهجوم وتنفيذ الدفاع. وعندما تقع حادثة CI/CD القادمة، ستكون جاهزًا.

أمن CI/CD ليس مشروعًا لمرة واحدة — بل هو انضباط مستمر يجب أن يتطوّر مع تقدّم تقنيات الهجوم. ابدأ بـ نموذج تهديدات، وطبّق الأنماط الدفاعية التي تعالج أعلى مخاطرك، وتحقق باستمرار من دفاعاتك عبر المختبرات العملية أعلاه. فخطوط أنابيبك أهم من أن تُترك بلا دفاع.