إدارة نتائج الفحص والثغرات مع DefectDojo

بعد شهر من بدء القصة صار عند شركة الحجوزات السعودية الصغيرة ما كانت تتمناه: فحص Nuclei كل أسبوع على الخدمات المكشوفة، وفحص OpenVAS كل شهر على كل المنافذ. لكن ظهرت مشكلة لم يتوقعها أحد: النتائج نفسها. فملف Nuclei الأسبوعي فيه 26 سطراً، وتقرير OpenVAS الشهري فيه 37 نتيجة، والفريق ينسخها إلى جدول Excel مشترك، فيتكرر السطر نفسه كل أسبوع، ويعيد أحدهم النقاش في الإنذار الخاطئ نفسه الذي حسم الشهر الماضي، ولا أحد يعرف أي ثغرة أصلحت ومتى، ولا من المسؤول عن الثغرة الحرجة التي ظهرت قبل ثلاثة أسابيع. ثم جاء المدقق وطلب الشيء الوحيد الذي لا يستطيع الجدول أن يقدمه: «أروني متى ظهرت كل ثغرة حرجة، ومتى أغلقت، وهل أغلقت ضمن المهلة التي تحددها سياستكم».

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

وسوف نناقش في هذا المقال ما يلي:

• لماذا وجد DefectDojo، وأين يقع في دورة إدارة الثغرات، ولماذا لا يفحص شيئاً بنفسه.
• التثبيت بـ Docker Compose، وكم يحتاج من ذاكرة ووقت إقلاع.
• بنية البيانات: المنتج Product والمشاركة Engagement والاختبار Test والنتيجة Finding.
• الإعداد الافتراضي الذي يعطل إزالة التكرار، ولماذا يجب أن تغيره أول يوم.
• استيراد نتائج Nuclei، وكيف تعمل إزالة التكرار Deduplication من الداخل.
• الفرز Triage: وسم الإنذار الخاطئ وحفظ القرار.
• مهلة الإصلاح SLA، وإعادة الاستيراد Reimport التي تغلق المصلح وحده، والفرق الخطير بينها وبين الاستيراد.
• استيراد تقرير OpenVAS، والخطأ الذي ظهر فيه وحله، وما فقدناه في الطريق.
• الأتمتة من خط CI/CD، والنسخ الاحتياطي، والرخصة، وقائمة التحقق.

لماذا وجد DefectDojo؟

بدأ DefectDojo عام 2013 أداة داخلية في فريق أمن شركة Rackspace، لأن الفريق واجه المشكلة نفسها التي تواجهها شركتنا: أدوات فحص كثيرة، كل منها يخرج تقريراً بصيغته، ولا مكان واحد يجمعها. ثم فتحت الشركة مصدره وصار مشروعاً تابعاً لـ OWASP، وهي المؤسسة المعروفة بقائمة أخطر عشر ثغرات في تطبيقات الويب، ثم تأسست حوله شركة تبيع نسخة تجارية وتطور النسخة المفتوحة. وترخيص النسخة المجتمعية BSD بثلاثة بنود، وآخر إصدار وقت التجربة 3.4.202 بتاريخ 22 أكتوبر 2026، والمشروع يصدر نسخاً متقاربة جداً، فقد صدر 3.4.201 قبله بيوم واحد.

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

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

وفي أدوات إدارة الثغرات وصفنا أربعة أعمال في دورة الثغرة: الجرد Inventory، والمطابقة Matching، والتنبيه Alerting، والمتابعة Tracking. وكل ما جربناه في السلسلة حتى الآن كان في الأعمال الثلاثة الأولى، وDefectDojo هو العمل الرابع، الحلقة التي تحول الفحص إلى إصلاح. وهذا ما تطلبه الضوابط الأساسية للأمن السيبراني ECC-2:2024 في الضابط 2-10-3: لا يكفي اكتشاف الثغرات وتصنيفها، بل يجب معالجتها بحسب التصنيف، والمعالجة لا تثبت إلا بسجل له تواريخ.

والشكل التالي يبين طريق النتيجة من الفاحص إلى مهمة لها صاحب وموعد، وسوف نمر على كل صندوق فيه:

التثبيت بـ Docker Compose

الطريقة الموصى بها للتجربة والفرق الصغيرة هي ملف Compose الرسمي من توثيق التثبيت، وهو يشغل ستة Containers، ولكل منها عمل: خادم التطبيق uwsgi المكتوب بإطار Django، وأمامه nginx، وعامل Celery الذي ينفذ المهام في الخلفية مثل إزالة التكرار وحساب المهل، ومجدوله celerybeat، وقاعدة PostgreSQL، وذاكرة Valkey وهي بديل Redis مفتوح المصدر. ونثبت الإصدار بالوسم نفسه في الملف وفي ال Images، لأن ملف Compose من فرع آخر قد لا يطابق ال Images:

