لماذا يجب فحص صور الحاويات قبل النشر (وكيف تفعل ذلك)

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

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

ما هو فحص الثغرات الأمنية؟

فحص الثغرات الأمنية هو عملية آلية تفتح صورة الحاوية الخاصة بك، وتفحص كل حزمة ومكتبة بداخلها، وتقارنها بقاعدة بيانات للثغرات المعروفة. يتم تتبع هذه الثغرات كـ CVEs (الثغرات والتعرضات الشائعة). كل CVE لها تصنيف خطورة: منخفض، متوسط، مرتفع، أو حرج.

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

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

لماذا لا يمكنك الفحص مرة واحدة ثم النسيان

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

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

أين تضع الفحص في خط الأنابيب الخاص بك

يقع الفحص بين خطوة البناء وخطوة الترقية. التدفق النموذجي يبدو كالتالي:

المخطط الانسيابي التالي يوضح عملية اتخاذ القرار هذه:

إليك مثال عملي باستخدام Trivy في سير عمل GitHub Actions الذي يفحص الصورة ويفشل خط الأنابيب عند وجود أي ثغرة حرجة:

scan-image:
  runs-on: ubuntu-latest
  steps:
    - name: Pull image from registry
      run: docker pull my-registry/my-app:${{ github.sha }}

    - name: Run Trivy vulnerability scan
      uses: aquasecurity/trivy-action@master
      with:
        image-ref: my-registry/my-app:${{ github.sha }}
        format: table
        exit-code: 1
        severity: CRITICAL

exit-code: 1 يخبر Trivy بإرجاع كود خروج غير صفري عند العثور على ثغرات، مما يوقف خط الأنابيب. severity: CRITICAL يحدد عتبة السياسة: فقط النتائج الحرجة تسبب الفشل. اضبط الخطورة على CRITICAL,HIGH إذا كنت تريد الحظر على كليهما.

flowchart TD A[بناء الصورة] --> B[دفع إلى السجل] B --> C[تشغيل فحص الثغرات] C --> D{هل الفحص ناجح؟} D -->|نعم| E[ترقية إلى البيئة التالية] D -->|لا| F[حظر خط الأنابيب] F --> G[إصلاح الصورة] G --> A
  1. بناء الصورة
  2. دفع الصورة إلى سجل
  3. تشغيل فحص الثغرات
  4. تقييم النتائج مقابل سياستك
  5. إذا نجح الفحص، ترقية الصورة إلى البيئة التالية
  6. إذا فشل الفحص، إيقاف خط الأنابيب وإصلاح الصورة

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

وضع سياسة الفحص

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

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

الأدوات التي يمكنك استخدامها

يمكن للعديد من الأدوات فحص صور الحاويات. تعمل جميعها بطريقة مماثلة: تفحص طبقات الصورة، وتحدد الحزم، وتقارنها بقواعد بيانات CVE.

  • Trivy - مفتوح المصدر، سريع، واسع الاستخدام. يعمل بشكل جيد في خطوط أنابيب CI.
  • Snyk - تجاري مع طبقة مجانية. يتكامل مع العديد من السجلات وأنظمة CI.
  • Grype - مفتوح المصدر من Anchore. غالبًا ما يُستخدم مع Syft لتوليد SBOM.
  • Clair - مفتوح المصدر، أصلاً من CoreOS. تستخدمه العديد من خدمات السجلات.
  • الماسحات الضوئية المدمجة في السجلات - Docker Hub وAmazon ECR وGoogle Artifact Registry تقدم فحصًا تلقائيًا للصور المخزنة في سجلاتها.

اختر أداة تناسب سير عملك. معظمها يعمل كأمر واحد في خط الأنابيب الخاص بك.

ماذا تفعل عندما يفشل الفحص

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

تحديث الصورة الأساسية. هذا هو الإصلاح الأكثر شيوعًا. الصور الأساسية مثل Alpine أو Ubuntu أو distroless تُصدر إصدارات محدثة بانتظام. انتقل إلى أحدث إصدار مُصحح وأعد البناء.

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

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

بعد الإصلاح، أعد بناء الصورة وقم بتشغيل الفحص مرة أخرى. كرر حتى تجتاز الصورة.

ما ليس عليه فحص الثغرات

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

قائمة مراجعة عملية

  • أضف خطوة فحص الثغرات بعد بناء الصورة في خط أنابيب CI الخاص بك
  • حدد سياسة فحص بعتبات واضحة (مثل، الحظر على الحرجة والعالية)
  • قم بتكوين خط الأنابيب للتوقف عند انتهاكات السياسة
  • استخدم عمليات البناء متعددة المراحل لتقليل سطح الهجوم لصورك
  • جدول تحديثات منتظمة لصورك الأساسية وتبعياتك
  • راجع تقارير الفحص بشكل دوري، حتى لعمليات البناء الناجحة

الخلاصة الملموسة

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