الحالة الوحيدة المتطابقة بين الطرفين، هي بالضبط تلك التي قدّم فيها البائع نفسه درجة CVSS إلى NVD.

السبب ليس أن أحدًا يخفي شيئًا عن الآخر: عندما لا يقدّم البائع تقييمًا، تقوم CISA-ADP بتسجيل درجة تلقائية بناءً على أسوأ الحالات، ومعظم أدوات SCA تأخذ الرقم الموجود على NVD. هذا ليس خطأ برمجيًا، بل هو اختلاف في منهجية نظامي التقييم — لكن إجراءات الاستجابة للطوارئ لديك تسير وفق 9.8.

الأمر الثاني: الإصدار الذي يطلب منك البائع الترقية إليه قد لا يكون قابلًا للتنزيل أصلًا

اختبار فعلي (مع مجموعة تحكم إيجابية، يُعاد تنفيذه في كل مرة يتم فيها توليد جدول القواعد):

في جدول الإصدارات المُصلَحة الرسمي، تُوسم هذه الإصدارات بـ Enterprise Support Only — أي أنها مخصصة فقط للعملاء الذين اشتروا الدعم التجاري. لذا إذا كنت مصابًا فعلًا، فخياراتك هي:الترقية عبر قفزة رئيسية في الإصدار، أو شراء الدعم التجاري.

الاستخدام

يتطلب JDK 17+. صفر اعتماديات وقت التشغيل، ولا يحتاج اتصالًا بالإنترنت.

رمز الخروج:0 الإصدار غير مصاب · 2 الإصدار مصاب لكن لم يتم العثور على شروط التفعيل · 3 شروط التفعيل محققة أيضًا.

شكل المخرجات

الجانب المعاكس — لماذا النشرات السبع الأخرى لا تختلف

قد يوحي الجدول أعلاه بأن «NVD دائمًا يقيّم بشكل عشوائي». ليس كذلك. في نفس مجموعة البيانات توجد 7 نشرات أخرى، حيث التقييم الرسمي وتقييم NVD متطابقان تمامًا:

لا توجد حالة مضادة في أي من الاتجاهين، وهذا هو الحكم السببي الوحيد الذي تجرؤ هذه الأداة على إصداره:

• 7 نشرات بتقييم متطابق ← مصدر التقييم كله هو [email protected] (تقديم البائع نفسه)
• 8 نشرات بتقييم مختلف ← مصدر التقييم كله هو CISA-ADP (البائع لم يقدّم، فقام طرف ثالث بالتسجيل التلقائي وفق أسوأ الحالات)

يستخدم سكربت التوليد تأكيدين لمراقبة هذين الاتجاهين على حدة (ASSERT4 / ASSERT7)، وفي حال ظهور أي حالة مضادة يرفض إخراج الجدول.

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

المنهجية — يرجى قراءة هذا كاملًا قبل استخلاص النتائج

• «غير مصاب» لا تعني «آمن». قد تكون شروط التفعيل موجودة في مكتبة تابعة لجهة خارجية تعتمد عليها، أو قد تُدار عبر متغيرات بيئة أو مركز إعدادات، أو ربما لم تقم بتمرير دليل الكود المصدري ببساطة. صياغة التقرير دائمًا هي «لم يتم العثور عليه في كودك المصدري»، وليست «أنت غير متأثر».
• يغطي فقط الدفعات الأربع المذكورة أعلاه، بإجمالي 15 نشرة، وليس ماسحًا شاملًا للثغرات، ولا يغني عن SCA.
• تشمل التغطية خط Spring Framework 5.3 (انتهى دعم OSS في 2024-08-31، الإصدار النهائي 5.3.39). عند تشغيل الأداة على spring-core-5.3.39.jar، ستُصاب بـ 11 نشرة، والإصدارات المُصلَحة الرسمية لهذه النشرات الـ 11 غير موجودة إطلاقًا على Maven Central العام (5.3.45 / 5.3.49 / 5.3.50، جميعها موسومة بـ Enterprise Support Only).
• يعتمد فقط على مطابقة النصوص، وليس AST. هذا اختيار مقصود:يجب أن يكون المسار الحرج قابلاً للفهم والتحقق يدويًا — فالحكم غير المفهوم إذا أخطأ لن يتمكن أحد من اكتشافه.
• اختلاف التقييمات هو قراءة موضوعية، وليس «البائع يخفي عنك شيئًا» ولا «NVD يقيّم بشكل عشوائي».

مصدر البيانات / كيفية التحقق بنفسك

يتم توليد جدول الأحكام بواسطة tools/gen_rules.py من أربعة مصادر أولية، دون نسخ يدوي:

إعادة التشغيل مرة أخرى تعني إعادة التحقق الكامل:

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

• ASSERT2 عدد النشرات غير المتطابقة بين الرسمي ⟷ NVD —— إذا وصل إلى صفر فهذا يعني أن الادعاء بطل، ويتوقف فورًا
• ASSERT3 فحص Central مع مجموعة تحكم إيجابية —— إذا فشلت المجموعة الضابطة، تُلغى كل نتائج 404 في تلك الدفعة
• ASSERT4 النشرة المتطابقة، يجب أن يكون مصدر تقييمها هو تقييم البائع الذاتي —— هذا هو الدليل الوحيد على «السبب»

License

Apache-2.0