curl -fsSL -O https://raw.githubusercontent.com/DefectDojo/django-DefectDojo/3.4.202/docker-compose.yml

# .env
COMPOSE_PROJECT_NAME=sce-dd
DD_IMAGE_REGISTRY=docker.io
DJANGO_VERSION=3.4.202
NGINX_VERSION=3.4.202
DD_PORT=18860
DD_TLS_PORT=18861
DD_SECRET_KEY=... من openssl rand -hex 32
DD_CREDENTIAL_AES_256_KEY=... من openssl rand -hex 16

في الإعداد أعلاه لاحظ التالي:

• DD_IMAGE_REGISTRY: الملف الرسمي يسحب ال Images من سجل الشركة الخاص، وغيرناه إلى Docker Hub حيث تنشر ال Images نفسها بالوسوم نفسها.
• DD_SECRET_KEY وDD_CREDENTIAL_AES_256_KEY: الملف الرسمي يضع لهما قيمة افتراضية مكتوبة فيه، وهي معروفة لكل من قرأ الملف. والمفتاح الأول يوقع جلسات الدخول، والثاني يشفر الاعتمادات التي تحفظها في DefectDojo، مثل توكن Jira، فإذا تركت القيمة الافتراضية استطاع أي أحد أن يزور جلسة أو يفك اعتماداً. ولدهما بنفسك دائماً.

docker compose pull
docker compose up -d
# كلمة مرور admin تطبع مرة واحدة في سجل الإقلاع:
docker compose logs initializer | grep "Admin password"

واستغرق سحب ال Images نحو ست دقائق ونصف، وحجمها 1.16 GB لصورة Django و459 MB لصورة nginx. ثم استغرق أول إقلاع 405 ثوان، أي قرابة سبع دقائق، قبل أن تفتح صفحة الدخول برد 200. والسبب أن Container اسمه initializer ينفذ ترحيلات قاعدة البيانات Migrations، أي ينشئ مئات الجداول، ثم ينشئ المستخدم الأول ويطبع كلمة مروره العشوائية مرة واحدة في السجل. فلا تظن أن التثبيت فشل لأن الصفحة لا تفتح في أول دقيقة، وتابع سجل initializer حتى يخرج. وانسخ كلمة المرور فوراً إلى مدير كلمات المرور وغيرها بعد أول دخول، لأن السجل نفسه ليس مكاناً آمناً لها.

والموارد معقولة جداً مقارنة بأدوات الفحص: قاس الأمر docker stats نحو 0.8 GiB من الذاكرة لكل المكونات مجتمعة، أكبرها خادم uwsgi بنحو 335 MiB، وعاملا Celery بنحو 180 MiB لكل منهما، وقاعدة PostgreSQL بنحو 88 MiB. وهذا أخف بكثير من OpenVAS الذي احتاج قرابة 43 GB من القرص، والسبب أن DefectDojo لا يحمل قاعدة ثغرات عالمية، بل يخزن نتائجك أنت فقط، فيكفيه سيرفر صغير.

بنية البيانات: من المنتج إلى النتيجة

أول قرار يواجهه الفريق ليس تقنياً بل تنظيمياً: كيف نرتب النتائج؟ وDefectDojo يفرض أربع طبقات، وفهمها يحدد هل ستعمل المتابعة عبر الزمن أم لا:

• المنتج Product: الشيء الذي تحميه ويملكه فريق، مثل «خدمات الويب المكشوفة» أو تطبيق الحجوزات. وله نوع Product Type للتجميع، وفي المختبر سميناه «Lab services». والمهلة SLA تربط بالمنتج، فالمنتجات المكشوفة على الإنترنت تأخذ مهلة أقصر.
• المشاركة Engagement: نشاط أمني على المنتج له بداية ونهاية، مثل «الفحص الأسبوعي» أو «اختبار اختراق الربع الأول». وفي المختبر أنشأنا مشاركتين: «Weekly network scans» لـ Nuclei و«Monthly OpenVAS scan».
• الاختبار Test: نتائج أداة واحدة، وكل استيراد ينشئ اختباراً، وكل إعادة استيراد تضيف إلى الاختبار نفسه، وهذا الفرق سوف يكون أهم درس في المقال.
• النتيجة Finding: ثغرة واحدة لها خطورة Severity وحالة Status ومكان Endpoint وتاريخ ظهور وتاريخ إغلاق.

ولنطبق ذلك على شركة الحجوزات: قرر الفريق ثلاثة منتجات. الأول «الخدمات المكشوفة»، وفيه موقع العملاء وواجهة API ولوحة الإدارة، بمهلة إصلاح قصيرة لأن الإنترنت كله يراها. والثاني «تطبيق الحجوزات»، وفيه نتائج فحص الكود والمكتبات، ويملكه فريق التطوير. والثالث «البنية الداخلية»، وفيه السيرفرات التي لا تظهر للإنترنت، بمهلة أطول. وتحت المنتج الأول مشاركتان دائمتان: «الفحص الأسبوعي» لـ Nuclei و«الفحص الشهري» لـ OpenVAS، وكل منهما فيها اختبار واحد يعاد استيراده كل مرة، ومشاركة مؤقتة لكل اختبار اختراق خارجي سنوي تنشأ وتغلق معه. وبهذا يعرف كل فريق منتجه، ويعرف المدير أين المشكلة بنظرة، ويقرأ المدقق تاريخ كل خدمة دون أن يبحث في عشرات الملفات.

