وصفة عملية لمشروعات المصادر المفتوحة للتعامل مع بلاغات الثغرات

نشرت CNCF في 7 سبتمبر 2026 بطاقة إرشادية بعنوان «التعامل مع بلاغات الثغرات» (Handling vulnerability reports: Recipe card)، تستهدف مشروعات المصادر المفتوحة الصغيرة والمتوسطة التي لا تركز أساساً على الأمن. أعد المادة Marina Moore من Edera، وهي الرئيسة المشاركة لـTAG Security، وSherine Khoury من Red Hat، وهي قائدة TAG Security.

الفكرة الأساسية في الدليل هي تقليل العمل الإضافي على المشرفين والمستخدمين، مع منع تحول البلاغ الأمني إلى نقاش عام قبل أن يصبح الإصلاح جاهزاً. وتوضح CNCF أن الثغرة الأمنية هي خلل يمكن استغلاله للتأثير في سرية النظام أو سلامته أو توافره، لكن ليس كل خلل برمجياً قابلاً للاستغلال أو مصنفاً كثغرة.

ابدأ بقناة إبلاغ واضحة وخاصة

توصي الإرشادات بأن يتضمن ملف README.md قسماً أمنياً واضحاً يسهل العثور عليه، مع وضع التعليمات مباشرة في الملف أو الإحالة إلى ملف SECURITY.md في جذر المستودع. الهدف هو توجيه الباحثين إلى مسار خاص بدلاً من نشر تفاصيل المشكلة في issue عام يمكن للجميع قراءته.

وينبغي أن توضح تعليمات الإبلاغ عدة عناصر، من بينها نموذج التهديد أو الحد الأدنى المقبول لاعتبار البلاغ ثغرة، ومكان الإرسال، وصيغة البلاغ، والمدة المتوقعة قبل مراجعته، والمدة التقريبية حتى الإفصاح عنه. ويمكن استخدام آلية الإبلاغ الخاص بالثغرات في GitHub أو قائمة بريدية خاصة. أما برنامج المكافآت فليس إلزامياً للمشروعات الصغيرة والمتوسطة إذا لم تكن لديها القدرة على تشغيله.

تحقق من طبيعة البلاغ قبل التعامل معه كثغرة

بعد وصول البلاغ، ينبغي أولاً تحديد ما إذا كان يشير فعلاً إلى ثغرة قابلة للاستغلال، أم إلى خلل غير قابل للاستغلال، أو سوء فهم للسلوك المتوقع، أو خطأ في التوثيق. تقترح CNCF مناقشة البلاغ مع صاحبه ومع الخبراء المناسبين في المشروع، مع إبقاء عدد المشاركين محدوداً والتزام الجميع بالسرية إلى أن يصبح البلاغ عاماً.

ومن الأسئلة العملية التي يمكن طرحها: هل توجد آلية تخفيف متاحة للمستخدمين؟ وهل يمكن أن يؤدي الخلل إلى اختراق أو تسريب بيانات أو نشاط ضار آخر؟ وهل المشكلة في التوثيق فقط؟ وإذا تبين أن البلاغ ليس ثغرة، يمكن توجيه صاحبه إلى إنشاء issue عام، مع استخدام إجراءات النشر المناسبة لإبلاغ المستخدمين عند الحاجة.

وفي حال عدم اليقين، تشير الإرشادات إلى إمكانية طلب التوجيه من TAG Security and Compliance أو موظفي CNCF، مع إبقاء تفاصيل البلاغ خارج القنوات العامة. كما ينبغي اختيار المشاركين في فترة الحظر السري بعناية، وإشراك من يحتاجون فعلاً إلى المساعدة في الحل فقط، حتى لا تتسرب المعلومة إلى مهاجمين قبل توفير التصحيح.

طوّر الإصلاح واختبره بعيداً عن العلن

تحذر CNCF من أن نشر التصحيح أو مناقشته في pull request عام قد يكشف طبيعة الثغرة قبل أن تتاح للمستخدمين فرصة التحديث. وإذا استُخدمت آلية الإبلاغ الخاص في GitHub، يمكن إنشاء فرع خاص انطلاقاً من البلاغ. وفي غير ذلك يمكن تطوير التصحيح ومراجعته عبر قناة خاصة.

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

نسّق الإصدار مع الإفصاح عن CVE

بعد اكتمال التصحيح، تعتبر CNCF أن الإفصاح عنه خلال 90 يوماً من استلام البلاغ ممارسة شائعة. ويمكن للمشروع، إذا كانت موارده تسمح، إبلاغ قائمة خاصة من المستخدمين مسبقاً، لكن الحفاظ على قائمة جهات اتصال محدثة يمثل عبئاً لا تستطيع معظم المشروعات الصغيرة تحمله.

لذلك تقترح البطاقة نهجاً أبسط: إتاحة الإصدار الذي يتضمن التصحيح والإعلان عن الثغرة في الوقت نفسه، حتى يحصل المستخدمون على الإصلاح عند إعلان المشكلة. ويتطلب ذلك بناء إصدار جديد فور إدخال التصحيح، ثم نشر CVE. وإذا استُخدمت آلية GitHub الخاصة، يمكن تنفيذ ذلك من واجهة GitHub.

يجب أن يخصص رقم CVE من جهة CNA، أي سلطة ترقيم CVE، وتُعد GitHub إحدى هذه السلطات ويمكنها تنفيذ العملية، كما يستطيع المشروع والباحث التواصل مباشرة مع إحدى سلطات CNA المدرجة. أما درجة خطورة CVE فتُحدد عبر مجموعة من الأسئلة، وينبغي أن يعمل المشروع مع الباحث للتأكد من دقة الإجابات والاتفاق على الدرجة المسندة.

لماذا تهم هذه الإرشادات؟

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

لكن نطاق الوصفة محدود بوضوح؛ فهي موجهة إلى المشروعات الصغيرة والمتوسطة غير المتخصصة في الأمن، وليست بديلاً عن برنامج أكثر تعقيداً للمشروعات عالية المخاطر أو الحساسة أمنياً. كما تقترح CNCF التفكير في نشر إثبات المفهوم بعد مرور وقت على إتاحة الإصلاح، لمنح المستخدمين فرصة إضافية للتحديث، مع الإقرار بأن تنفيذ ذلك قد يكون صعباً عند استخدام الإبلاغ الخاص.