الثغرات والتعرضات الشائعة

تصغير|الشعار
**نظام نقاط الضعف والتعرضات الشائعة ( [[اللغة الإنجليزية|بالإنجليزية]] :CVE)**، والذي كان يُعرف سابقًا باسم "تعداد نقاط الضعف الشائعة" ، يوفر آلية مرجعية موحدة لتحديد وتتبع نقاط الضعف والتعرضات الأمنية التي تم الكشف عنها بشكل علني . يتولى معهد هندسة وتطوير أنظمة الأمن الداخلي (FFRDC)، وهو مركز أبحاث وتطوير ممول اتحاديًا تديره مؤسسة MITRE Corporation، مسؤولية صيانة هذا النظام. يتم تمويل المشروع من قبل القسم الوطني للأمن السيبراني التابع لوزارة الأمن الداخلي الأمريكية. وقد تم الإطلاق الرسمي لنظام CVE للجمهور في شهر سبتمبر من عام 1999.

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

يعتمد بروتوكول أتمتة محتوى الأمان (SCAP) على نظام CVE، حيث يتم إدراج مُعرّفات CVE في نظام MITRE، بالإضافة إلى كونها الأساس الذي تقوم عليه قاعدة بيانات الثغرات الوطنية الأمريكية (NVD) .

## معرفات CVE
تُعرّف وثائق مؤسسة MITRE Corporation مُعرّفات CVE (والتي يُشار إليها أيضًا باسم "**أسماء CVE**" و "**أرقام CVE**" و "**معرفات CVE**" أو ببساطة "**CVE**") بأنها مُعرّفات فريدة ومشتركة لنقاط الضعف الأمنية المعروفة علنًا في حزم البرامج التي تم إصدارها للعموم. تاريخيًا، كانت مُعرّفات CVE تبدأ بحالة "**مرشح**" (يُشار إليها بالبادئة "CAN-") ثم يمكن ترقيتها لاحقًا إلى "**إدخالات**" (يُشار إليها بالبادئة "CVE-")، إلا أن هذه الممارسة تم إيقافها في عام 2005. ويتم الآن تعيين جميع المعرفات كـ CVEs. إن تعيين رقم CVE لا يعد ضمانًا بأنه سيصبح إدخال CVE رسميًا (على سبيل المثال، قد يتم تعيين CVE بشكل غير صحيح لمشكلة ليست ثغرة أمنية، أو تكرر إدخالًا موجودًا). إذا تبين أن الإدخال لا يلبي المعايير، فيمكن لـ MITRE أو هيئة ترقيم CVE (CNA) وضع الإدخال في حالة مرفوضة بشكل موجز.

يتم تخصيص مُعرّفات CVE بواسطة **هيئة ترقيم CVE (CNA)** [1]. وفي حين أن بعض البائعين كانوا يعملون بشكل غير رسمي كمساعدين في الترقيم قبل ذلك، إلا أن الاسم الرسمي "CNA" والتسمية الموحدة لم يتم إنشاؤهما حتى الأول من فبراير عام 2005. هناك أربعة أنواع أساسية من تعيينات أرقام CVE:

# تعمل شركة MITRE Corporation كمحرر ومساعد تمريض رئيسي
# يقوم العديد من مساعدي التمريض المعتمدين بتعيين أرقام CVE لمنتجاتهم الخاصة (على سبيل المثال، Microsoft، Oracle، HP، Red Hat)
# قد يقوم منسق تابع لجهة خارجية مثل مركز تنسيق CERT بتعيين أرقام CVE للمنتجات غير المغطاة بواسطة CNAs الأخرى
# في إحدى الحالات، تم منح الباحثين دور مساعد التمريض المعتمد (CNA).

عند التحقيق في ثغرة أمنية محتملة أو مؤكدة، يُعد الحصول على مُعرّف CVE في مرحلة مبكرة أمرًا مفيدًا. قد لا تظهر مُعرّفات CVE على الفور في قواعد بيانات MITRE أو NVD (قد يستغرق ذلك أيامًا أو أسابيع أو أشهر أو حتى سنوات) بسبب وجود مشكلات محظورة (حيث تم تخصيص رقم CVE ولكن لم يتم الإعلان عن الثغرة بعد)، أو تاريخيًا في الحالات التي لم يتم فيها البحث عن الإدخال وكتابته بواسطة MITRE بسبب قيود الموارد. تكمن فائدة الحصول على ترشيح CVE مبكرًا في إمكانية استخدام هذا الرقم الموحد في جميع المراسلات والتنسيقات المستقبلية، مما يضمن إشارة جميع الأطراف المعنية إلى نفس الثغرة الأمنية تحديدًا. تتوفر معلومات حول الحصول على معرفات CVE للمشكلات المتعلقة بمشاريع المصدر المفتوح من Red Hat  و GitHub .