والخطأ الشائع أن ينشئ الفريق منتجاً لكل سيرفر، فتتشتت الصورة في عشرات المنتجات، أو منتجاً واحداً للشركة كلها، فتختلط مهل الخدمات المكشوفة بالداخلية. والقاعدة الأنسب أن يكون المنتج هو ما له فريق مسؤول ومستوى خطورة واحد. ننشئ الطبقات عبر واجهة البرمجة API، ويمكن فعلها من الواجهة أيضاً، لكن الأوامر قابلة للتكرار والجدولة:

A=http://127.0.0.1:18860/api/v2
T="Authorization: Token <التوكن>"
# منتج بنوعه، ثم مشاركة مفتوحة
curl -s -X POST $A/products/ -H "$T" -H 'Content-Type: application/json' \
  -d '{"name":"lab-web","description":"خدمات الويب في المختبر","prod_type":2}'
curl -s -X POST $A/engagements/ -H "$T" -H 'Content-Type: application/json' \
  -d '{"name":"الفحص الأسبوعي","product":1,"target_start":"2026-10-25","target_end":"2026-12-31","engagement_type":"CI/CD","status":"In Progress"}'

والتوكن تأخذه مرة واحدة من واجهة المصادقة api-token-auth بمستخدم وكلمة مرور، ثم تضعه في ترويسة كل طلب. والأنسب في الإنتاج أن تنشئ مستخدماً خاصاً للأتمتة بصلاحية الاستيراد فقط، ولا تستخدم توكن المدير في خط CI/CD، ولا تكتبه في أي ملف تشاركه.

الإعداد الافتراضي الذي كاد أن يفسد كل شيء

قبل الاستيراد، الدرس الذي تعلمناه بالطريقة الصعبة. استوردنا ملف Nuclei مرتين في اختبارين مختلفين لنرى إزالة التكرار، فكانت النتيجة 19 نتيجة جديدة و0 مكررة، أي أن DefectDojo عامل الفحص الثاني كأنه مشكلات جديدة كلها. فسألنا إعدادات النظام عبر API:

{'enable_deduplication': False, 'delete_duplicates': False, 'false_positive_history': False, 'enable_finding_sla': True, ...}

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

curl -s -X PATCH $A/system_settings/1/ -H "$T" -H 'Content-Type: application/json' \
  -d '{"enable_deduplication":true,"false_positive_history":true}'

وبعد التفعيل أعدنا التجربة نفسها، فوسم DefectDojo ثلاث عشرة نتيجة من التسع عشرة بأنها مكررة Duplicate، وسوف نشرح بعد قليل لماذا لم تكن الستة الباقية مكررة، فهي أهم من الثلاث عشرة.

استيراد نتائج Nuclei

في مختبر Nuclei حفظنا نتائج الفحص في ملف JSONL، وفيه ستة وعشرون سطراً للخدمات القديمة. نستورده بأمر واحد، ونختار صيغة «Nuclei Scan» من قائمة الصيغ المدعومة:

curl -s -X POST $A/import-scan/ -H "$T" \
  -F scan_type="Nuclei Scan" -F engagement=1 \
  -F test_title="nuclei weekly" -F scan_date=2026-10-25 \
  -F minimum_severity=Info -F active=true -F verified=false \
  -F [email protected]

في الأمر أعلاه لاحظ التالي:

• minimum_severity=Info: نستورد حتى نتائج المعلومات، لأنها جرد لما يعمل على الخدمات، ويمكن رفع الحد إلى Low إذا أردت لوحة أنظف.
• verified=false: النتيجة القادمة من أداة آلية لم يتحقق منها إنسان بعد، وهذا الوسم يجعل الفرق واضحاً في اللوحة بين ما فحصه الفريق وما قالته الأداة فقط.
• scan_date: تاريخ الفحص لا تاريخ الاستيراد، وعليه تحسب المهلة، وظهر لنا أن DefectDojo يرفض التاريخ إذا كان في المستقبل بتوقيت الخادم UTC برسالة The scan_date cannot be in the future!، فانتبه عندما تستورد بعد منتصف الليل بتوقيت السعودية وقبل منتصف الليل UTC.

والمفاجأة في الرد أن النتائج صارت تسع عشرة لا ستاً وعشرين:

info: 8, low: 1, high: 7, critical: 3, total: 19

والصورة التالية من صفحة الاختبار بعد الاستيراد:

