شعار Xygeni باللون الأبيض
حاول مجانا
إحجز توضيحاً

ما الذي يمكن أن يحدث خطأ؟ CI/CD pipelines?

جدول المحتويات

منشورات يجب قراءتها

أحدث المشاركات ذات الاهتمام

التكامل المستمر والتسليم المستمر (CI/CD) pipelineتعتبر s أساس أي مؤسسة برمجية تقوم ببناء البرامج بطريقة "حديثة". توفر الأتمتة قوة كبيرة، لكن معظم المطورين يتجاهلون المسؤولية التي تنطوي عليها.

المطور: نعم نأخذ CI/CD أمن على محمل الجد ولديك سيطرة قوية على المشرفين على الكود ومراجعته commitالصورة قبل الدمج؛ وظائف و pipelineيتم الحفاظ عليها من قبل كبار الموظفين، وهم يهتمون بعدم تسريب الأسرار في pipelineس. وتم تثبيت الأداة من قبل موظفين يعرفون الأمر. ما الخطأ الذي يمكن أن يحدث؟

عزيزي المطور، CI/CD الأنظمة معقدة. مساحتها الهجومية الواسعة جذبت جهات خبيثة. لذا، من الأفضل توخي الحذر وعدم المبالغة في الثقة.

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

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

 

في الزمن الجميل كان الأمر سهلا جدا ...

M3M3N70: بالعودة إلى العصور القديمة، كان عملنا سهلاً للغاية... كانت الأيام الصفرية عبارة عن ثمار سهلة المنال، وكانت التطبيقات مفتوحة على مصراعيها مع سهولة استغلال الثغرات الأمنية، وكان بإمكاننا التحرك أفقيًا في لمح البصر.

مستنقع الغضب: فو#@الجحيم! هناك بعض الأفكار المجنونة هناك حتى الآن، لكن الأمور تغيرت. لقد وضع الرجال الكبار الكثير من الاهتمام في هذا الهراء AppSec.

M3M3N70أجل. لكن الحمقى الجدد هم المطورون. بالنسبة لنا، كان من الأسهل استخدام الأدوات التي يستخدمها هؤلاء. تكامل النظام، على وجه الخصوص، كنز ثمين! رموز الوصول السحابي، SCM بيانات الاعتماد، وكلمات مرور قاعدة بيانات الإنتاج، ومفاتيح SSH الخاصة، وبيانات اعتماد مستخدمي CI الآخرين... كان الانتقال من أشياء التطوير المملة إلى الأشياء الحقيقية أمرًا تافهًا إلى حد ما.

أتمتة بناء واختبار ونشر البرامج باستخدام CI/CD غالبًا ما تتطلب الأداة تمرير أسرار الأوامر تدريجيًا. وغالبًا ما تُسرّب هذه الأوامر، مما يؤدي إلى عواقب وخيمة.

Pipelineتحتاج إلى أسرار يتم تسريبها أحيانًا

M3M3N70: The code monkeys slipped their AWS keys in a pipeline on a GitHub commit, later they removed the thing but not changed git history. For our scripts it was trivial to scan the history, grab the key and wreak havoc.

ربما كانت الأوقات الخوالي هي العثور على تاريخ Git .env الملف (نسي المطور إضافته إلى .gitignore):

AWS_ACCESS_KEY_ID=AKIA...
AWS_SECRET_ACCESS_KEY=wJalrXUtn...
AWS_REGION=us-east-1
APP_FOLDER=...
S3BUCKET=...

والذي تم استخدامه في سير عمل GitHub .github/deploy.yaml التي تحتوي على شيء مثل هذا:

jobs:
  build:
    name: Automated build and deployment into AWS
    runs-on: 	ubuntu-22.04
    steps:
      # Load environment from .env file
      - id: dotenv
        uses: falti/dotenv-action@v1.0.2
        
      - name: Configure AWS Credentials
        uses:
        with:
          args: --acl public-read --follow-symlinks --delete 
          aws-access-key-id: $
          aws-secret-access-key: $
          aws-region: $
      
      # ... build steps skipped ...
      
      -  name: Upload compiled code for deployment
         working-directory: $/packaged_app
         run: aws s3 cp my-app.zip s3://$ 
         
      - name: Deploy the app
        run: aws deploy create-deployment ...

M3M3N70: واو! كانت تلك المفاتيح aws تعمل! لقد اختبرنا أولاً تغييرًا ضارًا في التطبيق، ثم أضفنا اللدغة حيث بدا أن هؤلاء الأشخاص غير مدركين. البنغو! ما هي الحملة…

