Characterizing and Modeling the GitHub Security Advisories Review Pipeline
تقدم هذه الورقة دراسة تجريبية واسعة النطاق لمسار مراجعة تنبيهات أمن GitHub (GHSA)، حيث تُصنف أنماط المراجعة والتأخير عبر 288,000 تنبيه لتحديد أنظمة معالجة متميزة سريعة وبطيئة، وتقترح نموذج طابور لشرح الآليات الكامنة وراءها.
البحث الأصلي مرخَّص بموجب CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل
تخيل الإنترنت كمدينة صاخبة وعظيمة بناها ملايين الأشخاص المختلفين. في هذه المدينة، توجد ملايين "المباني" (المشاريع البرمجية)، وأحياناً، قد تحتوي هذه المباني على شقوق مخفية أو أقفال مكسورة (ثغرات أمنية).
وللحفاظ على سلامة المدينة، يوجد مركز اتصالات طوارئ مركزي يسمى GitHub Security Advisories (GHSA). عندما يجد شخص ما شقاً في أحد المباني، فإنه يرسل تقريداً إلى هذا المركز. مهمة المركز هي التحقق من التقرير، وختمه بختم "رسمي"، ثم بث تنبيه لجميع سكان المدينة حتى يتمكنوا من إصلاح أقفالهم.
ومع ذلك، يكشف هذا البحث عن سر مفاجئ حول كيفية عمل مركز الاتصالات هذا: ليست كل التقارير تُفحص بنفس السرعة، والطريقة التي ترسل بها التقرير تهم أكثر مما تعتقد.
إليك قصة نتائجهم، مقسمة ببساطة:
1. مسارات المرور المزدوجة
نظر الباحثون في أكثر من 288,000 تقرير أُرسلت إلى مركز الاتصالات بين عامي 2019 و2025. ووجدوا أن المركز يعمل مثل طريق سريع به مسارين مختلفين تماماً:
- المسار السريع (المسار "المحلي"): إذا كان الشخص الذي وجد الشق هو مالك المبنى (مسؤول المشروع) واستخدم نموذجاً داخلياً خاصاً يسمى GRA (GitHub Repository Advisory) للإبلاغ عنه، فسيتم فحص التقرير فوراً تقريباً. الأمر يشبه اتصال مالك المبنى بإدارة الإطفاء مباشرة من داخل المبنى؛ الاستجابة فورية.
- المسار البطيء (المسار "الخارجي"): إذا جاء التقريد من مصدر خارجي، مثل قاعدة بيانات وطنية (NVD)، فيتعين عليه الانتظار في طابور طويل وفوضوي. الأمر يشبه اتصال غريب بإدارة الإطفاء من هاتف عمومي عبر المدينة. وحتى بعد أن يقوم مالك المبنى بإصلاح الشق بالفعل، قد يظل هذا التقرير عالقاً في قائمة الانتظار لأسابيع أو أشهر قبل أن يقوم مركز الاتصالات بختمه رسمياً.
2. "المسار السريع" غير مستغل بشكل كافٍ
هنا تكمن المفاجأة: على الرغم من أن المسار السريع أسرع بكثير، إلا أن معظم الناس لا يستخدمونه.
- حوالي 74% من التقارير الرسمية تأتي من المسار البطيء (NVD).
- وحوالي 26% فقط تأتي من المسار السريع (GRA).
وجد الباحثون أن المسار السريع يستخدمه غالباً مالكو المباني أنفسهم، الذين غالباً ما يكونون جدداً في هذا النظام ولم يسبق لهم القيام بذلك من قبل. وفي المقلىب، يتم التعامل مع المسار البطيء من قبل مجموعة صغيرة من "المفتشين" ذوي الخبرة العالية الذين فحصوا آلاف التقارير.
3. "الرقعة" مقابل "الختم"
درس البحث أيضاً توقيت الإصلاحات.
- في المسار السريع: عندما يقوم مالك المبنى بإصلاح شق (إصدار "رقعة")، فإن الختم الرسمي (المراجعة) يحدث عادةً في غضون يومين. يصل الإصلاح والتنبيه معاً تقريباً.
- في المسار البطيء: حتى بعد أن يقوم مالك المبنى بإصلاح الشق، قد يستغرق وصول الختم الرسمي 28 يوماً (أو أكثر من ذلك بكثير).
لماذا يهم هذا الأمر؟
تخيل أن لصاً (مخترقاً) يرى أن مبنى ما قد تم إصلاحه. إذا لم يتم ختم التنبيه الرسمي بعد، فإن بقية سكان المدينة لن يعرفوا بوجود الإصلاح. يمكن للص اللص أن يقتحم المبنى لأن "التحذير الرسمي" لم يُنشر بعد. المسار السريع يغلق هذه الفجوة؛ أما المسار البطيء فيترك المدينة مكشوفة لأسابيع.
4. نموذج "الطابور"
بنى الباحثون نموذجاً رياضياً (مثل محاكاة لطابور في مقهى) لشرح سبب حدوث ذلك.
- وجدوا أن المسار السريع يتخطى "غرفة الانتظار" تماماً.
- المسار البطيء يجبر التقارير على الجلوس في "غرفة انتظار" (قاعدة بيانات NVD) قبل أن تتمكن حتى من الوصول إلى المنصة.
- ليس هذا لأن مركز الاتصالات يتجاهل المسار البطيء؛ بل هذا هو تصميم النظام. الهيكل العام لخط الإمداد يخلق تأخيراً طبيعياً للتقارير الخارجية.
5. من الذي يقوم بالعمل؟
نظر البحث أيضاً في الأشخاص المعنيين:
- المكتشفون: الأشخاص الذين يجدون الشقوق هم غالباً أشخاص عاديون لديهم متابعات صغيرة عبر الإنترنت.
- المصلحون: الأشخاص الذين يقومون فعلياً بترقيع الكود هم عادةً مالكو المباني، وهم مشهورون جداً وموثوقون في المجتمع.
- المفتشون: المفتشون هم مزيج من الفئات. في المسار السريع، غالباً ما يكونون مالكي المباني أنفسهم (يقومون بدور مزدوج). أما في المسار الببطيء، فهم فريق متخصص من الخبراء الذين راجعوا مئات التقارير من قبل.
الخلاية
تخلص الورقة البحثية إلى أن نظام أمان GitHub يحتوي على "مسار سريع" فعال للغاية، ولكنه غير مستغل حالياً بالشكل المطلوب. معظم التقارير لا تزال تسلك "المسار البطيء"، مما يخلق تأخيراً خطيراً بين جاهزية الإصلاح وبين إبلاغ العالم به رسمياً.
يقترح الباحثون أنه إذا تم تشجيع المزيد من الناس على استخدام نماذج "المسار السريع" الداخلية (GRAs) بدلاً من انتظار قاعدة البيانات الخارجية، فإن المدينة بأكملها ستكون أكثر أماناً، وستتقلص الفترة الزمنية بين الإصلاح والتنبيه بشكل كبير. كما قاموا بنشر جميع بياناتهم وأكوادهم لتمكين الآخرين من دراسة هذا الازدحام المروري بشكل أكبر.
غارق في أبحاث مجالك؟
تصلك نشرة يومية بأحدث الأبحاث المطابقة لكلماتك البحثية المفتاحية — مع ملخصات تقنية، بلغتك.