كيف تعمل إزالة التكرار من الداخل؟

السبب في النقص من 26 إلى 19 أن الملف نفسه فيه أسطر متكررة: قالب redis-default-logins وحده أعطى خمسة أسطر، سطراً لكل كلمة مرور جربها، كما شرحنا في مقال Nuclei. فجمعها DefectDojo في نتيجة واحدة عدد مشاهداتها nb_occurences=5، وكذلك جمع أسطر الكشف المكررة على Apache وGrafana وJuice Shop.

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

ولاحظ الفرق المهم بين الصيغتين: بصمة Nuclei لا تحوي المكان Endpoint، أي أن القالب نفسه على سيرفرين مختلفين يعطي البصمة نفسها، فيعامل نتيجة واحدة لها مكانان. وهذا مناسب عندما يكون الإصلاح واحداً لكل السيرفرات، مثل ترقية Apache في كل مكان، لكنه يخفي أن الإصلاح يجب أن يصل إلى كل مكان. أما بصمة OpenVAS v2 فتحوي المكان، فكل سيرفر نتيجة مستقلة. وفهم هذه الحقول يشرح لك لماذا ترى أحياناً نتيجة واحدة تتوقع أن تكون اثنتين، أو العكس، وتوثيق إزالة التكرار يشرح كيف تغير الحقول لأداة معينة إذا لم تناسبك.

الفرز Triage: الإنذار الخاطئ وقراره المحفوظ

رأينا في مقال Nuclei أن أربع نتائج Redis إنذارات خاطئة، لأن القالب يقارن رقم الإصدار فقط، وملاحظات إصدار Redis 7.4.6 تقول إن هذا الإصدار نفسه يحمل الإصلاح. وفي الجدول القديم كان هذا القرار يضيع: يكتبه أحدهم في خلية تعليق، ثم يأتي فحص الأسبوع التالي بالأسطر نفسها فيلونها آخر بالأحمر. في DefectDojo نضع حالة كل نتيجة منها «إنذار خاطئ»، ونضيف ملاحظة فيها السبب والرابط وشرط إعادة النظر:

for id in 13 15 16 18; do
  curl -s -X PATCH $A/findings/$id/ -H "$T" -H 'Content-Type: application/json' \
    -d '{"false_p":true,"active":false}'
  curl -s -X POST $A/findings/$id/notes/ -H "$T" -H 'Content-Type: application/json' \
    -d '{"entry":"إنذار خاطئ: القالب يقارن redis_version أقل من 8.2.2 فقط، وRedis 7.4.6 يحمل الإصلاح بحسب ملاحظات الإصدار. يعاد النظر إذا خفض الإصدار."}'
done

والصورة التالية لإحدى هذه النتائج بعد الوسم:

ولاحظ في الصورة حالة النتيجة: «Inactive, Mitigated, False Positive» معاً. فوسم الإنذار الخاطئ في هذا الإصدار يضع النتيجة أيضاً في حالة «معالجة» ويختمها بتاريخ ومستخدم، وهذا ظهر لنا في إحصاءات الاختبار حيث صار عدد المعالجة 4 مع أننا لم نصلح شيئاً. وهذا مهم إذا كنت تحسب مقاييس الإصلاح: لا تحسب كل «Mitigated» إصلاحاً حقيقياً، بل افصل الإنذارات الخاطئة عنها، وإلا بدا فريقك أسرع مما هو.

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

مهلة الإصلاح SLA لكل خطورة

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

curl -s -X POST $A/sla_configurations/ -H "$T" -H 'Content-Type: application/json' \
  -d '{"name":"الخدمات المكشوفة","critical":3,"high":14,"medium":45,"low":90}'

وهذه الأرقام ليست من لائحة رسمية، فالضابط في ECC يطلب المعالجة بحسب التصنيف ولا يحدد أياماً، وإنما هي قرار الشركة في سياستها لإدارة الثغرات، ويجب أن تكتبها في السياسة وتعتمدها الإدارة، ثم تضعها في الأداة لتصبح قابلة للقياس. وبعد ربطها بالمنتج ظهر لكل نتيجة تاريخ انتهاء مهلتها: فالنتيجة الحرجة على Apache صار موعدها 28 أكتوبر، أي بعد ثلاثة أيام من الفحص، والعالية 8 نوفمبر بعد أربعة عشر يوماً، والمنخفضة 23 يناير. والصورة التالية لنتيجة «Grafana Default Login» وبجانبها رقم 14 في عمود SLA:

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

إعادة الاستيراد Reimport بعد الإصلاح

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

التجربة الأولى: إعادة استيراد الملف نفسه

curl -s -X POST $A/reimport-scan/ -H "$T" \
  -F scan_type="Nuclei Scan" -F test=1 -F scan_date=2026-10-25 \
  -F close_old_findings=true -F [email protected]

delta: created 0, closed 0, reactivated 0, untouched 15

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

التجربة الثانية: إعادة الاستيراد بعد الإصلاح