تُخصص مُعرّفات CVE للبرامج التي تم إصدارها للجمهور بشكل عام؛ وقد يشمل ذلك الإصدارات التجريبية والإصدارات التي تسبق الإصدار النهائي إذا كانت قيد الاستخدام على نطاق واسع. تُعتبر البرامج التجارية ضمن فئة "الإصدار العام"، ولكن البرامج المصممة خصيصًا والتي لا يتم توزيعها على نطاق واسع لم يتم تخصيص مُعرّفات CVE لها تاريخيًا. خلال العقدين الأولين من عمر البرنامج، لم تكن الخدمات (مثل مزودي البريد الإلكتروني المستند إلى الويب) تُمنح مُعرّفات CVE للثغرات الأمنية الموجودة في الخدمة نفسها (مثل ثغرات XSS)، إلا إذا كانت المشكلة متضمنة في منتج برمجي أساسي يتم توزيعه بشكل علني. لم يتم نشر قواعد رسمية بخصوص هذا التغيير، ولكن بدأت بعض هيئات ترقيم الثغرات الأمنية (CNAs)، بما في ذلك MITRE، في تخصيص مُعرّفات CVE للثغرات الأمنية القائمة على الخدمات منذ عام 2020.

## حقول بيانات CVE
تحتوي قاعدة بيانات CVE على عدة حقول:

### وصف
يُقدم مُعرّف CVE وصفًا نصيًا موحدًا للمشكلة الأمنية (أو المشكلات). ومن بين المدخلات الشائعة لهذا النظام:**محجوز** **:** يشير هذا التصنيف إلى أن مُعرّف CVE هذا قد تم حجزه بالفعل من قبل منظمة أو فرد، وسيتم استخدامه عند الكشف عن ثغرة أمنية جديدة. وعند الإعلان عن هذه الثغرة، سيتم توفير التفاصيل والمعلومات المتعلقة بهذا المُعرّف المحجوز.هذا يعني أن رقم الإدخال المحدد قد تم حجزه إما بواسطة مؤسسة MITRE تمهيدًا لإصدار محتمل، أو أن إحدى هيئات ترقيم الثغرات الأمنية (CNA) قامت بحجز هذا الرقم لاستخدامه لاحقًا. فعلى سبيل المثال، عندما تطلب CNA مجموعة من أرقام CVE بشكل مسبق (كما هو الحال مع شركة Red Hat التي تطلب حاليًا أرقام CVE في مجموعات تضم 500 رقم)، سيتم وضع علامة "محجوز" على رقم CVE حتى لو لم تقم CNA نفسها بتعيين هذا الرقم لثغرة معينة لفترة من الوقت. ولا يتم تحديث حالة CVE وإعلام MITRE بها (أي، يتم رفع الحظر وتصبح المشكلة علنية) إلا بعد أن يتم تعيين CVE فعليًا. ويقوم Mitre بالبحث عن المشكلة وكتابة وصف لها، ستظهر الإدخالات على أنها "** محجوزة **".

### تاريخ إنشاء السجل
**تاريخ الإنشاء (Date Entry Created):** يشير هذا الحقل إلى التاريخ الذي تم فيه إنشاء سجل CVE. بالنسبة لمُعرّفات CVE التي تم تخصيصها مباشرةً من قِبل مؤسسة MITRE، يمثل هذا التاريخ اللحظة التي أنشأت فيها MITRE سجل CVE. أما بالنسبة لمُعرّفات CVE التي تم تخصيصها من قِبل هيئات ترقيم الثغرات الأمنية (CNAs) مثل Microsoft أو Oracle أو HP أو Red Hat، فإن هذا التاريخ يظل هو تاريخ الإنشاء بواسطة MITRE، وليس بواسطة CNA نفسها. وعندما تطلب CNA مجموعة من أرقام CVE بشكل مسبق (كما هو الحال مع شركة Red Hat التي تطلب حاليًا أرقام CVE في مجموعات تضم 500 رقم)، يتم تعيين تاريخ الإنشاء في السجل بتاريخ تخصيص هذه المجموعة من الأرقام لـ CNA.