استخدم الممثل السيئ ببساطة مفاتيح AWS لتحميل تطبيق معدّل يحتوي على برامج ضارة ثم قام بتشغيل أمر النشر باستخدام بيانات الاعتماد هذه. الأسرار المسربة مع المعلومات الواردة في pipeline. "يا لها من حملة!" ربما يعني أن Memento قد أحدث دمارًا في الضحية المسكينة.

ما يخبرنا به Memento هنا هو أنه بمجرد حدوث تسرب سري، مثل مفاتيح الوصول إلى AWS في المثال، يتعين عليك إلغاء السر (تدوير المفاتيح أعلاه) فورا. هناك دائما نافذة التعرض بين التسرب commit وإبطال السر؛ إعادة كتابة تاريخ Git أمر صعب (حتى أقوى الدول الاستبدادية حاولت إعادة كتابة التاريخ، ولكن دون جدوى) وربما غير فعالة (ربما استنسخ أصدقاؤنا أمام المستودع مع التسريب السري) commit). قم بتدوير المفاتيح على الفور، وقم بالصلاة أثناء قراءة سجلات الأنشطة الخاصة بالحساب المستهدف أثناء نافذة التعرض!

ربما ينبغي للمنظمات حظر استخدام الأسرار طويلة المدى في CI/CD pipelines، واستبدالها بأوراق اعتماد مؤقتة. في المثال السابق مع مفاتيح AWS في إجراءات GitHub، يكون استخدام مزود اتصال OpenID (OIDC). للحصول على بيانات الاعتماد قصيرة الأجل اللازمة للإجراءات.

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

في بعض الأحيان، كانت المنطقة المستخدمة للنشر (حاوية AWS S3 في هذا المثال) مفتوحة للقراءة من الغرباء، بسبب خلل في التكوين (لم يتم اكتشافه). ماذا مستنقع الغضب المستخدمة كانت شيء من هذا القبيل:

aws s3 ls --recursive s3://<bucket_name>/<path>/ | \
awk '{print $4}' | \
xargs -I FNAME sh -c "echo FNAME; \
  aws s3 cp s3://<bucket_name>/FNAME - | \
  grep '<regex_pattern>'"

ربما تم إنشاء المجموعة في قالب توفير يمكن فحصه تلقائيًا بحثًا عن أي عيوب أمنية.

كان التكوين الافتراضي للأداة بمثابة لعبة بالنسبة لنا

لإعطاء أمثلة ملموسة دعونا نتحدث عنها جنكينز، إحدى أدوات CI الأكثر شيوعًا.

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