ثم أعدنا الاستيراد بملف الفحص بعد الإصلاح، وهو الفحص الذي وجهنا فيه الأسماء إلى النسخ المصلحة في مقال Nuclei، فظهر عمل DefectDojo الحقيقي:

delta: created 1, closed 6, reactivated 0, untouched 9

في المخرج أعلاه لاحظ التالي:

• أغلق ست نتائج: ثغرتا Apache، وثغرة Grafana للقراءة، ومشكلة Redis بلا مصادقة وأسطرها، كلها اختفت من الفحص الجديد فأغلقها DefectDojo وختمها بتاريخ المعالجة، دون أن نلمسها يدوياً. وهذا بالضبط السجل الذي طلبه المدقق: ظهرت يوم كذا، وأغلقت يوم كذا، ضمن المهلة.
• أبقى تسع نتائج: منها الباسورد الافتراضي في Grafana الذي بقي لأن أحداً لم يغيره رغم ترقية الإصدار، والمسار /metrics المكشوف، وكلاهما ما زال يعد أيام مهلته.
• أنشأ نتيجة واحدة: سطر كشف جديد لخدمة Redis في الفحص الجديد.
• لم يعد فتح الإنذارات الخاطئة: النتائج الأربع التي وسمناها بقيت مغلقة، فقرار الفرز لم يضع.

التجربة الثالثة: الفخ في الاستيراد إلى اختبار جديد

وماذا لو أخطأ أحد الفريق واستعمل import بدل reimport للفحص الأسبوعي؟ استوردنا الملف القديم نفسه، ملف ما قبل الإصلاح، في اختبار جديد بعد تفعيل إزالة التكرار، فكانت النتيجة 19 نتيجة، 13 منها مكررة، و6 أصلية. والسؤال المهم: لماذا لم تكن الستة مكررة؟ لأنها بالضبط الست التي أغلقت في التجربة الثانية. فإزالة التكرار تقارن النتيجة الجديدة بالنتائج المفتوحة، والنتيجة المغلقة لا تعد أصلاً، فعادت الثغرات المصلحة كأنها ظهرت من جديد، بخطورتها الحرجة، ومهلتها الجديدة. وفي شركة حقيقية معنى هذا أن ملفاً قديماً يستورد بالخطأ يفتح ثغرات أغلقت، ويطلق إنذارات، ويفسد مقاييس الإصلاح. لذلك اجعل الأتمتة تستخدم reimport دائماً على الاختبار نفسه، ولا تستورد يدوياً إلا لأداة جديدة أو لاختبار اختراق منفصل.

استيراد تقرير OpenVAS إلى المنتج نفسه

قوة المكان الموحد تظهر حين تضيف أداة ثانية بصيغة مختلفة تماماً. فتقرير OpenVAS صيغته XML، ويفهمه DefectDojo بصيغة «OpenVAS Parser»، ونستورده في مشاركة ثانية داخل المنتج نفسه. وصدرنا التقرير من OpenVAS عبر GMP بكل مستويات الخطورة والجودة، حتى لا يضيع شيء مما يخفيه الفلتر الافتراضي:

curl -s -X POST $A/import-scan/ -H "$T" \
  -F scan_type="OpenVAS Parser" -F engagement=2 \
  -F test_title="openvas full and fast" -F scan_date=2026-10-25 \
  -F minimum_severity=Info -F [email protected]

خطأ Internal server error، ولماذا ظهر؟

فشل الاستيراد الأول برد Internal server error, check logs for details، وهي رسالة لا تقول شيئاً. فقرأنا سجل خادم uwsgi:

File "/app/dojo/tools/openvas/parser_v1/xml_parser.py", line 21, in get_findings
TypeError: 'NoneType' object is not iterable

وقرأنا كود المحلل في السطر نفسه، فوجدنا أنه يتوقع أن يكون العنصر الجذر في الملف <report>، وبداخله <report> آخر فيه النتائج. أما الملف الذي أخرجه أمر get_reports في GMP فجذره <get_reports_response>، أي رد البروتوكول نفسه، والتقرير داخله. فلم يجد المحلل النتائج حيث يتوقعها. والحل أن نستخرج عنصر التقرير ونجعله الجذر:

import xml.etree.ElementTree as ET
r = ET.parse('openvas-report.xml').getroot()          # get_reports_response
ET.ElementTree(r.find('report')).write('openvas-report-root.xml',
                                        encoding='utf-8', xml_declaration=True)

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

ماذا أعطى الاستيراد، وماذا فقدنا؟

بعد الإصلاح استورد DefectDojo النتائج السبعة والثلاثين كاملة، بالتوزيع نفسه الذي في OpenVAS:

info 22, low 5, medium 6, high 2, critical 2, total 37

لكن انظر إلى عمودي العنوان ورقم الثغرة في الصورة، ففيهما ملاحظتان يجب أن تعرفهما:

