أدوات إدارة الثغرات Vulnerability Management مفتوحة المصدر

في مقال إدارة الثغرات Vulnerability Management رأينا أن السؤال «أي سيرفر عندي متأثر بثغرة اليوم؟» لا تجيب عنه مقارنة php -v بالنشرة، وأن الإجابة الصحيحة تأتي من دورة من خمس خطوات: الجرد Inventory، ثم المطابقة Matching، ثم ترتيب الأولوية Prioritization، ثم الإصلاح Patch، ثم التحقق Verification. وفي هذا المقال سوف ننتقل من الفكرة إلى الأدوات، فلكل خطوة أدوات مفتوحة المصدر تستضيفها بنفسك، وبعضها يغطي أكثر من خطوة، وبعضها يبدو مفتوح المصدر وترخيصه ليس كذلك. ثم سوف نشغل Trivy وGrype على Docker Images فيها Java وPHP وNode.js قديمة، لنرى بالأرقام ماذا رأت كل أداة من ثغرات 21 أكتوبر 2026 وماذا فاتها، ولماذا.

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

• خريطة الأدوات بحسب العمل: الجرد، والمطابقة، والفحص الشبكي Network Scan، والتنبيه Alerts بالثغرات الجديدة، والمتابعة Tracking.
• نقاط القوة ونقاط الضعف لكل أداة: Syft وosquery مع Fleet وTrivy وGrype وOSV-Scanner وWazuh وGreenbone OpenVAS وNuclei وOpenCVE وDependency-Track وDefectDojo.
• جدول مقارنة بالتراخيص Licenses والإصدارات والموارد من الصفحات الرسمية.
• تجربة عملية Lab: Trivy وGrype على أربع Docker Images، ثم على نظام الملفات Root Filesystem كأنه سيرفر، ثم بعد الإصلاح.
• من يختار ماذا: سيرفر واحد، وشركة صغيرة، وسيرفرات كثيرة.

ولن نكرر هنا ما شرحناه في مقالين سابقين، فتشغيل OSV-Scanner وDependency-Track على مكتبات التطبيق في فحص الاعتماديات SCA، والفرق بين Trivy وGrype داخل ال Docker Image وكيف يقرر الفاحص أن الحزمة مصابة في فحص ال Docker Images وملفات البنية ككود. أما هنا فالتركيز على السيرفرات والخدمات التي تعمل في الإنتاج.

خريطة الأدوات بحسب العمل Job

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

الجرد Inventory: ماذا يعمل عندي؟

الجرد هو قائمة بكل حزمة ونسختها الكاملة على كل سيرفر وفي كل Image، وصيغتها المعيارية هي SBOM (Software Bill of Materials) بصيغة CycloneDX أو SPDX، بحيث تحفظها مرة ثم تطابقها كل يوم دون أن تعيد فحص السيرفر.

Syft: قائمة SBOM من ال Image أو المجلد

Syft من شركة Anchore أداة سطر أوامر CLI تقرأ Docker Image أو مجلداً أو نظام ملفات وتخرج قائمة SBOM، وترخيصها Apache-2.0 وآخر إصدار في 22 أكتوبر 2026 هو 1.55.0. وما يميزها أنها لا تكتفي بقاعدة بيانات الحزم، وإنما تتعرف على الملفات التنفيذية Binaries المبنية من المصدر، فعندما شغلناها على Docker Image الرسمية لـ PHP وجدت php-cli وlibphp بالنسخة 8.4.26، وفي Image الرسمية لـ Node.js وجدت node 24.21.0، وفي Eclipse Temurin وجدت openjdk 21.0.12.1+1-LTS.

• نقاط القوة: خفيفة، ولا تحتاج سيرفراً، وتخرج صيغاً معيارية تقرؤها Grype وDependency-Track وغيرهما، وتتعرف على الملفات التنفيذية.
• نقاط الضعف: لا تجمع القوائم من سيرفراتك تلقائياً، فعليك أن تشغلها من خط CI أو من مهمة مجدولة Cron وترسل الناتج إلى مكان مركزي.

osquery وFleet: اسأل كل سيرفراتك بلغة SQL