(أعتذر، جينكينز، لوضعك كمثال 😉

كن ماهرًا (حتى مدمنًا) على مبادئ الأمان. واحد هو آمن بشكل افتراضي المبدأ: يجب ضبط عناصر التحكم افتراضيًا على أكثر إعدادات الأمان الممكنة. يجب أن يكون الأمان مُدمجًا في CI/CD أدوات و pipelineمن الألف إلى الياء، بدلاً من أن تكون فكرة لاحقة. لكن سهولة الاستخدام والراحة غالبًا ما تتعارض مع الأمان.

بالنسبة لحالة جنكينز، المصادقة المضمنة هشة للغاية: لا تستخدم أبدًا آليات المصادقة المضمنة في Jenkins. من الأفضل اختيار آلية تابعة لجهة خارجية (SAML، LDAP، Google...)، مع البرنامج الإضافي لاستراتيجية التفويض المستند إلى الدور ("RBAC"). وتوخي الحذر الشديد مع admin خاصاً بالعمل.

اهتم بكيفية العمل و pipeline تتم معالجة الملفات في جنكينز. الشيء نفسه مع البرنامج المساعد التكوين كرمز وملفات التكوين الخاصة به، والتي تنطبق على تكوين Jenkins.

الانتقال من الاستضافة الذاتية CI/CD يؤدي تحويل الأنظمة إلى أنظمة SaaS المستندة إلى السحابة إلى إزالة بعض المخاطر المحتملة التي تسمح بالحركة الجانبية داخل شبكة المؤسسة، ولكن تمت إضافة مخاطر أخرى، مثل الحاجة إلى فتح اتصالات خارجية بين الأنظمة الداخلية الحالية والأنظمة الخارجية. CI/CD الأداة.

ينبغي للمنظمات أن تمارسcisالعناية الواجبة في التصلب CI/CD النظام، بدءًا بالإعدادات الأكثر تقييدًا والانفتاح تدريجيًا مع الحد الأدنى من الأذونات المطلوبة لـ pipeline خطوات.

تكوين الأمان في CI/CD قد تكون الأدوات معقدة. العديد منها يحتوي على مكونات إضافية أو ملحقات تحتوي على معظم الثغرات الأمنية وتحتاج إلى تحديث.

قد تساعد أدوات فحص التكوين الأمني ​​الخاطئ لمثل هذه الأدوات أو المعايير المعقدة.

إدخال الكود في pipeline أوامر للمتعة والربح

M3M3N70: هل سبق لك استخدام Untrusted Code Checkouts، حيث تكون الإجراءات والنصوص الضعيفة عرضة لحقن الأوامر؟

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

المثال الأول ل سير عمل GitHub المؤسف:

# INSECURE. Provided as an example only.
on:
  pull_request_target #1

jobs:
  build:
    name: Build and test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
        with:
          ref: $ #2

      - uses: actions/setup-node@v1
      - run: |
          npm install #3
          npm build
      # ... more steps ...

الجمع بين pull_request_target يعد تشغيل سير العمل مع الخروج الصريح من العلاقات العامة غير الموثوق بها ممارسة خطيرة قد تؤدي إلى تسوية المستودع. في المثال، المجموعة المؤسفة من:

  • pull_request_target الحدث، والذي لديه بشكل افتراضي إذن الكتابة إلى المستودع الهدف وأسرار المستودع الهدف، حتى من التفرعات الخارجية، ويتم تشغيله في سياق المستودع الهدف للعلاقات العامة،
  • قم بالتحقق من رمز العلاقات العامة من المصدر، الريبو غير الموثوق به،
  • قم بتشغيل أي برنامج نصي قد يعمل على محتويات خاضعة للتحكم في العلاقات العامة، كما في حالة npm installو
  • عدم استخدام شرط للإثارة pull_request_target سيتم تشغيل الحدث فقط إذا تم تعيين نوع من التصنيف "تم فحص هذا العلاقات العامة" إلى العلاقات العامة (لا يمكن للمستخدمين الخارجيين تعيين تسميات إلى العلاقات العامة).

يأخذ المثال الثاني مدخلات غير موثوقة (من مشكلة أو تعليق أو pull request) كمصدر للحجج التي تم تمريرها إلى pipeline الأمر عبر التعبيرات. هذا ال pipeline إصدار الثغرة الأمنية لحقن أوامر نظام التشغيل.

- name: Check title
  run: |
    title="$"
    if [[ ! $title =~ ^.*:\ .*$ ]]; then
      echo "Bad issue title"
      exit 1
    fi

تقوم عملية التشغيل بإنشاء برنامج نصي مؤقت للصدفة يعتمد على القالب، باستخدام $ تم استبداله، مما يجعله عرضة لحقن أوامر الصدفة. يمكن للمهاجم الذي لديه حساب GitHub مزيف أن يخلق مشكلة في العنوان a"; bad_code_goes_here;#، والازدهار! 

مستنقع الغضب: أوه، هؤلاء الرجال كانوا يفتحون الباب لحقن الأوامر بمجرد فتح مشكلة...

كانت هناك ثغرات أمنية في تنفيذ التعليمات البرمجية في إجراءات GitHub، مثل تعليق gajira، تم إصلاحه الآن. يرجى القراءة "مدخلات غير موثوق بها في سير عمل GitHub" للحصول على تفاصيل كاملة.

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

 

نشر البرامج الضارة غير المقصودة هنا!

الانتشار المستمر هي ذروة الأتمتة، ولكن يمكن أن يتم إحباط هذه الذروة بسبب عدم وجود ضوابط الموافقة المناسبة على pipeline تدفق.

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

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

إنهم يغلقون الأبواب

مستنقع الغضب:هذه كلمات المرور الافتراضية المبهجة في CI/CD يتم مسح الأدوات. الوصول إلى /var/lib/jenkins/secrets/initialAdminPassword هو الآن مسار ميت. توفر العديد من الأدوات الآن المصادقة الثنائية (2FA)، التي جعلها فيروس كورونا شائعة، وحتى أكثر قرود الشفرات كسلاً يستخدمها!

M3M3N70: نحن نحارب المصادقة الثنائية، لكن الأمر ليس بهذه السهولة. من الصعب التصيد الاحتيالي لهؤلاء الأشخاص، مثل "Scatter Swine" فعلته مع Twilio. مع مفاتيح WebAuthn يكون الأمر أكثر صعوبة. على الأقل، يمكننا أن نحاول سرقة ملفات تعريف الارتباط لتجاوز MFA، ولكن يجب اقتحام صندوق المطور.

تعد المصادقة متعددة العوامل خطوة جيدة في الاتجاه الصحيح للحد من مخاطر تسرب أسرار المصادقة. تدعم معظم أدوات DevOps الحديثة MFA. ومفاتيح المصادقة ضمن WebAuthn / U2F (انظر مشروع فيدو2) ربما يكون الخيار الأفضل لـ MFA في DevOps، إذا تمت إدارته بشكل صحيح.

مستنقع الغضب: لقد استيقظ فريق DevOps. لديهم الشيء "الأقل امتيازًا" اللعين في دمائهم. ولم يعودوا قرودًا مشفرة بعد الآن. لقد تم القبض علينا الآن متلبسين من قبل المراجعين.

في الواقع، pipelineأصبحت الآن أكثر قوة بعض الشيء مما كانت عليه قبل عامين، مع إزالة الإجراءات والنصوص الضعيفة، ومع خطوات اختبار الأمان الإضافية التي اكتشفت حتى برامجنا المخفية في الخفاء commitوالحزم التي اختطفناها.

سؤال للقارئ: هل عملية بناء البرنامج من المصادر ونشره في الإنتاج عمل محفوف بالمخاطر؟ هل يمكنك رؤية DevOps الخاص بك في مرحلة اوقات سعيدة للأشرار ؟

التوصيات النهائية

من أين نبدأ؟ CI/CD pipelineس؟

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

ربما يمكن أن يكون من المفيد استخدام مجموعة من المراجعين الخبراء المسلحين بأجهزة فحص أكواد ضارة آلية.

التوصية الثانية هي تدريب المطورين الذين يكتبون pipelineق والحفاظ عليها على الأمن. أشياء للإعتبار:

  • كيفية التعامل بشكل صحيح مع المصادقة مع الخدمات الداخلية والسحابية، وتجنب إزعاج التعامل مع بيانات الاعتماد طويلة المدى.
  • كيفية الحد pipelineإلى المجموعة الدقيقة من الموارد التي يحتاج إلى الوصول إليها. مبدأ الامتياز الأقل يتألق مرة أخرى.
  • كيفية كتابة الخطوات اللازمة للقيام pipelineإنه قابل للتكرار مثل تثبيت الإصدار، وتجنب ثغرات إدخال الأوامر.
  • كيفية الموافقة على عمليات النشر من منظور الأمان (إنهم آخرون!): أي الأمان standardيجب أن تكون مطابقة وكيفية إضافة الفحوصات/البوابات المقابلة في pipelines.

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

التوصية الرابعة هي الاستفادة من CI/CD pipelineلأتمتة الأمن. تحليل الكود المصدر (SAST), تحليل تكوين المصدر (SCA)، يمكن تشغيل فحص تسريبات الأسرار، وأدوات مكافحة البرامج الضارة، وأجهزة مسح أمان الحاويات، أو أجهزة الكشف التلقائية (DAST والبرامج الضارة) بشكل روتيني على pipelineوقد تقوم مؤسستك بتنفيذ standardحول التغطية على المسح الأمني ​​في CI/CD.

تذكر أن هذه الأدوات لا تزيل مراجعة الخبراء من المعادلة، وإلا فقد يكون لديك شعور زائف بالأمان.

إذا كنت ماهرًا في أفضل العشرات من OWASP، فإن المشروع الحديث الرائع هو OWASP Top 10 CI/CD خطر أمني.

ملاحظة إخلاء المسؤولية

(1) الأمثلة في هذا المنشور تستخدم GitHub كـ SCM، AWS كمزود سحابي، وGitHub Actions أو Jenkins كـ CI/CD أداة. إنها ليست أضعف أو أكثر أمانًا من بدائلها. لا نية إعلامية سيئة! هذه الأدوات قوية ويجب استخدامها بشكل صحيح.

(2) M3M3N70 و مستنقع الغضب هي شخصيات خيالية. أي تشابه في الأشخاص أو الجماعات، أحياء أو موتاً، هو مجرد صدفة... أم هو كذلك؟

لقراءة المزيد

أدوات تحليل التركيبات البرمجية sca
إعطاء الأولوية للمخاطر التي تتعرض لها برامجك، ومعالجتها، وتأمينها
الإصدار التجريبي المجاني من 7 يومًا
لا ضرورة لبطاقة الائتمان
ابدأ الإصدار التجريبي المجاني

قم بتأمين تطوير البرامج الخاصة بك وتسليمها

مع مجموعة منتجات Xygeni

حاول مجانا
قم بجولة المنتج
شعار Xygeni باللون الأبيض

© 2026 زيجيني. كل الحقوق محفوظة

تابعني على في اكس تويتر يوتيوب

المنتجات

المصادر

الشركة

الجوانب القانونية