تأمين الحاويات وفحص الثغرات الأمنية لـ WebGoat باستخدام Trivy و Dockle

المقدمة

تخيل نشر تطبيق محتوى لتفاجأ أنه يحتوي على 37 ثغرة أمنية حرجة—بما في ذلك ثغرات تنفيذ الكود عن بُعد (RCE) وتزوير الطلبات من جانب الخادم (SSRF). هذا ليس سيناريو افتراضي؛ بل هو بالضبط ما واجهته عند العمل مع OWASP WebGoat، وهو تطبيق ضعيف عمداً مصمم للتدريب على الأمان.

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

هذا المشروع يوضح نهجاً عملياً لتأمين الحاويات من خلال أخذ تطبيق ضعيف—OWASP WebGoat—وتأمينه بشكل منهجي باستخدام أدوات معيارية في الصناعة: Trivy لفحص الثغرات الأمنية و Dockle للتحقق من أفضل الممارسات. كما نفذت CI/CD مؤتمت باستخدام GitHub Actions لفرض معايير الأمان ومنع الحاويات الضعيفة من الوصول إلى الإنتاج.

النتائج الرئيسية:

• تقليل الثغرات الأمنية الحرجة من 37 إلى 0
• تحقيق 100% توافق مع أفضل ممارسات أمان Docker
• أتمتة فحص الأمان في CI/CD
• إنشاء سير عمل DevSecOps قابل للتكرار

---

النهج والتنفيذ

🛠️ سير عمل تأمين الحاويات

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

بدأت بفحص الصورة الأصلية (webgoat/webgoat) باستخدام Trivy و Dockle.

• اكتشف Trivy ثغرات أمنية عديدة عالية وحرجة، خاصة في مكتبة xstream، وهي ضعيفة عمداً في WebGoat لإظهار عدم الأمان في إلغاء التسلسل.
• Dockle أشار إلى مشاكل مثل استخدام علامة latest ووجود ملفات ثنائية setuid/setgid.

الجدول 1: مشاكل صورة WebGoat الأصلية (قبل التأمين)

الأداة	نوع الاكتشاف	الوصف
Trivy	ثغرات أمنية حرجة	ثغرات RCE و SSRF في إلغاء تسلسل xstream، تم الإشارة إلى عدة CVEs
Dockle	انتهاك أفضل الممارسات	استخدام علامة latest، وجود ملفات ثنائية setuid/setgid

الشكل 1 - لقطة شاشة لنتيجة Trivy لـ webgoat/webgoat

الشكل 2 - لقطة شاشة لنتيجة Dockle لـ webgoat/webgoat

---

2.2 تأمين Dockerfile

للتخفيف من المخاطر وتحسين الأمان، أنشأت Dockerfile مؤمنين:

1. Dockerfile يبدأ من صورة WebGoat الرسمية، يزيل الملفات الثنائية setuid/setgid ويضيف تعليمات HEALTHCHECK.
2. Dockerfile مؤمن بالكامل من الصفر باستخدام eclipse-temurin:24-jdk-alpine، والذي:
   • ينشئ مستخدم غير root
   • يستخدم دليل عمل قابل للكتابة ومعزول
   • يعطل توليد المخطط لتجنب مشاكل الصلاحيات مع Hibernate (-Dhibernate.hbm2ddl.auto=none)
   • يربط WebGoat بـ 0.0.0.0 باستخدام Dserver.address=0.0.0.0
3. تجنب كشف الإعدادات الحساسة عبر متغيرات البيئة باستخدام سكريبت entrypoint.sh

الجدول 2: استراتيجيات التأمين المطبقة:

التقنية	الوصف
إزالة setuid/setgid	يمنع تصعيد الصلاحيات عبر الملفات الثنائية للنظام
مستخدم غير root	يعزل تشغيل WebGoat بصلاحيات دنيا
HEALTHCHECK	يتيح مراقبة صحة الحاوية
تأمين البيئة	إزالة التعرض المحفوف للمخاطر لـ ENV في ENTRYPOINT عبر سكريبت غلاف
تعطيل Hibernate auto DDL	يمنع تصدير المخطط في البيئات للقراءة فقط
الربط بـ 0.0.0.0	يضمن إمكانية الوصول إلى WebGoat من منفذ حاوية Docker

Dockerfile.patched

FROM eclipse-temurin:24-jdk-alpine

# إنشاء دليل التطبيق والمستخدم
RUN adduser -D -h /home/webgoat webgoat && \
    mkdir -p /webgoat-data && \
    chown -R webgoat:webgoat /webgoat-data

# نسخ JAR ونقطة الدخول

COPY webgoat-hardened.jar /webgoat/webgoat.jar
COPY entrypoint.sh /entrypoint.sh

# جعل نقطة الدخول قابلة للتنفيذ
RUN chmod +x /entrypoint.sh

# تعيين ENTRYPOINT بدون كشف الأعلام في Dockerfile
ENTRYPOINT ["/entrypoint.sh"]

# تعيين دليل العمل للقابل للكتابة
WORKDIR /webgoat-data

USER webgoat

# كشف منفذ التطبيق
EXPOSE 8080

# إضافة فحص الصحة لـ Docker
HEALTHCHECK --interval=30s --timeout=10s --start-period=10s --retries=3 \
  CMD wget -q --spider http://localhost:8080/WebGoat || exit 1

entrypoint.sh:

#!/bin/sh
exec java -Dserver.address=0.0.0.0 -Dhibernate.hbm2ddl.auto=none -jar /webgoat/webgoat.jar

---

CI/CD (GitHub Actions)

2.3 CI/CD مع GitHub Actions

أتمتت عملية أمان الحاويات باستخدام سير عمل CI/CD في GitHub Actions. هذا السير:

• يطلق عند الدفع
• يبني صورة Docker المؤمنة
• يشغل فحوصات Trivy و Dockle
• يخزن تقارير الفحص (trivy-report.json, dockle-report.json) في دليل reports/
• يرفع التقارير كقطع أثرية لـ GitHub Actions
• يفشل البناء إذا اكتشف Trivy أي ثغرات حرجة

الجدول 3: نظرة عامة على CI/CD:

المرحلة	الأداة/الإجراء المستخدم	الوصف
الإطلاق	GitHub Actions	يعمل عند أحداث الدفع وطلب السحب
بناء الصورة	docker build	يبني الصورة المؤمنة من Dockerfile المصحح
فحص الثغرات	Trivy	يفحص عن CVEs حرجة وعالية؛ يفشل البناء إذا وجدت
فحص أفضل الممارسات	Dockle	يتحقق من ممارسات أمان Dockerfile؛ يفشل البناء على مشاكل FATAL/WARN
رفع القطع الأثرية	actions/upload-artifact@v4	يرفع نتائج الفحص (.json و .txt) للتتبع
فرض الأمان	رموز الخروج	يضمن أن الصور المتوافقة فقط تمر عبر خط الأنابيب

الشكل 4 - GitHub Actions مع نتائج فحص Trivy و Dockle كقطع أثرية

---

النتائج

3.1 مقارنة قبل وبعد

فحص الثغرات الأمنية (Trivy)

• قبل التأمين: تم اكتشاف 37 ثغرة أمنية، العديد منها متعلق بـ xstream
• بعد التأمين: تم اكتشاف 0 ثغرة أمنية عالية/حرجة

أفضل الممارسات (Dockle)

• قبل: تحذير واحد (علامة latest)، رسالتان معلومات (setuid/setgid)
• بعد: اجتازت جميع الفحوصات الـ 16

الجدول 4: ملخص مقارنة قبل وبعد

أداة الفحص	المقياس	الصورة الأصلية	الصورة المؤمنة
Trivy	الثغرات الأمنية الحرجة	30+ (أساساً xstream)	0
Trivy	الثغرات الأمنية العالية	10+	0
Dockle	التحذيرات	1 (علامة latest)	0
Dockle	المشاكل المعلوماتية	2 (ملفات setuid/setgid)	0

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

الشكل 5 - مقارنة تقرير Trivy النظيف بين الصورة الأصلية والصورة المؤمنة

الشكل 6 - مقارنة تقرير Dockle النظيف بين الصورة الأصلية والصورة المؤمنة

---

المناقشة

وجدت أن ربط الخادم بـ 0.0.0.0 كان ضرورياً للحاوية لتكشف التطبيق بشكل صحيح. بالإضافة إلى ذلك، تعطيل توليد المخطط التلقائي لـ Hibernate (hibernate.hbm2ddl.auto) حل أخطاء الوصول للكتابة في نظام الملفات للقراءة فقط في الحاوية.

بينما يؤتمت خط الأنابيب فحص الأمان، تباطأ فحص Trivy بشكل كبير بسبب حجم .jar الكبير. تحسين حجم القطع الأثرية أو استبعاد الملفات الثابتة في الفحوصات يمكن أن يحسن الأداء.

هذا التمرين عزز أفضل الممارسات في التطوير الآمن وأظهر كيف يمكن لخطوط الأنابيب المؤتمتة فرض السياسات بشكل متسق.

---

الخلاصة

هذا المشروع يوضح أن أمان الحاويات ليس مجرد فحص للثغرات الأمنية—بل هو بناء نهج شامل للأمان أولاً لتطوير ونشر الحاويات. بدءاً من صورة ضعيفة عمداً، نجحت في بناء حاوية آمنة ومؤمنة تلبي معايير الأمان المؤسسية.

النقاط الرئيسية:

1. الأتمتة ضرورية: فحوصات الأمان اليدوية لا تتوسع. CI/CD يضمن فحص وتصحيح كل بناء للحاويات تلقائياً.

2. الدفاع في العمق: الجمع بين أدوات متعددة (Trivy + Dockle) يوفر تغطية شاملة—فحص الثغرات الأمنية بالإضافة إلى التحقق من أفضل الممارسات.

3. الأمان بالتصميم: تأمين الحاويات من البداية أكثر فعالية من محاولة تأمينها بعد النشر.

4. نتائج قابلة للقياس: التحول من 37 ثغرة أمنية حرجة إلى صفر يوضح فعالية تأمين الحاويات المنهجي.

الخطوات التالية لمنظمتك:

• دمج Trivy و Dockle في خطوط أنابيب CI/CD الموجودة
• إنشاء بوابات أمان تمنع الحاويات الضعيفة من الوصول إلى الإنتاج
• إنشاء صور أساسية مؤمنة لتطبيقاتك
• تنفيذ فحص أمان منتظم لسجل الحاويات الخاص بك

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

---

المراجع

• توثيق Trivy
• توثيق Dockle
• OWASP WebGoat
• دورة حياة Alpine Linux
• توليد مخطط Spring Boot Hibernate