osquery وكيل Agent يعرض نظام التشغيل كجداول تستعلم عنها بلغة SQL، مثل جدول deb_packages للحزم المثبتة، وترخيصه Apache-2.0 أو GPL-2.0 بحسب اختيارك، وآخر إصدار 5.24.0. وحده لا يعرف شيئاً عن الثغرات، ولذلك يأتي معه غالباً Fleet الذي يدير آلاف الوكلاء من واجهة واحدة، ويطابق البرامج المثبتة بالثغرات كما في صفحة معالجة الثغرات في وثائقه.

• نقاط القوة: جرد حي لكل الأجهزة بما فيها أجهزة الموظفين بـ Windows وmacOS، واستعلام واحد يجيب «أين يوجد PHP 8.2؟» في ثوان.
• نقاط الضعف: ترخيص Fleet هو MIT للجزء الأساسي، والمجلد ee/ تحت ترخيص تجاري منفصل، وبعض المزايا مثل تقييمات CVSS من NVD في النسخة المدفوعة Fleet Premium بحسب الوثائق. وتقول الوثائق أيضاً إن بعض البرامج على Linux تطابق بالرقم مع NVD وحدها، فتظهر إنذارات خاطئة False Positives لأن NVD لا تعرف الإصلاحات المنقولة Backports.

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

المطابقة Matching: أي حزمة متأثرة؟

Trivy: فاحص واحد لل Image والسيرفر

Trivy من Aqua Security، ترخيصه Apache-2.0 وآخر إصدار 0.76.1. يفحص Docker Image، ونظام ملفات كامل بالأمر trivy rootfs، ومستودعات الكود، وملفات SBOM، ويطابق حزم التوزيعة ببيانات التوزيعة نفسها، فيرى الإصلاحات المنقولة بشكل صحيح.

• نقاط القوة: ملف تنفيذي واحد دون سيرفر، ويفحص السيرفر نفسه لا ال Image فقط، وقاعدة بياناته تتحدث كثيراً، وفي تجربتنا كانت الوحيدة التي رأت ثغرتي Java وBrotli في حزم Debian.
• نقاط الضعف: لم يتعرف على PHP المبني من المصدر في ال Image الرسمية، ولا على ال JDK نفسه، وقاعدة بيانات Java التي ينزلها في أول فحص حجمها 941 MiB، فأول فحص على سيرفر بطيء قد يتجاوز المهلة الافتراضية كما سنرى.

Grype: المطابقة مع التعرف على الملفات التنفيذية Binaries

Grype من Anchore، ترخيصه Apache-2.0 وآخر إصدار 0.121.0، ويستخدم Syft داخلياً، لذلك يتعرف على الملفات التنفيذية ويطابقها بمعرفات CPE من NVD عندما لا تكون من حزمة توزيعة.

• نقاط القوة: وجد ثغرتي PHP في ال Image الرسمية التي لم ير Trivy فيها PHP أصلاً، ويقبل SBOM من Syft فتطابق الجرد المحفوظ دون إعادة الفحص.
• نقاط الضعف: المطابقة بمعرف CPE تنتظر NVD، فثغرتا Java وBrotli لم تظهرا في الملفات التنفيذية لأن سجليهما في NVD بلا CPE بعد، وقاعدة بياناته في تجربتنا كانت أقدم بسبع ساعات من قاعدة Trivy ففاتتها إضافات Debian لذلك اليوم.

OSV-Scanner: مكتبات التطبيق Libraries

OSV-Scanner من Google، ترخيصه Apache-2.0 وآخر إصدار 2.7.0، ويقرأ ملفات القفل Lockfiles لمكتبات التطبيق ويطابقها بقاعدة OSV، وقد شرحناه بالتفصيل في مقال SCA. ومكانه في السيرفرات هو مجلدات التطبيقات المنشورة، مثل composer.lock لتطبيق PHP أو package-lock.json لتطبيق Node، لأن ثغرات المكتبات لا تظهر في جرد حزم التوزيعة.

Wazuh: الجرد والمطابقة والتنبيه في وكيل واحد

