DCI: Dependency Confidence Index for Assessing Open-Source Dependency Trustworthiness
تقدم هذه الورقة مؤشر ثقة التبعيات (DCI)، وهو مقياس مركب يدمج تسعة عوامل ثقة موزونة تجريبياً مستمدة من الأدبيات واستطلاعات المطورين لتقييم موثوقية التبعيات مفتوحة المصدر، مما يثبت فعاليته من خلال تقييم تجريبي على 92 حزمة من مستودع PyPI.
المؤلفون الأصليون:Clemens Albrecht, Stefan Reitmann
تعتمد حياتنا الرقمية كل يوم على شبكة واسعة وغير مرئية من البرمجيات. فمن التطبيقات الموجودة على هواتفنا إلى الأنظمة التي تدير حساباتنا المصرفية، نادراً ما تُبنى البرامج الحديثة من الصفر؛ بل يتم تجميعها كبنى معقدة باستخدام أجزاء جاهزة، تُعرف بالتبعيات مفتوحة المصدر، والتي أنشأها آلاف الأشخاص والمنظمات المختلفة حول العالم. وبينما يسمح هذا النهج بتطور التكنولوجيا بسرعة، إلا أنه يفرض خطراً جسيماً: فإذا كان أحد هذه الأجزاء المستعارة معيباً أو خبيثاً، يمكن للتطبيق بأكمله الذي بُني عليه أن يفشل أو يتعرض للاختراق. ويكمن التحدي الذي يواجه المطورين في عدم وجود طريقة واحدة سهلة للحكم على مدى موثوقية هذه المكونات التي لا حصر لها؛ إذ يتعين عليهم البحث بين التقارير الأمنية، وفحوصات جودة الكود، وتواريخ المشاريع، وغالباً ما يكون ذلك دون وسيلة واضحة لوزن العوامل الأكثر أهمية.
ولمعالجة حالة عدم اليقين هذه، طور باحثون في جامعة كيمنتس للتكنولوجيا أداة جديدة تسمى "مؤشر ثقة التبعية" (Dependency Confidence Index). يعمل هذا النظام بمثابة بطاقة أداء موحدة، صُممت لمساعدة مطوري البرمجيات في اتخاذ قرار بشأن مدى الثقة في قطعة معينة من الكود قبل استخدامها. لم يبتكر الباحثون مجرد مجموعة جديدة من القواعد، بل بنوا نهجهم على أساس من الفهم العلمي القائم حول ما يجعل البرمجيات موثوقة. وقد بدأوا بتحديد تسعة مجالات رئيسية تساهم في بناء الثقة، تتراوح من أمن الكود نفسه إلى صحة المشروع الذي يديره. وتشمل هذه المجالات مدى جودة كتابة الكود، وما إذا كان المشروع يمتلك ترخيصاً واضحاً، ومدى تكرار تحديثه، وسمعة الأشخاص القائمين عليه.
تضمن جوهر المشروع ترجمة هذه المفاهيم الواسعة إلى قياسات ملموسة ومؤتمتة. فقد أنشأ الفريق منصة رقمية يمكنها فحص مكتبة برمجية وجمع بيانات حول هذه العوامل التسعة. ولتحديد الوزن الذي يجب أن يحمله كل عامل في الدرجة النهائية، استشاروا مجموعة صغيرة مكونة من عشرة مطورين برمجيات ذوي خبرة. وقام هؤلاء الخبراء بمقارنة العوامل ببعضها البعض لتحديد أي منها أكثر حرجاً للسلامة والموثوقية. وكانت النتيجة نظاماً موزوناً حيث برز الأمن كأهم عامل، يليه عن كثب جودة الكود المصدري والصحة العامة للمشروع. ثم تأخذ المنصة البيانات الخام التي تجمعها — مثل عدد الثغرات المعروفة أو وتيرة تحديثات الكود — وتدمجها في رقم واحد يتراوح بين صفر وواحد. وتشير الدرجة القريبة من الواحد إلى مكون عالي الموثوقية، بينما تشير الدرجة المنخفضة إلى مخاطر محتملة.
اختبر الباحثون مؤشرهم الجديد على اثنتين وتسعين حزمة برمجية شهيرة تُستخدم في لغة البرمجة "بايثون" (Python). ووجدوا أن النظام يعمل باتساق، حيث يعطي نفس النتائج عند تشغيله عدة مرات على الحزم نفسها. وعندما قارنوا درجاتهم الجديدة بأداة أمنية موجودة تُسمى "OpenSSF Scorecard"، لاحظوا توافقاً متوسطاً بينهما، مما يشير إلى أن المؤشر الجديد يلتقط معلومات مشابهة للأدوات الراسخة ولكنه يقدم منظوراً مختلفاً. ومن المثير للاهتمام أن التحليل كشف أن هذه الحزم الشهيرة وعالية الجودة كانت درجاتها مدفوعة بكيفية إدارة المشروع — مثل استخدام الاختبارات المؤتمتة وقواعد التبعية الواضحة — أكثر من وجود ثغرات أمنية. وفي هذه المجموعة المحددة من الحزم المختبرة، كانت مقاييس الأمن مرتفعة باستمرار لدرجة أنها لم تكن متغيرة بما يكفي للتمييز بين المكتبات المختلفة. وهذا لا يعني أن الأمن غير مهم، بل يشير إلى أنه بالنسبة للمشاريع الناضجة والشائعة، فإن عملية صيانة البرمجيات غالباً ما تكون الإشارة الأقوى للموثوقية.
كما سلطت الدراسة الضوء على حدود نهجهم الحالي. فقد أشار الباحثون إلى أن نظامهم يعتمد على بيانات يصعب أحياناً جمعها تلقائياً، مثل العدد الدقيق للأشخاص الذين يمكنهم صيانة مشروع ما أو اكتمال التوثيق. علاوة على ذلك، اقتصر الاختبار على مكتبات بايثون الشهيرة، مما يعني أن النتائج قد تبدو مختلفة بالنسبة للحزم الأقدم أو الأقل شهرة أو الخبيثة حيث تكون الثغرات الأمنية أكثر شيوعاً. ويؤكد الفريق بحذر أن هذا المؤشر ليس بديلاً لأدوات الأمن المتخصصة ولا ضمانة بأن قطعة برمجية ما آمنة، بل هو مخصص ليكون أداة مساعدة للفحص، تساعد المطورين على تنظيم الكم الهائل من المعلومات المتاحة حول مكتبة ما وتحديد المجالات التي قد تحتاج إلى فحص أدق. ومن خلال توفير رقم واحد قابل للتفسير إلى جانب تفاصيل دقيقة لكل عامل، يهدف "مؤشر ثقة التبعية" إلى جعل المهمة المعقدة لأمن سلسلة توريد البرمجيات أكثر سهولة وإدارة للأشخاص الذين يبنون عالمنا الرقمي.
ملخص تقني: مؤشر ثقة التبعيات (DCI)
بيان المشكلة لا يزال اختيار تبعيات البرمجيات مفتوحة المصدر (OSS) الموثوقة يمثل تحديًا حاسمًا في أمن سلاسل توريد البرمجيات. وبينما توجد مقاييس لإشارات الجودة الفردية (مثل عدد الثغرات الأمنية، وتغطية الاختبارات)، يفتقر المطورون إلى درجة موحدة وقابلة للتفسير لتوجيه عملية اختيار التبعيات. غالبًا ما تركز الأدوات الحالية على مجالات محددة (الأمن، أو جودة الكود، أو صحة المشروع) أو تتطلب تجميعًا يدويًا لبيانات متباينة. علاوة على ذلك، ارتفأت الحزم البرمجية الخبيعة بنسبة 156% سنويًا في عام 2024، ووجد أن 96% من المكونات الضعيفة التي تم تحميلها كانت تتوفر لها إصلاحات، مما يسلط الضرورة على وجود فجوة بين المعلومات المتاحة واتخاذ القرارات القابلة للتنفيذ.
المنهجية يقترح المؤلفون مؤشر ثقة التبعيات (DCI)، وهو مؤشر تكويني مركب مصمم لتجميع تسعة عوامل ثقة موزونة تجريبيًا في درجة واحدة موحدة ضمن النطاق [0,1]. تتبع المنهجية نهجًا مهيكلًا:
اختيار عوامل الثقة: تم اشتقاق تسعة عوامل من مراجعة أدبية منهجية (Hou and Jansen [12]) وتصنيفها إلى أبعاد قائمة على السمات (الأمن، جودة الكود المصدري، اكتمال التوثيق، إعلان الترخيص) وأبعاد قائمة على العمليات (جودة عملية التطوير، صحة المشروع، وتيرة الإصدار، إدارة التبعيات، والسمعة).
التوزين عبر عملية التسلسل الهرمي التحليلي (AHP): أُجري استطلاع استكشافي باستخدام عملية التسلسل الهرمي التحليلي (AHP) شمل 10 مطورين برمجيات لتحديد الأوزان التجريبية. برز كل من الأمن ($0.277)،وجودةالكودالمصدري(0.164)،وصحةالمشروع(0.140$) كأكثر العوامل تأثيرًا، حيث شكلت مجتمعة حوالي 60% من الوزن الإجمالي.
تنفيذ القياس (GQM): باستخدام منهجية الهدف/السؤال/المقياس (GQM)، تم تنفيذ 12 قياسًا مؤتمتًا باستخدام SonarQube، وواجهات برمجة تطبيقات GitHub، وبيانات OpenSSF Scorecard. تشمل هذه القياسات كثافة العيوب (الثغرات، الأخطاء، روائح الكود)، وكثافة التعليقات، ووجود الترخيص، واستخدام التكامل المستمر (CI)، وتغطية الاختبار، وعامل الحافلة (bus factor)، وتكرار الإصدار، وأدوات إدارة التبعيات، والشعبية (نجوم GitHub).
التطبيع (Normalization): تم تطبيع القياسات المستمرة إلى النطاق [0,1] باستخدام قيم مرجعية خاصة بكل تنفيذ (على سبيل المثال، الحدود العليا المستمدة من دراسات سابقة على C/C++/Java). وتم تعيين القياسات المنطقية (Boolean) إلى 0 أو 1.
بنية النظام: تم تطوير منصة تقييم حاوية (containerized)، تتكون من منصة تقييم (واجهة ويب، خلفية برمجية) ومشغل مهام (JobRunner) في بيئة معزولة باستخدام Docker. يقوم النظام بأتمتة استنساخ المستودعات، والتحليل الساكن (SonarQube)، وجمع المقاييس لحساب درجة DCI الموزونة.
المساهمات الرئيسية
نموذج ثقة مركب: مؤشر تكويني يجمع تسعة عوامل ثقة متميزة، موزونة عبر AHP، لتوفير درجة واحدة موجهة لاتخاذ القرار بشأن تبعيات OSS.
إطار قياس مؤتمت: تنفيذ 12 قياسًا مؤتمتًا عبر أبعاد الأمن، جودة الكود، وصحة المشروع، منشورة في بيئة حاوية قابلة لإعادة الإنتاج.
التقييم التجريبي: دراسة لحزم Python الشهيرة لتقييم ارتباط DCI مع OpenSSF Scorecard وموثوقية الاختبار وإعادة الاختبار (test-retest reliability).
النتائج أسفر التقييم التجريبي على حزم Python الشهيرة عن النتائج التالية:
حجم العينة: من بين 100 حزمة مختارة في البداية، تم قياس 92 منها بنجاح بواسطة منصة DCI. ومع ذلك، نظرًا لعدم وجود تداخل مع بيانات OpenSSF Scorecard المتاحة، كان العدد النهائي للحزم المتاحة للتقييم المقارن هو 85 حزمة.
الارتباط: أظهرت درجات DCI الموحدة ارتباطًا متوسطًا وذا دلالة إحصائية مع درجات OpenSSF Scorecard (ρ=0.396,p=0.0002).
الموثوقية: أظهر النظام موثوقية مثالية في اختبار إعادة الاختبار لمجموعة فرعية من الحزم تحت ظروف غير متغيرة.
تأثير العوامل: على عكس الوزن المفاهيمي العالي المخصص للأمن في استطلاع AHP، لم يظهر عامل الأمن (SV) أي ارتباط معنوي مع درجة DCI النهائية (r=0.033). وقد عزي ذلك إلى أن مجموعة البيانات تتكون من حزم ناضجة وشائعة حيث كانت كثافة الثغرات والمشكلات الأمنية ثابتة (قريبة من الصفر)، مما جعل العامل غير مميز في هذه العينة المحددة.
المحركات المهيمنة: هيمنت العوامل القائمة على العمليات، وتحديدًا إدارة التبعيات (r=0.760) وجودة عملية التطوير (r=0.602)، على تباين الدرجات للحزم عالية الجودة.
قيود القياس: كانت العديد من القياسات (مثل إعلان الترخيص، وكثافة الثغرات) ثابتة عبر العينة (1.0)، بينما فشل قياس تغطية الكود (P2) في توليد بيانات صالحة (0.0) بسبب قيود SonarQube مع مشاريع Python، مما قلل من الأبعاد الفعلية للمؤشر في هذا الاختبار التجريبي.
الأهمية والادعاءات يضع البحث DCI ليس كبديل لأدوات أمنية متخصصة، بل كإشارة فحص تكميلية لدعم مراجعة التبعيات. تكمن أهميته الأساسية في:
التركيب (Synthesis): توفير تمثيل مشترك موجه للقرار للإشارات المتباينة التي تكون موزعة بخلاف ذلك عبر أدوات متعددة (SonarQube، Scorecard، إلخ).
الشفافية: تنظيم الأدلة لمساعدة المطورين على تحديد نقاط الضعف في مجالات محددة (مثل الصيانة، التراخيص، العمليات) بدلاً من تقديم ضمان تلقائي للسلامة.
التأسيس: تقديم تنفيذ وإطار عمل متاح للجمال لمزيد من البحث في موثوقية OSS.
يصرح المؤلفون صراحةً بأن النتائج الحالية أولية. إن حدود التطبيع هي تقريبات هندسية وليست عتبات معايرة تجريبيًا لجميع الأنظمة البيئية، كما أن أوزان AHP تعتمد على عينة صغيرة متجانسة. لا تدعي الدراسة أن DCI هو مقي ر نهائي لمخاطر سلسلة التوريد أو أن مخطط التوزين الحالي ثابت؛ بل تعمل كخطوة تأسيسية للتدقيق الآلي للتبعيات.