SBOM-Based Container Deployment Risk Assessment under Incomplete Runtime Observations
تقترح هذه الورقة طريقة تكيفية قائمة على قائمة مواد البرمجيات (SBOM) لتقييم مخاطر نشر الحاويات في ظل ملاحظات وقت التشغيل غير المكتملة، وذلك من خلال دمج مصادر أدلة متعددة لتصنيف قابلية تطبيق الثغرات الأمنية وتحديد أولويات تكاليف الفحص، مما يحقق معدلات إكمال قرار محسنة وتقليلاً في أوقات الانتظار مقارنة بالنهج المرجعية.
البحث الأصلي مرخَّص بموجب CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل
في عالمنا الرقمي الحديث، نادراً ما تُبنى البرمجيات من الصفر. بدلاً من ذلك، يقوم المطورون بتجميع التطبيقات مثلما يجمع طاهٍ ماهر طبقاً معقداً من مكونات جاهزة: مكتبات، وأطر عمل، وأدوات صُنعت من قبل الآخرين. ولتتبع هذه المكونات، يعمل معيار جديد يُسمى "قائمة مواد البرمجيات" (SBOM)، كقائمة جرد تفصيلية. وتعد هذه القائمة حاسمة للأمن؛ لأنه إذا تم اكتشاف ثغرة معروفة في أحد المكونات، فإن قائمة (SBOM) تساعد في تحديد التطبيقات التي تحتوي عليها. ومع ذلك، فإن معرفة وجود مكون ما ليست سوى نصف المعركة؛ فالثغرة في إحدى المكتبات لا تصبح خطراً إلا إذا كان البرنامج يستخدم ذلك الجزء المحدد من الكود بالفعل أثناء تشغيله. أما إذا ظل الكود خاملاً، ولم يتم استدعاؤه أبداً من قبل البرنامج، فإن الثغرة تكون غير ضارة. ويكمكم التحدي الذي يواجه الفرق الأمنية في أنهم لا يستطيعون دائماً مراقبة تشغيل البرنامج بشكل مثالي؛ فأحياناً تغفل أدوات المراقبة عن بعض الأحداث، أو لا تغطي سيناريوهات الاختبار كل الطرق الممكنة لاستخدام البرنامج. وهذا يترك فجوة حيث قد لا تعرف الفرق ما إذا كانت الثغرة خطيرة أم آمنة، مما يضطرهم إما إلى حظر تحديث ضروري أو المخاطرة بوقوع اختراق.
لقد عالج الباحثان بيونغ تشان بارك وسون جيب كيم حالة عدم اليقين هذه من خلال ابتكار طريقة جديدة لتقرير ما إذا كان ينبغي نشر "حاوية برمجية" (software container)، وهي عبارة عن حزمة مستقلة من تطبيق ومكوناته. يعامل نهجهما نقص المعلومات الكاملة ليس كسبب للتخمين، بل كسبب للتوقف وجمع المزيد من الأدلة المحددة. لقد بنيا نظاماً يجمع بين قائمة الجرد والتحليل الساكن (static analysis)، الذي يفحص هيكل الكود، والملاحظات أثناء التشغيل (runtime observations)، التي تراقب البرنامج أثناء العمل. والأهم من ذلك، أن النظام يدرك أنه مجرد عدم رؤية دالة خطيرة أثناء الاختبار لا يعني بالضرورة أن الدالة آمنة للتجاهل. وبدلاً من فرض إجابة "نعم" أو "لا" عندما تكون الأدلة ضئيلة، يصنف النظام الخطر كـ "خطر مؤكد"، أو "آمن ضمن نطاق محدد"، أو "غير محسم". وعندما يكون الخطر غير محسم، لا يقوم النظام بالموافقة على النشر ببساطة، بل يضع الطلب قيد الانتظار.
يكمن جوهر ابتكارهما في استراتيجية تخصيص قدر محدود من الوقت وقوة الحوسبة لحسم حالات عدم اليقين هذه. تخيل فريقاً أمنياً لديه موعد نهائي صارم لاتخاذ قرار بشأن تحديث برمجي. لديهم قائمة بالثغرات المحتملة، لكن فحص كل واحدة منها بدقة يستغرق وقتاً طويلاً جداً. تعمل طريقة الباحثين كدليل ذكي، يقرر أي الفحوصات يجب إجراؤها أولاً بناءً على مدى احتمالية مساعدتها في الوصول إلى قرار نهائي، بدلاً من إجراء الفحوصات بترتيب عشوائي أو بناءً على الخطورة وحدها. يقوم النظام بإعادة تقييم خياراته باستمرار مع ورود بيانات جديدة، مما يضمن إنفاق كل ثانية من ميزانية الفحص على الفحص الأكثر أهمية للقرار النهائي.
ولاختبار هذا النهج، أنشأ الباحثان محاكاة واقعية باستخدام مائة سيناريو مختلف لنشر البرمجيات مستمدة من أربعين حالة ثغرة محددة في مشاريع لغة "جافا" (Java). وقد وضعوا "حقيقة أرضية" (ground truth) لتسعين حالة من هذه الحالات، مما يعني أنهم كانوا يعرفون بالضبط أي عمليات النشر كانت آمنة وأيها كانت خطيرة، بشكل مستقل عن نظامهم الجديد. ثم أخضعوا النظام لأشكال مختلفة من المعلومات الناقصة، مثل الأجزاء المفقودة من عبء عمل الاختبار، أو فترات المراقبة القصيرة، أو فقدان أحداث البيانات. وقارنوا طريقتهم التكيفية بعدة استراتيجيات أخرى، بما في ذلك الفحص البسيط القائم على القوائم، وطريقة تعطي الأولوية للفحوصات بناءً على تكلفتها في الحسم. وأظهرت النتائج أن طريقتهم كانت أكثر فعالية في الوصول إلى قرار نهائي صحيح ضمن المهلة الزمنية. وتحت ميزانية قدرها مائة وعشرون ثانية، حققت طريقتهم الجديدة معدل قرار صحيح متوازن بنسبة 78.4%، مقارنة بـ 76.3% للطريقة التالية الأفضل منها.
وربما الأهم من ذلك، أن الطريقة الجديدة قللت من عدد الحالات التي ظلت عالقة في حالة "الانتظار" غير المحسمة. فبينما تركت الطرق الأخرى 22% من القرارات دون حسم، قللت الطريقة المقترحة هذه النسبة إلى 20%. وهذا يعني أن المزيد من التحديثات البرمجية يمكن أن تمضي قدماً بأمان دون تأخيرات غير ضرورية، مع الحفاظ في الوقت نفسه على معدل خطأ منخفض جداً. لقد وافق النظام على عمليات النشر الخطيرة بشكل خاطئ بنسبة 1.2% فقط، وحظر عمليات النشر الآمنة بشكل خاطئ بنسبة 2% فقط. وتشير هذه الأرقام إلى أنه من خلال ترتيب الفحوصات بعناية ورفض اتخاذ قرار عند عدم كفاية الأدلة، يمكن للفرق الأمنية التنقل عبر ضباب البيانات غير المكتملة بشكل أكثر فعالية. وتؤكد الدراسة أن النهج المنظم القائم على الأدلة يمكنه التمييز بين الثغرة التي هي حقاً غير ضارة وتلك التي لم تُلاحظ فحسب، مما يسمح للمؤسسات بالمضي قدماً بثقة حتى عندما لا يمكنهم رؤية كل تفصيل من سلوك برمجياتهم.
غارق في أبحاث مجالك؟
تصلك نشرة يومية بأحدث الأبحاث المطابقة لكلماتك البحثية المفتاحية — مع ملخصات تقنية، بلغتك.