وحدة اكتشاف الثغرات في Wazuh تعمل هكذا بحسب وثائقها: الوكيل على كل سيرفر يرسل قائمة البرامج المثبتة إلى سيرفر Wazuh، والوحدة تطابقها بمستودع الثغرات في منصة Wazuh CTI أو بنسخة محلية منه، ثم تظهر النتائج كتنبيهات في اللوحة نفسها مع بقية الأحداث الأمنية. وترخيص Wazuh هو GPL-2.0 لأغلب الكود، مع AGPL-3.0 لمحرك التحليل، وآخر إصدار 4.14.9.

• نقاط القوة: إذا كان عندك Wazuh كنظام SIEM فإدارة الثغرات تأتي معه دون أداة إضافية، والنتائج مرتبطة بالجهاز وبقية أحداثه.
• نقاط الضعف: منظومة كاملة فيها سيرفر وقاعدة فهرسة Indexer ولوحة، فهي ثقيلة لمن يريد فحص الثغرات فقط، ولا تفحص ال Docker Images قبل النشر.

الفحص الشبكي Network Scan: ماذا يرى المهاجم؟

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

Greenbone OpenVAS: الفاحص الشبكي الكامل

نسخة Greenbone Community Edition تجمع الفاحص OpenVAS بترخيص GPL-2.0 ومدير الفحوص gvmd بترخيص AGPL-3.0 مع لوحة ويب، وتأخذ اختباراتها من Community Feed. وتقول وثائق التثبيت بالحاويات إن الحد الأدنى معالجان CPU و4 GB من الذاكرة RAM و20 GB من التخزين، والموصى به 4 معالجات و8 GB و60 GB.

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

Nuclei: قوالب Templates سريعة للثغرات المعروفة

Nuclei من ProjectDiscovery، ترخيصه MIT وآخر إصدار 3.11.1، يرسل طلبات محددة مكتوبة في قوالب Templates يكتبها المجتمع، كثير منها لثغرة CVE بعينها، ويحكم من الرد هل الخدمة متأثرة.

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

التنبيه Alerts: هل ظهرت ثغرة جديدة في منتجاتي؟

OpenCVE: اشتراك بالمورد والمنتج

OpenCVE منصة تزامن قائمة CVE من MITRE وNVD وRed Hat وغيرها، وتشترك فيها بمورد أو منتج مثل PHP أو Oracle Java، فتصلك رسالة بالبريد أو Slack أو Webhook عند إضافة ثغرة أو تحديثها، ولها نسخة سحابية ونسخة تستضيفها بنفسك، وآخر إصدار 3.1.0. ولكن انتبه إلى ترخيصها، فهو Business Source License 1.1، وينص الملف نفسه على أنه ليس ترخيصاً مفتوح المصدر، ويسمح بالاستخدام الداخلي ويمنع تقديمها خدمة تنبيه أمني تجارية لطرف ثالث، ويتحول إلى Apache-2.0 في 14 أغسطس 2030.

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

Dependency-Track: ثغرة جديدة على جرد قديم

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

المتابعة Tracking: من يصلح ومتى؟

Dependency-Track: لوحة Dashboard للجرد والمخاطر

ترخيصه Apache-2.0 وآخر إصدار 5.2.0، وتقول وثائق التثبيت إن سيرفر ال API يحتاج كحد أدنى 2 GB من الذاكرة ومعالجين، والموصى به 8 GB وأربعة معالجات.

• نقاط القوة: يستقبل SBOM من Syft أو غيره لكل سيرفر وكل Image، ويعرض أين يوجد المكون المتأثر في كل المشاريع، وله سياسات وتنبيهات وواجهة API.
• نقاط الضعف: مصمم أصلاً لمكونات البرمجيات، فحزم نظام التشغيل تحتاج SBOM صحيحاً لكل سيرفر، ولا يجمعها بنفسه.

DefectDojo: مكان واحد لنتائج كل الأدوات

DefectDojo مشروع من OWASP بترخيص BSD-3-Clause وآخر إصدار 3.4.202، يستقبل تقارير أدوات الفحص المختلفة، ويزيل التكرار بينها، ويربط كل نتيجة بمنتج وصاحب وموعد إصلاح، وله نسخة تجارية Pro إلى جانب نسخة المجتمع.

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

جدول المقارنة Comparison

