كيف تسير الأمور فعليًا
حين تُبلّغ عن ثغرة حقيقية وقابلة للاستغلال، يفترض معظم الناس أن رقم CVE سيصدر تلقائيًا، وكأنه إيصال استلام لاكتشاف الخلل. الأمر ليس كذلك. معظم البلاغات لا تحصل على رقم CVE على الإطلاق، وخطورة الثغرة لا علاقة لها تقريبًا بسبب ذلك.
1. سؤال سريع حول رقم CVE الذي تنتظره
سؤال سريع: إذا سبق أن أبلغت شركة ما عن ثغرة حقيقية ولم تسمع شيئًا سوى أن الإصلاح صدر بعد بضعة أسابيع، هل افترضت أن سجل CVE لا بد أن يكون موجودًا في مكان ما يوثّق ذلك؟ معظم الباحثين يفعلون ذلك، على الأقل في المرة الأولى. إنه افتراض معقول، إلى أن يتضح أنه غير صحيح — لأن نسبة كبيرة من الثغرات المؤكدة والمُصلَحة والحقيقية تمامًا لم تكن مؤهلة أصلًا للحصول على رقم CVE، وقلّما يشرح أحد ذلك قبل أن ترسل رسالة "أين رقم CVE الخاص بي؟".
2. ما هي جهة CNA فعليًا من الناحية العملية
تدير مؤسسة MITRE برنامج CVE، لكن MITRE لا تتولى شخصيًا تخصيص كل رقم يصدر. فهي تشرف على شبكة موزعة من جهات ترقيم CVE، أو CNAs — وهي منظمات مخوّلة بشكل فردي لإصدار أرقام CVE، ولكن ضمن نطاق محدد فقط. قد يكون هذا النطاق خط منتجات بائع واحد، أو نظام مفتوح المصدر، أو قطاع أنظمة تحكم صناعية، أو جهة تنسيق تتولى ما لا تغطيه أي جهة أخرى. يوجد المئات من هذه الجهات، وتعمل كل واحدة منها وفق بيان نطاق منشور يحدد بدقة ما تخوَّل تغطيته، وذلك تحديدًا كي لا تنتهي جهتان اثنتان بتخصيص أرقام متعارضة لنفس الثغرة.
إذا كان البائع يدير جهة CNA خاصة به، وهو ما تفعله كثير من شركات البرمجيات الكبرى، فإن الباحث يطلب رقمًا مباشرة من تلك الجهة. أما إذا كان المنتج المتأثر خارج نطاق كل جهات CNA، فهناك خيار احتياطي: نموذج طلب CVE الخاص بـ MITRE نفسها، والمصمم خصيصًا لتغطية ما لا تغطيه أي جهة أخرى.
3. القاعدة التي لا يذكرها أحد صراحةً: الأهلية لا الخطورة
هنا يكمن الجزء الذي يفسر معظم اللبس. لكي تكون الثغرة مؤهلة للحصول على رقم CVE أصلًا، يجب عمومًا أن تكون قابلة للإصلاح بشكل مستقل، ومرتبطة بمرجع عام، وأن تؤثر على منتج محدد وقابل للتحديد يقوم العملاء فعليًا بتثبيته والتحكم به من جهتهم. تلك الجملة الأخيرة تحمل وزنًا أكبر مما تبدو عليه. أخطاء الإعداد، والقرارات التصميمية، والمشكلات التشغيلية تُرفض باستمرار، حتى عندما تكون قابلة للاستغلال فعليًا، لمجرد أنها لا تجتاز هذا المعيار. الخطورة لا تدخل النقاش إطلاقًا. الأهلية هي التي تدخل.
4. لماذا تفشل معظم ثغرات الويب وخدمات SaaS في تحقيق هذه القاعدة
هذا هو الجزء الذي يُوقع معظم الباحثين المعتادين على اكتشاف الثغرات في البرمجيات التقليدية. فنظام CVE بُني لعالمٍ يقوم فيه البائع بشحن الكود، ويقوم العميل بتثبيت نسخة معينة منه على جهازه الخاص، ويجب أن يصل التحديث إلى كل واحدة من تلك التثبيتات المنفصلة على حدة. هذا هو السبب الكامل لوجود رقم CVE أصلًا — كي يعرف كل عميل متأثر يشغّل تلك النسخة أنه بحاجة إلى تحديثها.
منصة ويب مستضافة (SaaS) لا تعمل بهذه الطريقة. يوجد نشر واحد فعّال، وتتحكم الشركة به مباشرة، وبمجرد أن تصلحه، يصبح كل مستخدم محميًا تلقائيًا. لا توجد تثبيتات منفصلة. لا تتبع لإصدارات. لا شيء يتوجب على أي طرف آخر فعله. ولأنه لا يُطلب أي إجراء من أحد سوى البائع نفسه، فإن الثغرة تقع عمومًا خارج ما يتتبعه برنامج CVE أصلًا — وهذا ليس ثغرة في النظام أو إغفالًا، بل هو مدمج مباشرة في معايير الأهلية، سواء كان الخلل في نظام تسجيل الدخول، أو في نقطة وصول API، أو في إعداد خصوصية.
5. رفض حقيقي، بنصه الكامل
هناك مثال واقعي مفيد جدًا على ذلك. طلب قُدّم بخصوص عناوين أمان مفقودة وضعف في التعامل مع ملفات تعريف ارتباط الجلسة على منصة SaaS، ورُفض رسميًا، وكان السبب المُعلن من جهة CNA أنه يصف ثغرة في منتج SaaS لا تتطلب أي إجراء من المستخدمين. هذه الجملة الواحدة تلخّص القاعدة أفضل من معظم الشروحات. الخطورة لم تكن القضية أبدًا. انطباق المعايير على منتج قابل للتحكم والإصدار هو ما كان القضية.
6. أين تقف الأمور، وما الذي يمكنك فعله فعليًا
حتى عندما تتم الموافقة على رقم CVE، فإنه لا يظهر للعلن فور منحه. تمر الأرقام بعدة حالات متمايزة: "محجوز"، حيث تكون جهة CNA قد حجزت الرقم دون نشر التفاصيل بعد؛ و"محجوز لكن عام"، حيث يظهر الرقم داخل نشرة استشارية قبل وجود السجل الكامل؛ و"مُكتمَل"، بمجرد أن تُنشر بيانات الثغرة الفعلية. قد يبقى السجل أيضًا في حالة "متنازع عليه"، إذا اختلفت جهة CNA مع الباحث حول الأهلية، أو يُرفض تمامًا كما في المثال أعلاه.
إذا كنت أنت من اكتشف الثغرة ولم يظهر أي رقم CVE، فهذا غالبًا ليس علامة على أن بلاغك جرى تجاهله أو اعتباره غير مهم. بضعة أمور تساعد فعليًا هنا:
- ابحث عن نشرة استشارية أمنية، أو سجل تحديثات، أو مكافأة برنامج اكتشاف الثغرات (bug bounty) بدلًا من ذلك — فالإقرار على المنصات المستضافة يظهر عادة هناك، لا كرقم CVE.
- اسأل البائع مباشرة عمّا إذا كان المنتج يقع أصلًا ضمن نطاق أي جهة CNA قبل افتراض أن البلاغ ذهب سدى.
- بالنسبة لأي حالة تقع فعليًا خارج نطاق كل جهات CNA، يوجد نموذج طلب CVE الخاص بـ MITRE نفسها مخصص لسد هذه الفجوة تحديدًا — يستحق التجربة قبل الاستسلام.
- احتفظ ببلاغك موثقًا ومؤرخًا بغض النظر عن النتيجة. الإسناد إلى مكتشف الثغرة لا يحتاج إلى وجود رقم CVE ليكون ذا قيمة.
لا شيء من هذا يعني أن الثغرة لم تكن حقيقية، أو أن الإبلاغ عنها كان بلا جدوى. إنه يعني فقط أن نظام التعريف الذي بُني لعالم البرمجيات المعبأة على ملايين الأجهزة المنفصلة لم يكن ليخصص مكانًا لخلل تم إصلاحه مرة واحدة، مركزيًا، قبل أن يضطر أي أحد في الطرف الآخر لتحريك إصبعه.
اكتشف المزيد من محتوى التوعية والأمان
اكتشف المزيد من نصائح الأمان وتحليل التهديدات والتوعية بالاختراقات والأدلة العملية المصممة لمساعدتك على البقاء آمنًا على الإنترنت.
تصفح قسم التوعية والأمان →