إذا كنت تتابع الثغرات الأمنية، فلا يكفي فتح موقع واحد والبحث عن رقم CVE. أفضل طريقة في 2026 هي استخدام عدة مصادر، لأن كل مصدر يجيب عن سؤال مختلف: ما السجل الرسمي للثغرة؟ ما المنتجات المتأثرة؟ هل توجد تصحيحات؟ هل استُغلت فعليًا؟ وما احتمال استغلالها قريبًا؟
للبحث السريع عن سجل CVE استخدم CVE.org، وللتفاصيل والتحليل استخدم NVD، ثم افحص CISA KEV لمعرفة ما إذا كان هناك استغلال موثّق في الواقع، وEPSS لتقدير احتمال الاستغلال خلال الثلاثين يومًا التالية.
أما إذا كنت مطورًا أو تتعامل مع مكتبات مفتوحة المصدر، فغالبًا ستكون GitHub Advisory Database وOSV أكثر فائدة لتحديد الحزم والإصدارات المتأثرة.
أفضل مواقع تتبع CVE في 2026
| المصدر | الأفضل في | أهم معلومة تحصل عليها |
|---|---|---|
| CVE.org | المرجع الأساسي لسجل CVE | السجل الرسمي والمراجع والجهة التي نشرت CVE |
| NVD | تحليل وتفاصيل الثغرة | CVSS وCWE وCPE وبيانات إضافية |
| CISA KEV | معرفة الاستغلال الفعلي | هل توجد أدلة موثوقة على استغلال الثغرة في الواقع؟ |
| FIRST EPSS | ترتيب أولوية المعالجة | احتمال الاستغلال خلال 30 يومًا |
| GitHub Advisory Database | المكتبات مفتوحة المصدر | الحزم والإصدارات المتأثرة والإصدارات المصححة |
| OSV | Dependencies وDevSecOps | مطابقة الثغرات مع Package وVersion وCommit |
| OpenCVE | المراقبة والتنبيهات | متابعة Vendors وProducts وتغييرات CVE |
| Vendor Advisories | قرار التصحيح النهائي | الإصدارات المتأثرة والتحديث أو Workaround الرسمي |
1. CVE.org: ابدأ من السجل الرسمي للثغرة
CVE.org هو موقع برنامج Common Vulnerabilities and Exposures، والغرض الأساسي منه تحديد الثغرات الأمنية المنشورة علنًا وتعريفها وإسناد معرفات CVE إليها.
عند البحث عن رقم مثل CVE-2026-XXXXX، يمكنك استخدام سجل CVE لمعرفة الوصف المنشور، الجهة التي أسندت السجل، المراجع الأصلية، وأي تحديثات تمت إضافتها إلى السجل.
لكن وجود معرف CVE لا يعني تلقائيًا أن الثغرة شديدة الخطورة أو أنها تُستغل حاليًا. CVE هو نظام تعريف وفهرسة بالدرجة الأولى، وليس مؤشرًا كاملًا للمخاطر.
وهذا مهم خصوصًا عند التفريق بين ثغرة Zero-Day والاستغلال الفعلي؛ فقد تكون هناك ثغرة معروفة ومعرف CVE منشور من دون وجود دليل على استغلالها في هجمات حقيقية.
2. NVD: تفاصيل CVSS وCWE والمنتجات المتأثرة
National Vulnerability Database التابعة لـNIST تضيف طبقة تحليل وإثراء فوق بيانات CVE. لهذا السبب تعد من أكثر المواقع استخدامًا عند تحليل الثغرات.
بحسب السجل المتاح للثغرة قد تجد في NVD:
- درجة وخط متجه CVSS.
- تصنيف CWE لنوع الضعف البرمجي.
- بيانات CPE للمنتجات والإصدارات.
- مراجع إلى Advisory أو Patch أو Exploit.
- تاريخ النشر وآخر تعديل للسجل.
- بيانات إثراء مقدمة من جهات أخرى.
لكن توجد نقطة مهمة جدًا في 2026: لا ينبغي تفسير غياب تحليل NVD الكامل على أنه دليل على أن الثغرة غير خطيرة. أعلنت NIST في أبريل 2026 أنها ستعطي أولوية في عملية الإثراء لثغرات CISA KEV والبرمجيات المستخدمة في الحكومة الفيدرالية والبرمجيات الحرجة، بينما قد تُصنف سجلات أخرى كأولوية منخفضة وغير مجدولة للتحليل الفوري.
كما وسعت NVD في يونيو 2026 البيانات المعروضة لتشمل معلومات SSVC وبيانات affected عند توفرها. لذلك أصبح من المهم أكثر من السابق النظر إلى مصدر السجل الأصلي وVendor Advisory بدل الاعتماد على حالة تحليل NVD وحدها. يمكن متابعة التغييرات من صفحة NVD الرسمية لدى NIST.
3. CISA KEV: هل تُستغل الثغرة بالفعل؟
إذا كان السؤال الأهم لديك هو: هل يستخدم المهاجمون هذه الثغرة في هجمات حقيقية؟ فابدأ من CISA Known Exploited Vulnerabilities Catalog.
تصف CISA الكتالوج بأنه مصدر للثغرات المعروفة بأنها استُغلت في الواقع، وتوصي المؤسسات باستخدامه كمدخل أساسي لترتيب أولويات إدارة الثغرات.
وجود CVE داخل KEV أقوى بكثير من مجرد ارتفاع CVSS. فقد توجد ثغرة بدرجة حرجة من دون دليل معروف على استغلالها، بينما قد تكون ثغرة بدرجة أقل موجودة في KEV ويجب التعامل معها بسرعة لأنها مستخدمة بالفعل ضد أهداف حقيقية.
كما يعرض KEV عادةً اسم Vendor والمنتج، تاريخ إضافة الثغرة، الإجراء المطلوب، وتاريخًا نهائيًا للمعالجة بالنسبة للجهات الفيدرالية الأمريكية المشمولة بالتوجيهات ذات الصلة.
4. FIRST EPSS: ما احتمال استغلال CVE قريبًا؟
Exploit Prediction Scoring System أو EPSS يجيب عن سؤال مختلف تمامًا عن CVSS.
CVSS يحاول وصف شدة التأثير التقني للثغرة، أما EPSS فيقدّر احتمال ملاحظة استغلال CVE في الواقع خلال الثلاثين يومًا التالية.
يصدر EPSS قيمة بين 0 و1 بالإضافة إلى Percentile، ويتم تحديث الدرجات يوميًا. على سبيل المثال، قيمة 0.10 تعني تقديرًا لاحتمال استغلال يبلغ 10% خلال نافذة التنبؤ، وليس أن خطورة الثغرة تساوي 10%.
الأهم أن EPSS نفسه لا يعتبر درجة مخاطر متكاملة؛ فهو لا يعرف مدى أهمية الخادم لديك أو ما إذا كانت الثغرة موجودة فعلًا في بيئتك أو ما هي وسائل الحماية المطبقة.
لذلك استخدم المعادلة الذهنية التالية:
- CVSS: ما شدة التأثير التقني المحتمل؟
- EPSS: ما احتمال حدوث استغلال قريب؟
- CISA KEV: هل لدينا دليل على استغلال حقيقي بالفعل؟
- بيئتك: هل المنتج المتأثر موجود ومكشوف ومهم بالنسبة لك؟
5. GitHub Advisory Database: الأفضل لمكتبات البرمجيات مفتوحة المصدر
إذا كنت مطورًا أو تعمل في AppSec وDevSecOps، فمن المفيد البحث في GitHub Advisory Database بجانب CVE.org وNVD.
الميزة الأساسية هي أن GitHub يعرض المعلومات بطريقة مرتبطة مباشرة بالنظام البرمجي والحزمة، مثل npm وPyPI وMaven وNuGet وGo وRust وغيرها.
بحسب Advisory قد تجد:
- معرف CVE ومعرف GHSA.
- اسم الحزمة.
- نطاق الإصدارات الضعيفة.
- أول إصدار مصحح.
- CVSS وCWE.
- مراجع المشروع الأصلية.
كما يمكن البحث حسب CVE أو Package أو Ecosystem أو Severity، وتوفر GitHub واجهات REST وGraphQL لمن يريد دمج البيانات داخل أدوات داخلية أو عمليات CI/CD.
هذه البيانات أكثر فائدة للمطور من معرفة أن "CVE موجود" فقط، لأن السؤال الحقيقي غالبًا هو: هل النسخة المستخدمة داخل المشروع تقع داخل النطاق المتأثر؟
6. OSV: تتبع الثغرات على مستوى Package وVersion
OSV مشروع موجه أساسًا للثغرات في البرمجيات مفتوحة المصدر، ويتميز بقدرته على ربط الثغرة بإصدارات الحزم والمشاريع بطريقة مناسبة لأنظمة إدارة Dependencies.
تجمع OSV بيانات من مصادر متعددة مثل GitHub Advisory Database وقواعد بيانات PyPI وGo وUbuntu وغيرها، إضافة إلى بيانات محولة من مصادر مثل Debian وAlpine وبعض سجلات NVD المتعلقة بالبرمجيات مفتوحة المصدر.
كما توفر OSV API للبحث عن الثغرات باستخدام اسم الحزمة والإصدار أو Commit، بالإضافة إلى الاستعلام المجمع عن عدد كبير من Dependencies.
إذا كنت تدير مشروعًا يحتوي على مئات المكتبات، فإن هذا النموذج أكثر عملية من البحث اليدوي عن كل رقم CVE.
7. OpenCVE: للمراقبة المستمرة والتنبيهات
البحث اليدوي مناسب عندما لديك CVE محدد، لكنه غير عملي إذا كنت مسؤولًا عن عشرات المنتجات. هنا يصبح OpenCVE أكثر فائدة.
تتيح المنصة متابعة Vendors ومنتجات محددة ثم تلقي إشعارات عند إضافة CVE جديدة أو تعديل السجلات الموجودة. ووفق توثيق OpenCVE، يمكن تصفية التنبيهات استنادًا إلى معايير مثل CVSS ونوع التعديل، كما تدعم المنصة مصادر متعددة بدل الاعتماد على قاعدة واحدة.
وهذا يجعلها مناسبة لفرق SOC ومراقبة العمليات الأمنية أو مسؤولي الأنظمة الذين يريدون Watchlist مرتبطة بالتقنيات التي يستخدمونها فعلًا.
8. Vendor Advisory: أهم مصدر قبل اتخاذ قرار التصحيح
بعد العثور على CVE في أي قاعدة بيانات، حاول دائمًا الوصول إلى النشرة الأمنية الأصلية للجهة المصنعة.
إذا كانت الثغرة تخص Microsoft مثلًا، فإن Microsoft Security Update Guide قد يوفر الإصدارات المتأثرة والتحديثات وMitigations وWorkarounds وتاريخ مراجعات النشرة.
وبالنسبة إلى Red Hat توفر الشركة Red Hat Security Data وبيانات CSAF/VEX ومعلومات مرتبطة بالمنتجات التي تدعمها.
وينطبق المبدأ نفسه على Cisco وApple وGoogle وFortinet وVMware وUbuntu وغيرهم.
هذه الخطوة ضرورية لأن سجل CVE العام قد يخبرك بوجود الثغرة، لكن الشركة المصنعة هي الأقدر عادةً على تحديد أي Builds أو Packages من منتجها متأثرة وما الإصدار الذي يحتوي على الإصلاح.
ما الفرق بين CVE وCVSS وEPSS وKEV؟
| المصطلح | ماذا يخبرك؟ | ما الذي لا يثبته؟ |
|---|---|---|
| CVE | هوية موحدة لثغرة منشورة | لا يثبت أنها مستغلة فعليًا |
| CVSS | شدة التأثير التقني وفق مجموعة Metrics | لا يتنبأ وحده باحتمال الاستغلال |
| EPSS | احتمال ملاحظة الاستغلال خلال 30 يومًا | ليس درجة مخاطر كاملة لبيئتك |
| CISA KEV | وجود دليل على استغلال الثغرة في الواقع | لا يعني أن كل مؤسسة تستخدم المنتج معرضة بنفس الدرجة |
| PoC | وجود طريقة أو كود يوضح إمكانية الاستغلال | لا يساوي Active Exploitation |
هذا التفريق يزيل أحد أكثر الأخطاء شيوعًا عند قراءة أخبار الثغرات. وجود Exploit أو PoC منشور لا يعني تلقائيًا أن هناك حملة هجمات واسعة، وارتفاع CVSS لا يعني تلقائيًا أن CVE يجب أن تتقدم على كل شيء آخر في قائمة التصحيح.
للمبتدئ، يشرح دليل مصطلحات الأمن السيبراني الأساسية الفرق بين Vulnerability وExploit والمفاهيم المرتبطة بهما بصورة أوسع.
أفضل طريقة للتحقق من CVE خطوة بخطوة
- ابدأ من CVE.org: تحقق من المعرف والسجل والمراجع الأصلية.
- افتح NVD: راجع CVSS وCWE وCPE ومصادر الإثراء، مع الانتباه إلى حالة التحليل وتاريخ آخر تعديل.
- ابحث عن Vendor Advisory: تأكد من الإصدارات المتأثرة والإصدار المصحح أو Workaround.
- افحص CISA KEV: تحقق مما إذا كانت الثغرة معروفة بالاستغلال الفعلي.
- راجع EPSS: استخدم احتمال الاستغلال كإشارة إضافية لترتيب الأولوية.
- للمكتبات: افحص GitHub Advisory Database أو OSV لتحديد Dependency والإصدار المتأثر بدقة.
- قارن النتيجة مع أصولك: لا توجد أولوية حقيقية قبل معرفة ما إذا كان المنتج موجودًا لديك ومكشوفًا للهجوم.
مثال على ترتيب الأولويات
تخيل أن لديك ثلاث ثغرات:
- الثغرة الأولى CVSS 9.8 لكنها في نظام غير مستخدم لديك.
- الثغرة الثانية CVSS 8.1 وموجودة في CISA KEV على خادم Internet-facing لديك.
- الثغرة الثالثة CVSS 9.0 لكنها تحتاج وصولًا محليًا ولديها EPSS منخفض جدًا.
من الخطأ ترتيبها تلقائيًا حسب CVSS فقط. في هذا السيناريو، الثغرة الثانية قد تستحق الاستجابة أولًا بسبب وجود أصل متأثر ومكشوف مع دليل على الاستغلال في الواقع.
هذا هو جوهر إدارة الثغرات والتحديثات الأمنية: الانتقال من مجرد جمع CVE إلى تحديد ما يؤثر فعلًا في البيئة وترتيب المعالجة حسب الخطر الحقيقي.
أي موقع تختار حسب استخدامك؟
| الحالة | المصادر الأنسب |
|---|---|
| أريد البحث عن CVE محدد | CVE.org + NVD |
| أريد معرفة هل تُستغل حاليًا | CISA KEV |
| أريد ترتيب آلاف الثغرات | EPSS + KEV + بيانات الأصول |
| أنا مطور npm أو PyPI أو Maven | GitHub Advisory Database + OSV |
| أريد تنبيهات لمنتجات محددة | OpenCVE + Vendor Advisories |
| أريد تحديد التحديث الصحيح | النشرة الرسمية للشركة المصنعة |
| أريد فحص أجهزتي فعليًا | Vulnerability Scanner وليس قاعدة CVE فقط |
قاعدة بيانات CVE ليست أداة فحص ثغرات
من المهم أيضًا عدم الخلط بين موقع يتتبع CVE وأداة تفحص بيئتك.
NVD أو CVE.org يخبرانك بما هو معروف عن الثغرات، لكنهما لا يفحصان خوادمك لمعرفة ما إذا كانت تلك الثغرات موجودة فعلًا.
لهذا تحتاج إلى أدوات Vulnerability Scanning أو إدارة الثغرات التي تجمع جردًا للبرمجيات وتقارنه بالمعلومات الأمنية. إذا كنت تبحث عن هذا الجانب، يتناول دليل أدوات الأمن السيبراني مفتوحة المصدر مثال Vuls المخصص لاكتشاف الثغرات في الأنظمة.
لا تعتمد على مصدر واحد
أكبر خطأ في تتبع CVE هو البحث في NVD فقط، قراءة رقم CVSS، ثم اتخاذ قرار التصحيح.
سجل الثغرة يمكن أن يتغير بعد النشر، وقد تضيف الشركة المصنعة إصدارات متأثرة جديدة، أو يظهر استغلال فعلي لاحقًا، أو يرتفع EPSS بعد ظهور إشارات جديدة، أو تُضاف CVE إلى KEV بعد توفر أدلة موثوقة.
لذلك فإن عملية التتبع الجيدة ليست لقطة ثابتة، بل سلسلة:
CVE Record → Vendor Advisory → Exposure → KEV → EPSS → Patch → Verification
وبالنسبة للمؤسسات، من الأفضل تحويل هذه السلسلة إلى عملية مراقبة مستمرة بدل انتظار ظهور خبر عن ثغرة حرجة ثم البحث عنها يدويًا.
الخلاصة
لا يوجد موقع واحد يمكن وصفه بأنه أفضل مصدر لكل ما يتعلق بـCVE. CVE.org مناسب للسجل الأساسي، وNVD للإثراء والتحليل، وCISA KEV للاستغلال المؤكد في الواقع، وEPSS لاحتمال الاستغلال، بينما تخدم GitHub وOSV المطورين وسلاسل Dependencies بصورة أفضل.
وعندما تحتاج إلى اتخاذ قرار فعلي بشأن تحديث منتج، اجعل Vendor Advisory هو نقطة التحقق الأخيرة، ثم اربط كل هذه المعلومات بأصولك الفعلية. بهذه الطريقة تتحول متابعة CVE من قراءة قائمة طويلة من الثغرات إلى عملية Vulnerability Management يمكن ترتيب أولوياتها والدفاع عنها بالأدلة.