### الحقول القديمة
في الماضي، كانت سجلات CVE تتضمن بعض الحقول التي لم تعد قيد الاستخدام حاليًا:

* المرحلة: المرحلة التي يوجد فيها CVE (على سبيل المثال، CAN، CVE).
* الأصوات: في السابق كان أعضاء مجلس الإدارة يصوتون بنعم أو لا على ما إذا كان ينبغي قبول CAN وتحويله إلى CVE أم لا.
* التعليقات: تعليقات على الموضوع.
* المقترح: عندما تم اقتراح القضية لأول مرة.

## تغييرات في بناء الجملة
بهدف دعم مُعرّفات CVE التي تتجاوز التنسيق CVE-YEAR-9999 (وهي مشكلة يُشار إليها باسم "**مشكلة CVE10k**" [1])،... )، تم إجراء تغيير على بناء جملة CVE في عام 2014 ودخل حيز التنفيذ في 13 يناير 2015.

صيغة CVE-ID الجديدة ذات طول متغير وتتضمن:

بادئة CVE + السنة + أرقام عشوائية

... تم اعتماد نظام ترقيم جديد يعتمد على أرقام تعسفية ذات طول متغير. يبدأ هذا النظام بأربعة أرقام ثابتة للسنة التقويمية (YYYY)، ثم يتبعها عدد من الأرقام التعسفية (N) يتوسع فقط عند الحاجة خلال نفس السنة التقويمية. على سبيل المثال، يبدأ الترقيم بـ CVE-YYYY-NNNN، وإذا استدعت الحاجة، يتم التوسع إلى CVE-YYYY-NNNNN، ثم CVE-YYYY-NNNNNN، وهكذا. يُذكر أن هذا المخطط الجديد متوافق تمامًا مع مُعرّفات CVE التي تم تخصيصها سابقًا، والتي تتضمن جميعها على الأقل أربعة أرقام بعد السنة.

## تقسيم ودمج CVE
يهدف نظام CVE إلى تخصيص مُعرّف CVE فريد لكل ثغرة أمنية. ومع ذلك، في العديد من الحالات، قد يؤدي هذا النهج إلى عدد كبير جدًا من مُعرّفات CVE. على سبيل المثال، عندما يتم اكتشاف عشرات الثغرات الأمنية من نوع البرمجة النصية عبر المواقع (XSS) في تطبيق PHP نتيجة لعدم استخدام الدالة `htmlspecialchars()` بشكل صحيح، أو عند إنشاء ملفات غير آمنة في الدليل `/tmp`. في مثل هذه السيناريوهات، قد يكون تخصيص مُعرّف CVE منفصل لكل instance من هذه المشكلات غير عملي أو مفرطًا.

ولمعالجة هذه الحالات، تتضمن الإرشادات (التي تخضع للتغيير) مبادئ لتجميع المشكلات وتقسيمها ضمن مُعرّفات CVE مميزة. كقاعدة عامة، يجب أولاً تقييم المشكلات لتحديد ما إذا كان ينبغي دمجها ضمن مُعرّف CVE واحد. بعد ذلك، ينبغي تقسيم المشكلات بناءً على نوع الثغرة الأمنية (على سبيل المثال، تجاوز سعة المخزن المؤقت مقابل تجاوز سعة المكدس )، ثم حسب إصدار البرنامج المتأثر (على سبيل المثال، إذا أثرت مشكلة واحدة على الإصدار 1.3.4 حتى 2.5.4 وأثرت الأخرى على الإصدارات 1.3.4 حتى 2.5.8 فسيتم تقسيمهما) ثم حسب مُبلغ المشكلة (على سبيل المثال، إذا أبلغت أليس عن مشكلة واحدة وأبلغ بوب عن مشكلة أخرى، فسيتم تقسيم المشكلات إلى أرقام CVE منفصلة).