• العنوان يحمل المكان: المحلل يلحق عنوان السيرفر والمنفذ بعنوان النتيجة، مثل OpenBSD OpenSSH < 9.3p2 RCE Vulnerability_192.168.96.15_22/tcp. فالثغرة نفسها على عشرة سيرفرات تصبح عشر نتائج بعناوين مختلفة، وهذا مناسب للمتابعة لكل سيرفر، لكنه يجعل البحث عن ثغرة بعينها في كل الشبكة أصعب.
• رقم الثغرة CVE فارغ: عمود Vulnerability Id جاء فارغاً لكل النتائج من هذا التصدير، فخسرنا ربط النتيجة بسجل CVE داخل DefectDojo، وهو الربط الذي يحتاجه من يبحث «هل نحن متأثرون بالثغرة كذا؟». ولذلك وضعنا رقم CVE ورابط مصدره في ملاحظة الفرز يدوياً كما سيأتي.

فرز نتائج OpenSSH الحرجة

رأينا في مقال OpenVAS أن نتائج OpenSSH العالية والحرجة كلها جودة كشفها 30%، استنتجت من رقم النسخة 9.2p1، بينما السيرفر يشغل نسخة Debian المصلحة 1:9.2p1-2+deb12u10. فوسمنا الأربع التي أكدنا إصلاحها من متتبع Debian إنذارات خاطئة، وفي كل ملاحظة رقم CVE والنسخة التي أصلحتها Debian ورابط المتتبع، مثل:

False positive (QoD 30, version from banner). CVE-2024-6387 regreSSHion fixed in Debian
bookworm 1:9.2p1-2+deb12u3 (DSA-5724-1); target runs deb12u10.
https://security-tracker.debian.org/tracker/CVE-2024-6387

ولاحظ في الصورة التالية أن عمود Vuln ID from tool يحمل معرف اختبار OpenVAS نفسه OID، وهو أحد حقول بصمة التكرار في صيغة OpenVAS v2، أي أن النتيجة تعرف بالاختبار الذي أخرجها لا برقم CVE. فصارت النتائج النشطة من OpenVAS 33، منها نتيجة عالية واحدة وخمس متوسطة وخمس منخفضة واثنتان وعشرون معلومة، والحرجتان خرجتا من قائمة العمل مع سبب موثق. والنتيجة العالية الباقية «D(HE)ater» ونتائج OpenSSH المتوسطة الأخرى بقيت نشطة وغير متحقق منها، لأننا لم نؤكد إصلاحها بعد، وهذا هو الوضع الصحيح: لا تسم نتيجة إنذاراً خاطئاً لأنها تشبه أخواتها، بل لأنك تحققت منها.

الصورة الموحدة: أداتان في منتج واحد

والآن نصل إلى ما ثبتنا الأداة من أجله. فصفحة المنتج تجمع نتائج Nuclei وOpenVAS في مكان واحد، بمهلة واحدة، ويرى فيها الفريق والمدير والمدقق الحالة نفسها:

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

حالات النتيجة: ماذا تعني كل كلمة؟

كل رد استيراد في المختبر حمل إحصاءات بهذه الحقول، وهي نفسها الحالات التي تمر بها أي نتيجة:

{'active': 15, 'verified': 0, 'duplicate': 0, 'false_p': 4, 'out_of_scope': 0, 'is_mitigated': 4, 'risk_accepted': 0, 'total': 19}

وفهم الفرق بينها هو ما يجعل اللوحة صادقة، لأن كل حالة تجيب عن سؤال مختلف:

• نشطة Active: مشكلة قائمة الآن تحتاج عملاً، وهي ما تحسب عليه المهلة.
• متحقق منها Verified: إنسان من الفريق أكد أن النتيجة صحيحة، لا الأداة وحدها. وفي المختبر كانت كل النتائج غير متحقق منها لأننا استوردناها بـ verified=false، والممارسة الأنسب أن تتحقق من الحرجة والعالية قبل أن تكلف أحداً بإصلاحها.
• إنذار خاطئ False Positive: الأداة أخطأت، والدليل في الملاحظة، كما في نتائج Redis وOpenSSH.
• مكررة Duplicate: نسخة من نتيجة أصلية مفتوحة، تتبع الأصلية ولا تحسب مرتين.
• معالجة Mitigated: أغلقت، إما بإصلاح اختفى أثره في إعادة الاستيراد، أو بوسمها إنذاراً خاطئاً كما رأينا، ولذلك يجب أن تفصل بين الحالتين.
• خطر مقبول Risk Accepted: المشكلة حقيقية، لكن الإدارة قررت قبولها مؤقتاً لسبب، مثل نظام قديم سوف يستبدل خلال ثلاثة أشهر. وهذا قرار إداري لا تقني، ويجب أن يكون له صاحب وتاريخ انتهاء، وإلا صار طريقة لإخفاء المشكلات.
• خارج النطاق Out of Scope: النتيجة على شيء لا تملكه أو لا يشمله الفحص، مثل خدمة شريك ظهرت في الفحص بالخطأ.

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