الإصدارات والتراخيص من المستودعات الرسمية في 22 أكتوبر 2026، والموارد من الوثائق الرسمية حيث ذكرتها:

تجربة عملية Lab: ماذا رأى Trivy وGrype في ثغرات أكتوبر؟

لنفرض أن عندك أربع خدمات: سيرفر Debian 12 ثبت عليه PHP وNode.js وJava من مستودع التوزيعة ولم يحدث منذ أسبوع، وثلاث خدمات تعمل من Docker Images رسمية لـ PHP مع Apache وNode.js وJava. والسؤال: هل يكشف الفاحص ثغرات 21 أكتوبر في كل منها؟

تجهيز سيرفر قديم بحزم Packages يوم 15 أكتوبر

لكي نحصل على حزم Debian كما كانت قبل النشرات نستخدم أرشيف snapshot.debian.org الذي يحفظ المستودع في كل لحظة، فنبني Docker Image تمثل السيرفر القديم:

# Old stack: Debian 12 packages as they were on 15 October 2026 (before the PHP, Java and Node advisories)
FROM debian:12.15
ARG SNAP=20261015T000000Z
RUN rm -f /etc/apt/sources.list.d/debian.sources \
 && printf '%s\n' \
    "deb [check-valid-until=no] http://snapshot.debian.org/archive/debian/${SNAP} bookworm main" \
    "deb [check-valid-until=no] http://snapshot.debian.org/archive/debian/${SNAP} bookworm-updates main" \
    "deb [check-valid-until=no] http://snapshot.debian.org/archive/debian-security/${SNAP} bookworm-security main" \
    > /etc/apt/sources.list \
 && apt-get update \
 && DEBIAN_FRONTEND=noninteractive apt-get install -y --no-install-recommends php8.2-cli nodejs openjdk-17-jre-headless \
 && rm -rf /var/lib/apt/lists/*

docker build -t oldstack:2026-10-15 .

والحزم التي ثبتت هي php8.2-cli 8.2.34-1~deb12u1 وnodejs 18.20.4+dfsg-1~deb12u3 وlibbrotli1 1.0.9-2+b6 وopenjdk-17-jre-headless 17.0.20.1+1-1~deb12u1، وكلها متأثرة بحسب متتبع Debian كما رأينا في المقال السابق.

Trivy على السيرفر القديم

docker run --rm \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v trivy-cache:/root/.cache \
  -v "$PWD:/out" \
  aquasec/trivy:0.76.1 image --scanners vuln --format json -o /out/trivy-oldstack.json oldstack:2026-10-15

وفي أول تشغيل على جهاز جديد نزل Trivy قاعدة الثغرات بحجم 129 MiB، ثم قاعدة Java بحجم 941 MiB في ست دقائق ونصف، لأن ال Image فيها ملفات Java، ثم توقف بهذا الخطأ:

2026-10-22T14:34:35Z	WARN	Provide a higher timeout value, see https://trivy.dev/docs/v0.76/guide/references/troubleshooting#timeout
2026-10-22T14:34:35Z	FATAL	Fatal error	run error: image scan error: scan error: scan failed: failed analysis: analyze error: pipeline error: failed to analyze layer (sha256:33db498b995aa06384d9ca5d059b585ef15816fbea248d207b4b3992759b2a29): post analysis error: post analysis error: walk dir error: walk error: context deadline exceeded

والسبب أن المهلة الافتراضية للفحص خمس دقائق، والتنزيل استهلكها. والحل إما رفع المهلة بالخيار --timeout 30m، أو تنزيل القواعد مسبقاً في مهمة مستقلة، وبعد أن أصبحت القاعدتان في ال Volume المسمى trivy-cache انتهى الفحص نفسه في دقيقة و49 ثانية. ثم نستخرج من التقرير ثغرات أكتوبر فقط:

jq '[.Results[].Vulnerabilities[]?] | length' trivy-oldstack.json
jq -r '.Results[].Vulnerabilities[]? | select(.VulnerabilityID | test("2026-(109618|109619|111497|91403)")) | [.PkgName, .VulnerabilityID, .Status, (.FixedVersion // "-")] | @tsv' trivy-oldstack.json

495
libbrotli1	CVE-2026-111497	affected	-
libnode108	CVE-2026-111497	affected	-
nodejs	CVE-2026-111497	affected	-
openjdk-17-jre-headless	CVE-2026-91403	affected	-
php8.2-cli	CVE-2026-109618	fixed	8.2.35-1~deb12u1
php8.2-cli	CVE-2026-109619	fixed	8.2.35-1~deb12u1
php8.2-common	CVE-2026-109618	fixed	8.2.35-1~deb12u1
php8.2-common	CVE-2026-109619	fixed	8.2.35-1~deb12u1
php8.2-opcache	CVE-2026-109618	fixed	8.2.35-1~deb12u1
php8.2-opcache	CVE-2026-109619	fixed	8.2.35-1~deb12u1
php8.2-readline	CVE-2026-109618	fixed	8.2.35-1~deb12u1
php8.2-readline	CVE-2026-109619	fixed	8.2.35-1~deb12u1

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

• رأى Trivy الثغرات الأربع كلها، وهذا لأن قاعدة بياناته حدثت الساعة 13:15 بتوقيت UTC بعد أن أضاف متتبع Debian ثغرتي Brotli وJava.
• الحالة fixed مع رقم الإصلاح لـ PHP تعني أن الحل جاهز الآن: 8.2.35-1~deb12u1، أما affected دون رقم لـ Brotli وJava فتعني أن Debian لم تصدر الإصلاح بعد، فهذه تحتاج تخفيفاً أو متابعة لا تحديثاً.
• العدد الكلي 495 نتيجة لسيرفر عمره أسبوع، وثغرات أكتوبر 12 سطراً فقط منها، وهذا بالضبط سبب الحاجة إلى ترتيب الأولوية.

Grype على السيرفر نفسه

docker run --rm \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v grype-cache:/root/.cache \
  -v "$PWD:/out" \
  anchore/grype:v0.121.0 oldstack:2026-10-15 -o json --file /out/grype-oldstack.json

jq '.matches | length' grype-oldstack.json
jq -r '.matches[] | select(.vulnerability.id | test("2026-(109618|109619|111497|91403)")) | [.artifact.name, .artifact.type, .vulnerability.id, .vulnerability.fix.state, (.vulnerability.fix.versions | join(",")), .matchDetails[0].type] | @tsv' grype-oldstack.json

465
php8.2-cli	deb	CVE-2026-109618	fixed	8.2.35-1~deb12u1	exact-indirect-match
php8.2-cli	deb	CVE-2026-109619	fixed	8.2.35-1~deb12u1	exact-indirect-match
php8.2-common	deb	CVE-2026-109618	fixed	8.2.35-1~deb12u1	exact-indirect-match
php8.2-common	deb	CVE-2026-109619	fixed	8.2.35-1~deb12u1	exact-indirect-match
php8.2-opcache	deb	CVE-2026-109618	fixed	8.2.35-1~deb12u1	exact-indirect-match
php8.2-opcache	deb	CVE-2026-109619	fixed	8.2.35-1~deb12u1	exact-indirect-match
php8.2-readline	deb	CVE-2026-109618	fixed	8.2.35-1~deb12u1	exact-indirect-match
php8.2-readline	deb	CVE-2026-109619	fixed	8.2.35-1~deb12u1	exact-indirect-match

وجد Grype ثغرتي PHP بالإصلاح نفسه، ولم يجد Java ولا Brotli. وقد يتساءل البعض: هل Grype أضعف؟ والإجابة أن الفرق هنا في عمر قاعدة البيانات لا في الأداة، فالأمر grype db status أظهر أن قاعدته بنيت الساعة 06:29 بتوقيت UTC، وثغرة Brotli دخلت بيانات Debian في OSV الساعة 07:47، وثغرة Java الساعة 12:47، أي بعد بناء القاعدة. وكلمة exact-indirect-match تعني أن المطابقة تمت عبر الحزمة المصدر php8.2 في بيانات Debian، لا برقم PHP الأصلي.

ال Docker Images الرسمية: هنا تختلف الأداتان فعلاً

والآن نشغل الأداتين بالأوامر نفسها على ثلاث Docker Images رسمية قديمة: php:8.4.26-apache وnode:24.21.0-bookworm-slim وeclipse-temurin:21.0.12.1_1-jre، ونستخرج ثغرات أكتوبر بأوامر jq نفسها. وكانت النتيجة:

### trivy-php_8.4.26-apache.json total=1784
libbrotli1	CVE-2026-111497	affected	-
### trivy-node_24.21.0-bookworm-slim.json total=262
### trivy-eclipse-temurin_21.0.12.1_1-jre.json total=71
### grype-php_8.4.26-apache.json total=980
libphp	binary	CVE-2026-109618	fixed	8.2.35,8.3.36,8.4.27,8.5.12	cpe-match
libphp	binary	CVE-2026-109619	fixed	8.2.35,8.3.36,8.4.27,8.5.12	cpe-match
php-cli	binary	CVE-2026-109618	fixed	8.2.35,8.3.36,8.4.27,8.5.12	cpe-match
php-cli	binary	CVE-2026-109619	fixed	8.2.35,8.3.36,8.4.27,8.5.12	cpe-match
### grype-node_24.21.0-bookworm-slim.json total=256
### grype-eclipse-temurin_21.0.12.1_1-jre.json total=151

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

• في Image الـ PHP الرسمية لم ير Trivy ثغرتي PHP أصلاً، لأن PHP هنا مبني من المصدر ولا يظهر في قاعدة بيانات حزم Debian، بينما تعرف Grype على الملفات php-cli وlibphp وطابقها بمعرف CPE من NVD، فنوع المطابقة cpe-match. ومن الجهة الأخرى رأى Trivy ثغرة Brotli في حزمة libbrotli1 الخاصة بـ Debian 13 داخل ال Image نفسها ولم يرها Grype.
• في Image الـ Node.js لم تظهر ثغرة Brotli عند أي منهما، رغم أن Syft تعرف على node 24.21.0. والسبب أن سجل الثغرة مكتوب على مشروع Brotli لا على Node.js، وأن NVD لم تضف له معرفات CPE بعد، فلا يوجد ما يربط الثغرة بالملف التنفيذي لـ Node.
• والأمر نفسه مع Java، فـ Grype رأى openjdk 21.0.12.1+1-LTS لكن سجل CVE-2026-91403 في NVD ما زال بحالة Received دون CPE، وTrivy لم يتعرف على ال JDK كحزمة.

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

فحص السيرفر نفسه بالأمر trivy rootfs

وعلى السيرفر الذي لا يعمل بال Containers تفحص نظام الملفات مباشرة، وهنا نضيف الخيار --ignore-unfixed لنرى فقط ما له إصلاح متاح الآن، أي ما تستطيع فعله اليوم:

trivy rootfs --scanners vuln --severity CRITICAL --ignore-unfixed \
  --skip-dirs /proc --skip-dirs /sys --format json -o rootfs.json /
jq -r '.Results[].Vulnerabilities[]? | [.PkgName, .VulnerabilityID, .InstalledVersion, .FixedVersion] | @tsv' rootfs.json

php8.2-cli	CVE-2026-109618	8.2.34-1~deb12u1	8.2.35-1~deb12u1
php8.2-cli	CVE-2026-109619	8.2.34-1~deb12u1	8.2.35-1~deb12u1
php8.2-common	CVE-2026-109618	8.2.34-1~deb12u1	8.2.35-1~deb12u1
php8.2-common	CVE-2026-109619	8.2.34-1~deb12u1	8.2.35-1~deb12u1
php8.2-opcache	CVE-2026-109618	8.2.34-1~deb12u1	8.2.35-1~deb12u1
php8.2-opcache	CVE-2026-109619	8.2.34-1~deb12u1	8.2.35-1~deb12u1
php8.2-readline	CVE-2026-109618	8.2.34-1~deb12u1	8.2.35-1~deb12u1
php8.2-readline	CVE-2026-109619	8.2.34-1~deb12u1	8.2.35-1~deb12u1

ونفس الأمر دون --ignore-unfixed أعطى 16 نتيجة حرجة، منها ثغرات في undici وglib وsqlite وlibxml2 بحالة affected أو fix_deferred لا إصلاح لها في Debian 12 الآن. فالخيار لا يخفي الخطر، وإنما يفصل قائمة «حدث الآن» عن قائمة «تابع وخفف»، وكلتاهما تحتاج صاحباً.

بعد الإصلاح Patch: هل اختفت فعلاً؟

حدثنا السيرفر القديم من مستودع Debian الحالي بالأمر apt-get upgrade وبنينا منه oldstack:patched، وانتقلنا في PHP الرسمي إلى php:8.4.27-apache، ثم أعدنا الفحص بالأوامر نفسها:

### trivy-patched.json total=482
libbrotli1	CVE-2026-111497	affected	-
libnode108	CVE-2026-111497	affected	-
nodejs	CVE-2026-111497	affected	-
openjdk-17-jre-headless	CVE-2026-91403	affected	-
### grype-patched.json total=457
### grype-php_8.4.27-apache.json total=976

• اختفت ثغرتا PHP من السيرفر لأن الحزمة أصبحت 8.2.35-1~deb12u1، واختفتا من Image الـ PHP الرسمية بعد الانتقال إلى 8.4.27.
• بقيت Brotli وJava في Trivy لأن Debian 12 لم تصدر إصلاحهما حتى وقت التجربة، فالتحديث الكامل لم يغلقهما، وهذا وضع طبيعي يجب أن تسجله كخطر مفتوح مع تخفيف ومتابعة لنشرة التوزيعة.
• تقرير Grype للسيرفر بعد الإصلاح خال من ثغرات أكتوبر، لكن ذلك لأن قاعدته لا تعرف ثغرتي Brotli وJava بعد، لا لأنهما أغلقتا، فلا تقرأ «لا شيء» على أنها «آمن».

إزالة التجربة Cleanup

docker image rm oldstack:2026-10-15 oldstack:patched php:8.4.26-apache php:8.4.27-apache node:24.21.0-bookworm-slim eclipse-temurin:21.0.12.1_1-jre
docker volume rm trivy-cache grype-cache

من يختار ماذا؟ Who Should Choose What

سيرفر واحد Single Server

إذا كنت تدير سيرفراً واحداً لمشروعك فلا تبن منظومة، وإنما فعل التحديثات الأمنية التلقائية كما شرحنا في تأمين خادم VPS من أول دخول، ثم شغل Trivy أسبوعياً بمهمة Cron على السيرفر بالأمر trivy rootfs مع --ignore-unfixed وعلى كل Image تشغلها، وأرسل الحرج فقط إلى بريدك، واشترك في نشرات توزيعتك والمنتجات التي تشغلها. وهذا كله لا يحتاج سيرفراً إضافياً.

شركة صغيرة Small Company

من خمسة إلى خمسين سيرفراً مع Containers تحتاج جرداً مركزياً، فالتركيب العملي: Syft يخرج SBOM لكل سيرفر وكل Image من مهمة مجدولة ومن خط CI، وDependency-Track يحفظها ويعيد تحليلها وينبه الفريق، وTrivy أو Grype كبوابة Gate في خط CI، وGreenbone مرة في الشهر من خارج الشبكة، واشتراك في OpenCVE أو تنبيهات الهيئة للمنتجات التي لا يغطيها الجرد. وكل هذا يعمل على سيرفر إدارة واحد متوسط.

سيرفرات كثيرة Many Servers

مع مئات الأجهزة يصبح الوكيل Agent ضرورياً، فإما Wazuh إن كنت تريد SIEM وإدارة الثغرات معاً، أو osquery مع Fleet إن كان الجرد الحي لكل الأجهزة هو الأهم. ثم Greenbone وNuclei للرؤية من الخارج، وDefectDojo لتجميع كل النتائج وتحويلها إلى مهام لها أصحاب ومواعيد إصلاح بحسب الخطورة. وهنا لا تكفي الأدوات، فأنت تحتاج من يتابع اللوحة كل يوم، وإلا فلن يتغير شيء.

أخطاء شائعة Common Mistakes

• اعتبار التقرير النظيف دليلاً على الأمان: كما رأينا في Image الـ Node.js، فالتقرير النظيف قد يعني أن قاعدة البيانات أو طريقة التعرف لا ترى الثغرة بعد.
• أداة واحدة لكل شيء: الفاحص الشبكي لا يرى المكتبات، والفاحص الداخلي لا يرى الخدمة المكشوفة التي نسيتها، فاجمع بين الرؤيتين.
• تجاهل عمر قاعدة البيانات: افحص بعد تحديث القاعدة، واعرض تاريخها في التقرير بالأمر grype db status أو trivy version.
• فحص الأسبوع الأول ثم النسيان: قيمة Dependency-Track وWazuh أنهما يعيدان المطابقة كل يوم على الجرد نفسه، والثغرة التي تنشر غداً تظهر دون فحص جديد.
• الخلط بين مفتوح المصدر والمتاح المصدر: اقرأ ملف الترخيص قبل أن تبني عليه، فـ OpenCVE بترخيص BSL، وجزء من Fleet تجاري.
• تشغيل الفحص الشبكي على أنظمة لا تملكها: لا تقم بذلك دون إذن مكتوب، والسبب أنه يعامل كمحاولة هجوم.

الخلاصة

وصلنا لنهاية الموضوع، وأهم ما فيه:

• لا توجد أداة واحدة لإدارة الثغرات، والتركيب الصحيح جرد ومطابقة من الداخل، وفحص شبكي من الخارج، ومكان واحد للمتابعة.
• Trivy فحص السيرفر وال Image دون سيرفر إضافي، ورأى الثغرات الأربع في حزم Debian، لكنه لم ير PHP المبني من المصدر.
• Grype تعرف على الملفات التنفيذية ووجد ثغرتي PHP في ال Image الرسمية، لكن مطابقته بالـ CPE تنتظر NVD، وقاعدته كانت أقدم بسبع ساعات ففاتتها ثغرتان.
• ثغرتا Node.js وJava لم تظهرا في الملفات التنفيذية الرسمية عند أي أداة في اليوم الأول، فالنشرة الأصلية تبقى المرجع.
• OpenCVE مفيد للتنبيه لكن ترخيصه BSL وليس مفتوح المصدر، وFleet مفتوح في جزئه الأساسي فقط.
• لسيرفر واحد: تحديثات تلقائية وTrivy أسبوعي، ولشركة صغيرة: Syft مع Dependency-Track وGreenbone، ولسيرفرات كثيرة: Wazuh أو Fleet مع DefectDojo.

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

دليلإدارة الثغرات Vulnerability Management: هل سيرفرك متأثر؟كيف تعرف خلال ساعات أن ثغرة جديدة تمس سيرفراتك، ولماذا يخدعك رقم الإصدار، وكيف ترتب الإصلاح وتتأكد أنه تم فعلاً.دليلSCA: كيف تجد الثغرات المعروفة في مكتبات مشروعككيف تجد أداة فحص الاعتماديات SCA المكتبات المصابة في مشروعك، ولماذا تختلف نتائج الأدوات، وكيف تبقي مكتباتك محدثة.دليلفحص ال Docker Images وملفات البنية ككود IaCماذا يرى فاحص الثغرات داخل ال Docker Image وما الذي يفوته، وكيف تختار Base Image أصغر وتجعل الفحص بوابة في خط CI.دليلDevSecOps للمبتدئين: الأمن داخل خط CI/CD ومتى يعمل كل فحصما الذي يجده كل فحص أمني في خط CI/CD وما الذي يفوته، وكيف ترتب نتائجه حتى تصل إلى قرار بدل قائمة طويلة.دليلتأمين سيرفر VPS على Ubuntu من أول دخولقبل أن تثبت أي تطبيق على سيرفرك الجديد، هذه الخطوات تغلق أبرز الثغرات وأولها الدخول بمفتاح SSH بدل كلمة المرور.

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

• أكتوبر 2026: كتابة المقال، وتنفيذ التجربة بأدوات Trivy 0.76.1 وGrype 0.121.0 وSyft 1.55.0 على Docker Image لـ Debian 12 بحزم يوم 15 أكتوبر من snapshot.debian.org وعلى Docker Images رسمية لـ PHP وNode.js وEclipse Temurin، والتحقق من التراخيص والإصدارات والموارد من المستودعات والوثائق الرسمية في 22 أكتوبر 2026.