مثال آخر يوضح هذا المفهوم هو قيام Alice بالإبلاغ عن ثغرة أمنية تتعلق بإنشاء ملف في الدليل `/tmp` في الإصدار 1.2.3 والإصدارات الأقدم من متصفح الويب ExampleSoft. بالإضافة إلى هذه المشكلة المحددة، تم اكتشاف العديد من المشكلات الأخرى المتعلقة بإنشاء ملفات في نفس الدليل `/tmp`. في مثل هذه الحالات، قد يُنظر إلى هذه التقارير على أنها واردة من مصدرين مختلفين (Alice كمبلغ خارجي وفريق ExampleSoft داخليًا)، وبالتالي قد يتم تخصيص مُعرّفين CVE منفصلين لهما. أما إذا كانت Alice تعمل لدى ExampleSoft وقام فريق داخلي آخر في الشركة باكتشاف بقية المشكلات، فمن المرجح أن يتم تجميع جميع هذه الثغرات تحت مُعرّف CVE واحد. وعلى العكس من ذلك، يمكن دمج المشكلات، مثل إذا وجد Bob 145 ثغرة XSS في ExamplePlugin لـ ExampleFrameWork بغض النظر عن الإصدارات المتأثرة وما إلى ذلك، فقد يتم دمجها في CVE واحد.

## البحث عن معرفات CVE
يمكن إجراء بحث في قاعدة بيانات MITRE CVE عبر صفحة قائمة البحث CVE. وبالمثل، تتوفر إمكانية البحث في قاعدة بيانات NVD CVE من خلال صفحة قاعدة بيانات البحث عن ثغرات قائمة البحث CVE وCCE.

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

## مشاكل تعيين CVE
وفقًا للبند السابع من لوائح هيئات ترقيم الثغرات الأمنية (CNAs)، يتمتع البائع الذي يتلقى بلاغًا عن ثغرة أمنية بسلطة تقديرية مطلقة فيما يتعلق بالتعامل مع تلك الثغرة. يمكن أن ينشأ عن هذا الوضع تضارب في المصالح، حيث قد يسعى البائع إلى إهمال تصحيح الثغرات الأمنية عن طريق رفض تعيين مُعرّف CVE لها في المقام الأول – وهو قرار لا تملك مؤسسة MITRE سلطة نقضه. ويهدف مشروع "!CVE" (يُلفظ "نوت CVE")،... الذي تم الإعلان عنه في عام 2023، إلى جمع الثغرات الأمنية التي يرفضها البائعون، طالما تم اعتبارها صالحة من قبل لجنة من الخبراء من المشروع.

في بعض الحالات، تم تخصيص مُعرّفات CVE لمشكلات وهمية أو لمشكلات لا ينتج عنها تبعات أمنية فعلية. ردًا على ذلك، تقدم عدد من المشاريع مفتوحة المصدر بطلب لتصبح هيئة ترقيم CVE (CNA) لمشروعها الخاص.

## قضايا التمويل لعام 2025
في الخامس عشر من أبريل عام 2025، أشارت التقارير إلى قرب انتهاء العقد المبرم بين مؤسسة MITRE وحكومة الولايات المتحدة الأمريكية، والذي كان من المقرر له الانتهاء في اليوم التالي. وذكرت هذه التقارير أن انتهاء هذا العقد كان من شأنه أن يؤدي إلى توقف الذراع التشغيلية لبرنامج CVE. سينتهي. ذكرت التقارير أن انتهاء العقد من شأنه أن يضع نهاية للذراع التشغيلية لبرنامج CVE، بما في ذلك تعيين CVEs جديدة، في حين ستظل قاعدة البيانات قابلة للوصول عبر GitHub .

قبل وقت قصير من انتهاء صلاحية العقد الأصلي، تم تمديده لمدة أحد عشر شهرًا إضافيًا، وهو ما حال دون توقف البرنامج .

## انظر أيضا

* نظام تسجيل نقاط الضعف المشتركة (CVSS)
* أمن الكمبيوتر
* قاعدة بيانات الضعف الأوروبية

## مراجع

## روابط خارجية

* 
* National Vulnerability Database (NVD)
* Common Configuration Enumeration (CCE) at NVD
* vFeed the Correlated and Aggregated Vulnerability Database - SQLite Database and Python API
* Cyberwatch Vulnerabilities Database , third party
* What Enterprises need to know about IT Security Audit Services?

تصنيف:استغلالات أمن الحاسوب