من يملك الإصلاح؟

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

ماذا تعرض على الإدارة كل شهر؟

بعد شهر من الاستخدام لا يريد المدير قائمة نتائج، بل أربعة أرقام تقول هل الوضع يتحسن، وكلها تخرج من DefectDojo مباشرة:

• النتائج النشطة بحسب الخطورة: في المختبر كانت صفحة المنتج تعرض 49 نتيجة نشطة، منها حرجة واحدة وست عالية، والسؤال الشهري: هل هذا الرقم ينزل؟
• النتائج المتجاوزة لمهلتها: عدد ما تجاوز تاريخ SLA، وهو أهم رقم لأنه يقيس الالتزام لا الكمية.
• متوسط زمن الإصلاح: من تاريخ الظهور إلى تاريخ المعالجة لكل خطورة، بعد استبعاد الإنذارات الخاطئة كما شرحنا، وإلا بدا الإصلاح فورياً.
• نسبة الإنذارات الخاطئة لكل أداة: في مختبرنا كانت أربع من ست نتائج حرجة وعالية في Redis إنذارات خاطئة، وفي OpenVAS ثلاث من أربع نتائج حرجة وعالية، وهذا رقم يقول للفريق أين يحتاج فحصاً موثقاً أو قالباً أدق.

وهذه الأرقام الأربعة هي في الحقيقة إجابة البنود الثلاثة في الضابط 2-10-3: التقييم الدوري ظاهر في تواريخ الاختبارات، والتصنيف في توزيع الخطورة، والمعالجة بحسب التصنيف في المهل وأزمنة الإصلاح.

الأتمتة من خط CI/CD

كل ما فعلناه بالأوامر يمكن أن يصبح خطوة في خط عمل آلي، وهذا هو الشكل الذي تريده شركة الحجوزات: بعد فحص Nuclei الأسبوعي، يرسل الخط ملف JSONL إلى DefectDojo بإعادة الاستيراد على الاختبار نفسه، دون أن يتذكر أحد:

curl -s -X POST "$DD_URL/api/v2/reimport-scan/" -H "Authorization: Token $DD_TOKEN" \
  -F scan_type="Nuclei Scan" -F test="$DD_TEST_ID" -F scan_date="$(date -u +%F)" \
  -F close_old_findings=true -F [email protected]

وثلاثة أشياء تجعل هذه الخطوة آمنة: التوكن في متغير سري في نظام CI لا في الملف، ومستخدم مخصص بصلاحية الاستيراد على هذا المنتج فقط، وتاريخ الفحص بتوقيت UTC حتى لا يرفضه الخادم. ويمكن أن توقف الخط إذا ظهرت نتيجة حرجة جديدة، بقراءة حقل created في الرد، فيصبح DefectDojo جزءاً من قرار النشر لا سجلاً بعده.

ماذا تنسخ احتياطياً؟

DefectDojo هو ذاكرة فريقك الأمنية، فإذا ضاع ضاعت قرارات الفرز وتواريخ الإصلاح التي يحتاجها المدقق. وما يجب نسخه شيئان: قاعدة PostgreSQL بالأمر pg_dump، وفيها كل النتائج والقرارات، وVolume الوسائط defectdojo_media، وفيه التقارير والملفات المرفقة. أما ال Images والإعدادات فتعيد بناءها من ملف Compose وملف .env، واحفظ الأخير في مدير الأسرار، لأن المفتاح DD_CREDENTIAL_AES_256_KEY بدونه لا تستطيع فك الاعتمادات المخزنة حتى لو استعدت القاعدة.

الرخصة والنسخة التجارية

النسخة المجتمعية Community Edition مفتوحة المصدر بالكامل بترخيص BSD، ومجانية للاستخدام الداخلي والتجاري دون قيد، وهي ما جربناه. وإلى جانبها نسخة تجارية DefectDojo Pro، وبحسب صفحة الأسعار في 25 أكتوبر 2026 تبدأ خطة الدفع بالاستخدام من مئة دولار شهرياً زائد خمسة عشر سنتاً لكل نتيجة تعالج، وهناك اتفاق سنوي بسعر حسب الطلب للفرق الكبيرة، وتضيف واجهة أحدث ولوحات وتقارير ومزايا ذكاء اصطناعي ودعماً. ولاحظنا أن رسائل الخطأ في واجهة API نفسها في النسخة المجتمعية تحمل سطراً يذكر النسخة التجارية. ولمتابعة نتائج فاحصيك في شركة صغيرة فالنسخة المجتمعية كافية، فشركة الحجوزات في قصتنا لم تحتج شيئاً من النسخة التجارية.

متى لا تحتاج DefectDojo؟

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

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

