وتيرة التصحيح لدى المورّد، أي السرعة التي يحدد بها مورّد البرمجيات الثغرات المعروفة في برمجياته ويطور تصحيحاتها ويصدرها، هي من أهم أبعاد أمن سلسلة توريد البرمجيات وأقلها خضوعًا للتقييم الدقيق. فاستبيانات TPRM تطلب من المورّدين بشكل روتيني ذكر اتفاقيات مستوى الخدمة للتصحيح لديهم: مدى السرعة التي يلتزمون بها بتصحيح الثغرات الحرجة والعالية والمتوسطة والمنخفضة الخطورة. ويقدم المورّدون بشكل روتيني إجابات على مستوى السياسة تصف التزامهم الطموح أو المعلن. أما ما نادرًا ما يُقيَّم فهو ما إذا كان ذلك الالتزام المعلن يتحقق فعلًا: هل يتوافق متوسط المدة من نشر الثغرة حتى إصدار التصحيح مع السياسة، وهل تُصحح جميع الثغرات الحرجة في نهاية المطاف.
فجوة السياسة مقابل الالتزام هي المشكلة الجوهرية. فالمورّد الذي يعلن SLA لتصحيح الثغرات الحرجة خلال 30 يومًا ويحقق متوسط 73 يومًا لا يفي بسياسته المعلنة، لكن ذلك لن يظهر في استبيان يسأل عن السياسة بدلًا من قياس الالتزام. ويتطلب القياس النظر في سجل الإصدارات الفعلي للمورّد ومقارنته بالجداول الزمنية المنشورة لـCVE: متى نُشرت الثغرة، ومتى أصبح التصحيح متاحًا، وهل هذا متسق عبر مجموعة الثغرات المنشورة؟ ويمكن إجراء هذا التحليل باستخدام بيانات عامة، مثل تواريخ نشر NVD وملاحظات إصدار المورّد وتتبع CVE، لكنه يتطلب جهدًا لا يتطلبه الاستبيان القياسي.
تمثل مشكلة الثغرات غير المصححة التعرض المحدد في TPRM. فالثغرات الحرجة التي لا تُصحح أبدًا تمثل خطرًا دائمًا على كل مؤسسة تشغّل إصدار البرمجيات المتأثر. وسياسة المورّد للتصحيح خلال 30 يومًا لا تعالج الثغرات التي لا تُصحح إطلاقًا، فهي لا تصف إلا الجدول الزمني المقصود للتصحيحات التي تُنتج. فأربع من الثغرات الحرجة الأربع عشرة لدى المورّد خلال العام الماضي ما زالت دون تصحيح بعد انقضاء نافذة 30 يومًا المعلنة. وبالنسبة للمؤسسات التي تشغّل إصدارات البرمجيات تلك، فإن الثغرة ليست خطرًا لمدة 30 يومًا أو 73 يومًا، بل خطر مستمر دون أي معالجة مجدولة.
لماذا يهم هذا
تكتسب حقيقة وتيرة التصحيحات أهمية لأن البرمجيات التي تنشرها مؤسستك تستمر في مراكمة مخاطر الثغرات بين تقييمك الأولي والمراجعة المخطط لها التالية للمورّد. فالمورّد الذي يصحح ببطء أو بشكل منقوص هو مورّد تصبح برمجياته أكثر عرضة للثغرات تدريجيًا مع مرور الوقت. والمؤسسة التي أكدت سياسة المورّد للتصحيح خلال 30 يومًا دون قياس الالتزام بها تشغّل برمجيات أكثر عرضة للثغرات بكثير مما يوحي به تأكيد السياسة.
- تأكيد سياسة التصحيح دون قياس الالتزام بها
- عدم حساب متوسط مدة التصحيح من بيانات الإصدارات التاريخية وCVE
- عدم تحديد الثغرات غير المصححة، إذ تسأل السياسة عن SLA لا عن مدى التغطية
- غياب المراقبة المستمرة للتصحيحات، والاكتفاء بتأكيد السياسة في نقطة زمنية واحدة
- عدم تتبع حداثة إصدار البرمجيات المنشور مقارنة بأحدث إصدار مصحح
كيف تبدو الممارسة الجيدة
تقيس برامج وتيرة التصحيحات الناضجة لدى المورّدين الالتزام الفعلي بالتصحيح من البيانات التاريخية، فتحسب متوسط المدة من نشر CVE حتى إصدار التصحيح لبرمجيات المورّد، وتحدد الثغرات غير المصححة، وتتابع مدى حداثة الإصدار المنشور لدى المؤسسة مقارنة بأحدث إصدار مصحح.
- تحليل الالتزام التاريخي بالتصحيح، الجدول الزمني لنشر CVE مقارنة بإصدار التصحيح
- تحديد الثغرات غير المصححة، أي ثغرات CVE في برمجيات لا يوجد لها تصحيح
- تتبع حداثة الإصدار المنشور، الإصدار الحالي مقارنة بأحدث إصدار مصحح
- المراقبة المستمرة للتصحيحات، أي مراقبة CVE للبرمجيات المنشورة
- مقياس الالتزام بـSLA التصحيح، السياسة مقارنة بالواقع الفعلي في تقييمات المورّدين
الأدوات
مراقبة التصحيحات، Vulncheck وRecorded Future لتحليل نشر CVE والجداول الزمنية للتصحيح، وSnyk للمراقبة المستمرة للبرمجيات المنشورة
توفر منصات معلومات الثغرات الجداول الزمنية لنشر CVE وتتبع إصدار التصحيحات لدى المورّدين، مما يتيح حساب الالتزام بوتيرة التصحيح من البيانات العامة. وبالنسبة لممارسي TPRM، فإن حساب متوسط المدة من نشر CVE حتى إصدار المورّد للتصحيح لمنتج برمجي خلال الأشهر الاثني عشر الماضية هو قياس محدد وموضوعي لوتيرة التصحيح لا يمكن لبيانات السياسة أن تحل محله.
تحديات الحوكمة
يتمثل تحدي الحوكمة في تقييم وتيرة التصحيح في جهد جمع البيانات. فحساب الالتزام الفعلي بالتصحيح من بيانات CVE والإصدارات يتطلب البحث عن تواريخ النشر التاريخية لـCVE، والعثور على ملاحظات إصدار المورّد التي تعالج كل CVE، وحساب الفارق. وهذا ممكن لثغرات CVE الحرجة لكنه كثيف الجهد في التحليل الشامل. والحل من منظور الحوكمة هو إعطاء الأولوية لتحليل الالتزام الفعلي بالتصحيح لدى مورّدي البرمجيات الحرجين، واستخدام المراقبة المؤتمتة للثغرات لتغطية البرمجيات المنشورة بشكل مستمر.
- احسب الالتزام الفعلي بالتصحيح لدى مورّدي البرمجيات الحرجين، لا السياسة فقط
- حدد ثغرات CVE الحرجة غير المصححة في البرمجيات المنشورة
- تتبّع حداثة الإصدار المنشور، النشر الحالي مقارنة بأحدث إصدار مصحح
- طبّق مراقبة مستمرة لـCVE للبرمجيات المنشورة
- أدرج بيانات الالتزام بالتصحيح في إعادة تقييم المورّد إلى جانب السياسة
إذا كنت فريقًا صغيرًا
لأهم ثلاثة مورّدي برمجيات حرجين لديك، ابحث عن ثغرات CVE المنشورة لبرمجياتهم خلال الأشهر الاثني عشر الماضية وتواريخ إصدار التصحيحات التي عالجتها. احسب متوسط المدة بين نشر CVE وإتاحة التصحيح. ثم تحقق مما إذا كانت هناك أي ثغرات CVE حرجة لم تُصحح في إصدار صادر. سيخبرك هذا التحليل، باستخدام NVD وMITRE CVE وملاحظات إصدار المورّد، ما إذا كانت SLA التصحيح خلال 30 يومًا وصفًا للممارسة أم مجرد تعبير عن طموح.
- ابحث عن ثغرات CVE لدى أهم ثلاثة مورّدي برمجيات خلال آخر 12 شهرًا
- احسب متوسط المدة من نشر CVE حتى إصدار التصحيح
- حدد ثغرات CVE الحرجة غير المصححة
- تتبّع حداثة الإصدار المنشور مقارنة بأحدث إصدار مصحح
ما الذي ينبغي اشتراطه
اسأل مباشرةً:
«ما متوسط المدة لديكم من نشر CVE حرجة حتى إصدار التصحيح خلال الأشهر الاثني عشر الماضية، وهل توجد أي ثغرات CVE حرجة نُشرت خلال الأشهر الاثني عشر الماضية لبرمجياتكم ولم تُعالج بعد في تصحيح صادر؟»
ما تتوقعه دليلًا
- بيانات الجدول الزمني التاريخي للتصحيحات، نشر CVE مقارنة بإصدار التصحيح
- قائمة ثغرات CVE الحرجة غير المصححة مع الجدول الزمني لمعالجتها
- متوسط وتيرة التصحيح حسب درجة الخطورة
- تأكيد حداثة التصحيح للإصدار المنشور
المورّد الذي يؤكد SLA للتصحيح خلال 30 يومًا يجب أن يُطلب منه تقديم بيانات التزامه الفعلي بالتصحيح. فالسياسة تصف الالتزام المعلن. والبيانات التاريخية تصف الأداء. وكلاهما لازم لتقييم المخاطر الفعلية لتشغيل برمجيات ذلك المورّد.
كيف تُثبت ذلك
- سجلات تحليل الالتزام التاريخي بالتصحيح
- تتبع CVE غير المصححة
- مراقبة حداثة الإصدار المنشور
- الالتزام بـSLA التصحيح في تقييم المورّدين
الخلاصة الرئيسية
SLA التصحيح خلال 30 يومًا: مؤكدة. متوسط مدة التصحيح الفعلية: 73 يومًا. ثغرات CVE الحرجة غير المصححة: 4 من 14. كانت السياسة حقيقية. أما الالتزام بها فلم يكن كذلك. سأل الاستبيان عن السياسة. وكشفت بيانات الجدول الزمني للتصحيحات فجوة الالتزام. يصف تأكيد السياسة ما ينوي المورّد فعله. وتصف بيانات الالتزام التاريخية ما يقدمه فعلًا. وفي مخاطر سلسلة توريد البرمجيات، فإن ما يقدمه المورّد فعلًا هو ما يحدد التعرض الفعلي للثغرات لدى المؤسسة التي تشغّل برمجياته، لا ما ينوي تقديمه.