How Reliable Are NVD CWE Labels? A Large-Scale Semantic Audit with Seclometry
تقدم هذه الورقة تدقيقاً دلالياً واسع النطاق باستخدام أداة CWEAgent التي تم التحقق من صحتها للكشف عن أن ما يقرب من نصف تسميات CWE في قاعدة بيانات الثغرات الوطنية (NVD) لا تتطابق تماماً مع الدلالات البرمجية للثغرات، مما يحدد أنماط الخطأ الهيكلية ويوضح أن موثوقية التسمية تتباين بشكل كبير حسب المنظمة المسندة ونوع الضعف.
البحث الأصلي مرخَّص بموجب CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل
في العالم الرقمي، يُفترض أن كل ثغرة برمجية يمكن استغلالها من قبل طرف خبيث يتم تدوينها في مكتبة عامة ضخمة تسمى "قاعدة بيانات الثغرات الوطنية" (NVD). فكر في هذه القاعدة على أنها نظام أرشفة مركزي لمشكلات البرمجيات في العالم. عندما تُكتشف ثغرة ما، يتم منحها معرفًا فريدًا وتسميةً تصف نوع الخطأ الذي تسبب فيها. هذه التسمية أمر بالغ الأهمية لأنها تعمل كعلامة تصنيف لفرق الأمن، والباحثين، والأدوات المؤتمتة. فإذا قالت العلامة إن المشكلة هي "قفل مكسور"، يعرف فريق الأمن وجوب التحقق من ضعف المصادقة. وإذا قالت "دلو يفيض"، فإنهم يبحثون عن أخطاء في الذاكرة. لسنوات طويلة، افترض الجميع أن هذه العلامات دقيقة وموثوقة، وتعاملوا معها كحقيقة مطلقة لبناء أنظمة أمنية أفضل ولقياس مدى فعالية الأدوات الجديدة.
ومع ذلك، فإن مجرد وجود تسمية لا يعني بالضرورة أنها صحيحة. تكمن المشكلة في أن الأشخاص الذين يكتبون التقارير الأولية غالبًا ما يصفون ما حدث — أي العرض، مثل سرقة البيانات — بدلاً من السبب الجذري، مثل خطأ برمجي محدد سمح بالسرقة. قد يقول التقرير "قام مهاجم بسرقة البيانات"، مما يؤدي إلى تسمية عامة، بينما يكشف الكود الفعلي عن آلية محددة للغاية، مثل إعادة استخدام مفتاح تشفير. إذا كانت التسمية خاطئة، فإنها تضلل كل من يعتمد عليها، مما يتسبب في إغفال الأدوات للمخاطر الحقيقية أو إضاعة الوقت في إنذارات كاذبة. وحتى الآن، لم يقم أحد بفحص دقة ملايين التسميات هذه بشكل منهجي على نطاق واسع، ويرجع ذلك أساسًا إلى أن القيام بذلك يتطلب قراءة الكود الفعلي والترقيعات البرمجية لفهم الطبيعة الحقيقية للخطأ، وهي مهمة معقدة للغاية بالنسبة لعمليات التحقق المؤتمتة البسيطة.
لقد وضع فريق من الباحثين حداً لهذه المشكلة عبر بناء نوع جديد من أدوات التدقيق. فقد أنشأوا نظامًا لا يكتفي بقراءة النص الوارد في تقرير الثغرة، بل يفحص في الواقع التغييرات البرمجية التي أصلحت المشكلة. يقوم النظام بترجمة كل من الثغرة والتسميات الرسمية إلى وصف هيكلي للآليات الأساسية: ما الذي تسبب في الخطأ، وما هي القاعدة الأمنية التي تم انتهاكها، وكيف فشل الكود. ومن خلال مقارنة التسمية الرسمية بهذا الوصف المستند إلى الكود، يمكن للنظام تحديد ما إذا كانت التسمية صحيحة تمامًا، أو إذا كانت وصفًا أوسع ولكنه مقبول، أو إذا كانت ببساطة خاطئة. اختبر الباحثون هذه الأداة على مجموعة مختارة بعناية من مائة ثغرة معروفة لضمان عملها بشكل صحيح، وحققوا مستوى عالٍ من الدقة. ثم طبقوها على مجموعة ضخمة تضم أكثر من خمسة عشر ألف ثغرة من البرمجيات مفتوحة المصدر تم اكتشافها بين عامي 2017 و2026.
كشفت النتائج عن مشهد أكثر تعقيدًا من مجرد قائمة بسيطة من الإجابات الصحيحة والخاطئة. وجدت الدراسة أن ما يقرب من نصف التسميات الرسمية طابقت دليل الكود تمامًا. كما أن جزءًا كبيرًا آخر لم يكن خاطئًا من الناحية التقنية ولكنه كان غير دقيق، حيث قدم فئة أوسع ولكنها مقبولة ولكنها أقل تحديدًا مما سمح به الدليل. ومع ذلك، كانت هناك نسبة صغيرة ولكنها حرجة من التسميات — حوالي 3.6 بالمائة — تتعارض مباشرة مع الدليل، مما يعني أن التسمية وصفت نوعًا مختلفًا من نقاط الضعف عما هو موجود بالفعل في الكود. واكتشف الباحثون أن موثوقية التسمية تعتمد بشكل كبير على الجهة التي وضعتها؛ حيث قدمت بعض المؤسسات باستمرار علامات دقيقة ومحددة، بينما استخدمت مؤسسات أخرى كثيرًا تسميات فضفاضة أو غير صحيحة. والمثير للدهشة أن شدة الثغرة لم تتنبأ بدقة تسميتها؛ فالثغرات الأكثر خطورة كانت عرضة للتسمية الخاطئة بقدر الثغرات الأقل خطورة.
بمرور الوقت، تغيرت جودة هذه التسميات. وبينما ظل معدل المطابقة المثالية مستقرًا نسبيًا، فإن عدد التسميات التي تتعارض مع دليل الكود قد نما في السنوات الأخيرة، حيث ارتفع من حوالي واحد إلى ثلاثة بالمائة في السنوات الأولى من الدراسة إلى ثلاثة إلى ستة بالمائة في السنوات الأخيرة. حدد الباحثون ستة أنماط متكررة لهذه الأخطاء. وكان الخطأ الأكثر شيوعًا هو الخلط بين تبعات الثغرة وسببها، مثل تسمية ثغرة بأنها "تعرض للمعلومات" بينما كان السبب الجذري في الواقع خطأ تشفير محدد. وشملت الأخطاء المتكررة الأخرى الخلط بين أنواع فرعية متشابهة من أخطاء الذاكرة، أو الخلط بين أنواع مختلفة من هجمات الحقن. لم تكن هذه الأخطاء عشوائية، بل كانت تنبع غالبًا من الطريقة التي يُبنى بها نظام التسمية نفسه، حيث يكون تعيين الفئات العامة أسهل من الفئات المحددة، أو حيث يفتقر التقرير الأولي إلى التفاصيل التقنية اللازمة لاتخاذ الخيار الصحيح.
كما سلطت الدراسة الضوء على أن هذه الأخطاء ليست حوادث معزولة بل هي قضايا هيكلية داخل منظومة البيانات الوصفية (Metadata). فأحيانًا، يتم إضافة تسمية صحيحة من قبل المُبلغ الأصلي، ولكن تحديثًا لاحقًا من قبل مديري قواعد البيانات يُدخل تسمية متعارضة وغير صحيحة تظل مسجلة. وفي حالات أخرى، يغفل التقرير الأصلي ببساطة التفاصيل التقنية الضرورية، مما يضطر واضع التسمية إلى التخمين، مما يؤدي إلى خطأ يكون متسقًا تقنيًا مع التقرير ولكنه خاطئ بناءً على الكود. وخلص الباحثون إلى أنه بينما تعد قاعدة البيانات موردًا حيويًا، لا يمكن للمستخدمين معاملة كل تسمية كحقيقة مطلقة. وبدلاً من ذلك، يجب عليهم النظر في الجهة التي وضعت التسمية وإدراك أن جزءًا كبيرًا من البيانات يتطلب تحققًا بشريًا أو نظرة أعمق في الكود ليكون موثوقًا حقًا. ويشير العمل إلى أنه بينما يمكن للأدوات المؤتمتة المساعدة في إدارة التراكم المتزايد للثغرات، فإن الحكم النهائي على ماهية الثغرة حقًا يجب أن يظل مستندًا إلى دليل الكود نفسه.
غارق في أبحاث مجالك؟
تصلك نشرة يومية بأحدث الأبحاث المطابقة لكلماتك البحثية المفتاحية — مع ملخصات تقنية، بلغتك.