وإذا كنت تتابع ثغرات المكتبات في تطبيقاتك من قوائم SBOM أكثر من نتائج الفحص الشبكي، فقد يناسبك Dependency-Track الذي ذكرناه في أدوات إدارة الثغرات، فهو مبني حول المكونات لا حول نتائج الفاحصين. والفرق العملي أن DefectDojo يجمع ما تقوله الأدوات عن خدماتك، وDependency-Track يتابع ما تحتويه تطبيقاتك، وكثير من الفرق تشغل الاثنين.

مشكلات شائعة Common Problems وحلولها

• الصفحة لا تفتح بعد up -d مباشرة: انتظر حتى ينتهي initializer من الترحيلات، فأول إقلاع أخذ عندنا نحو سبع دقائق، وتابع docker compose logs -f initializer.
• كل استيراد يضيف نتائج جديدة بدل أن يوسمها مكررة: فعل enable_deduplication من إعدادات النظام، فهو معطل افتراضياً في هذا الإصدار.
• الإنذار الخاطئ يعود في كل فحص: فعل false_positive_history ليحفظ القرار ويطبقه تلقائياً.
• ثغرات مصلحة عادت مفتوحة: غالباً استورد أحدهم ملفاً قديماً بـ import في اختبار جديد، فاستخدم reimport في الاختبار نفسه مع close_old_findings=true.
• رسالة scan_date cannot be in the future: ضع تاريخاً بتوقيت الخادم UTC.
• Internal server error عند استيراد OpenVAS: اقرأ سجل uwsgi، فإذا كان الخطأ في xml_parser.py فالملف ملفوف في get_reports_response، فاستخرج عنصر report واجعله الجذر.
• مقاييس الإصلاح تبدو أفضل من الواقع: الإنذارات الخاطئة توسم Mitigated أيضاً، فافصلها عند حساب سرعة الإصلاح.

قائمة تحقق لتشغيل DefectDojo في شركتك

الخلاصة

وصلنا لنهاية السلسلة، وأهم ما ظهر في المختبر:

• DefectDojo لا يفحص شيئاً، بل يتذكر ويوحد ويلزم، وهو حلقة المتابعة التي تحول الفحص إلى إصلاح قابل للإثبات أمام المدقق.
• إزالة التكرار وسجل الإنذارات الخاطئة معطلان افتراضياً في 3.4.202، وبعد تفعيلهما وسم 13 نتيجة من 19 مكررة.
• داخل الاستيراد الواحد جمع 26 سطراً من Nuclei في 19 نتيجة، لأن البصمة تحسب من العنوان والضعف والخطورة والمكون.
• إعادة الاستيراد بعد الإصلاح أغلقت ست نتائج وحدها وختمتها بتاريخ المعالجة، بينما الاستيراد الخاطئ إلى اختبار جديد أعاد فتح الست نفسها.
• تقرير OpenVAS احتاج إصلاحاً بسيطاً في جذر XML، واستورد 37 نتيجة، لكن رقم CVE لم ينتقل، فوثقناه في ملاحظة الفرز.
• الأداتان صارتا في منتج واحد بمهلة واحدة، والنسخة المجتمعية كافية لشركة صغيرة.

دليلفحص الثغرات المعروفة Known Vulnerabilities مع Nucleiشغلنا Nuclei على خدمات قديمة في شبكة Docker معزولة، فأصاب في ثغرات Apache وGrafana وأعطى أربعة إنذارات خاطئة على Redis.دليلالفحص الشبكي للثغرات Network Scan مع OpenVASشغلنا منصة Greenbone المجتمعية وفحصنا بها سيرفر Debian، فانتظرنا أربع ساعات قبل أول فحص ووجدنا نتائج حرجة كلها إنذارات خاطئة.دليلأدوات إدارة الثغرات Vulnerability Management مفتوحة المصدرأي أداة مفتوحة المصدر تجرد سيرفراتك وتطابقها مع الثغرات وتنبهك بالجديد، وماذا رأى Trivy وGrype فعلاً في ثغرات أكتوبر.دليلمختبر Lab: اكتشف السيرفرات المتأثرة بثغرة CVE جديدة وأصلحهافحصنا ثلاثة سيرفرات قديمة وسيرفراً محدثاً بأدوات Trivy وWazuh وسكربت تنبيه صغير، فظهر من يكتشف ثغرة الأسبوع ومن يفوته.دليلإدارة الثغرات Vulnerability Management: هل سيرفرك متأثر؟كيف تعرف خلال ساعات أن ثغرة جديدة تمس سيرفراتك، ولماذا يخدعك رقم الإصدار، وكيف ترتب الإصلاح وتتأكد أنه تم فعلاً.

تدريب عملي Practice

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

سجل التحديثات

• أكتوبر 2026: كتابة المقال وتنفيذ المختبر بين 25 و26 أكتوبر 2026 على DefectDojo Community Edition 3.4.202 مع نتائج Nuclei وOpenVAS الحقيقية من مقالات السلسلة.