CauSec: Unboxing the Causal Drivers of Static Vulnerability Analysis Performance
تقدم هذه الورقة CAUSEC، وهو إطار عمل للتحليل السببي يعمل على صياغة والتحقق من صحة الافتراضات الكامنة وراء أدوات اختبار أمن التطبيقات الساكن (SAST) لتحديد ما إذا كانت مقايضات التصميم الخاصة بها تؤدي حقاً إلى مكاسب الأداء المنشودة، مبرهنةً على فائدته من خلال دراسة منهجية لـ 57 افتراضاً لسوء استخدام واجهة برمجة تطبيقات التشفير (crypto-API) عبر أربع أدوات شائعة.
البحث الأصلي مرخَّص بموجب CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل
في العالم الرقمي، تعمل الأدوات البرمجية كحراس للبوابة الأمنية، حيث تقوم بفحص الكود البرمجي للعثور على الثغرات الخفية قبل استغلالها. تُستخدم هذه الأدوات، المعروفة باسم أدوات اختبار أمن التطبيقات الساكنة (SAST)، في كل مكان، من الشركات الناشئة الصغيرة إلى الشركات الضخمة. وهي تعمل من خلال تقديم تخمينات مدروسة حول كيفية سلوك الكود، وغالبًا ما تختار تجاهل أجزاء معينة من البرنامج لتعمل بشكل أسرع أو لتجنب تصنيف الكود غير الضار على أنه خطير. لقد عملت هذه الصناعة لفترة طويلة بناءً على مجموعة من المعتقدات غير المثبتة: مثل أن تخطي أنواع معينة من الكود سيجعل الأداة أكثر دقة، أو أن تجاهل مكتبات معينة سيقلل من الإنذارات الكاذبة. توجه هذه المعتقدات كيفية بناء الأدوات، ولكن حتى الآن، لم يقم أحد باختبار ما إذا كانت هذه الافتراضات صحيحة بالفعل أم أنها مجرد قصص مريحة أخبرها المصممون لأنفسهم.
قرر فريق من الباحثين في جامعة ويليام آند ماري وضع هذه المعتقدات قيد الاختبار. فقد قاموا ببناء إطار عمل جديد يسمى CAUSEC، والذي يعامل الافتراضات الكامنة وراء الأدوات الأمنية ليس كحقائق، بل كفرضيات يمكن إثباتها أو دحضها. وبدلاً من مجرد النظر في ما إذا كانت الأداة تجد الأخطاء، تساءلوا عن سبب إيجادها لها وماذا يحدث عندما تتغير القواعد. ومن خلال تطبيق منهجية تسمى "الاستدلال السببي"، والتي تساعد في الفصل بين علاقات السبب والنتيجة الحقيقية وبين المصادفات البسيطة، تمكنوا من عزل خيارات التصميم المحددة وقياس تأثيرها الحقيقي. ويكشف عملهم أن القواعد التي تتبعها الأدوات الأمنية غالبًا ما تكون أكثر هشاشة وتحديدًا مما كان يُعتقد؛ إذ إن الاستراتيجية التي تنجح تمامًا مع أداة واحدة قد تفشل تمامًا مع أخرى.
بدأ الباحثون بالنظر في تاريخ الأدوات المصممة لكشف الأخطاء في كيفية استخدام البرمجيات للتشفير، وهو العلم الرياضي الذي يحافظ على أمن البيانات. لقد فحصوا عشرين عامًا من الأوراق البحثية ووجدوا سبعة وخمسين افتراضًا متميزًا وضعها مصممو الأدوات. وتراوحت هذه الافتراضات بين فكرة أن التركيز على قواعد برمجية محددة يحسن الدقة، وبين الاعتقاد بأن تجاهل مكتبات الطرف الثالث يجعل الأداة أسرع وأكثر دقة. وأدرك الفريق أن العديد من هذه الادعاءات كانت مبنية على الارتباطات — أي الأشياء التي حدثت معًا بالصدفة — بدلاً من الأسباب المثبتة. فعلى سبيل المثال، قد تتخطى أداة ما مكتبات الطرف الثالث وبالتزامن مع ذلك يقل عدد الإنذارات الكاذبة، لكن هذا لا يعني أن عملية التخطي كانت هي السبب الفعلي للتحسن؛ فقد تكون هناك عوامل خفية أخرى تلعب دورًا في ذلك.
لفك هذا الاشتباك، ركز الفريق على افتراض شائع جدًا: وهو أن الإبلاغ عن التنبيهات الأمنية من مكتبات الطرف الثالث يقلل من دقة الأداة، مما يعني أنها تسبب المزيد من الإنذارات الكاذبة. وقد جمعوا مجموعة بيانات ضخمة تضم أكثر من 57,000 تنبيه أنتجتها أربع أدوات أمنية شهيرة هي: Semgrep وCodeQL وCogniCrypt وCryptoGuard. ثم قاموا بفحص كل تنبيه يدويًا للتأكد مما إذا كان مشكلة حقيقية أم إنذارًا كاذبًا، مما خلق "حقيقة مطلقة" يمكن قياس الأدوات بناءً عليها. وباستخدام إطار عملهم الجديد، قاموا بمحاكاة ما سيحدث لو أجبروا كل أداة على الإبلاغ عن تنبيهات مكتبات الطرف الثالث، مع مراعاة المتغيرات الأخرى بعناية مثل حجم التطبيق أو مدى شعبيته.
كانت النتائج مفاجئة وأظهرت أن هذا الافتراض ليس حقيقة عالمية. فبالنسبة لأداتين من الأدوات، صمد الافتراض: فعندما بدأت هاتان الأداتان في الإبلاط عن تنبيهات من مكتبات الطرف الثالث، ارتفع معدل الإنذارات الكاذبة بالفعل. ومع ذلك، بالنسبة للأداتين الأخريين، حدث العكس تمامًا؛ فعندما تضمنت هاتان الأداتان تنبيهات من مكتبات الطرف الثالث، تحسنت دقتهما في الواقع. أثبت هذا الاكتشاف أن تصميم الأداة نفسها يعمل كعامل تعديل؛ إذ يمكن لنفس القاعدة أن تؤدي إلى تأثيرات مختلفة تمامًا اعتمادًا على الآليات الداخلية للأداة. ووجد الباحثون أن تأثير تضمين كود الطرف الثالث يختلف اختلافًا جذريًا اعتمادًا على نوع المكتبة المحددة والأداة المستخدمة. فبالنسبة لأداة واحدة، تسببت المكتبات الخدمية (utility libraries) في انخفاض كبير في الدقة، بينما أدت تلك المكتبات نفسها إلى تحسين الدقة في أداة أخرى.
كما سلطت الدراسة الضوء على أن العديد من الافتراضات التي وضعها مصممو الأدوات كانت مبنية على مقايضات غير مؤكدة. فالمصممون غالبًا ما يضحون بالقدرة على اكتشاف كل خطأ ممكن مقابل السرعة أو تقليل الإنذارات الكاذبة، معتقدين أن هذه المقايضة ضرورية. ووجد الباحثون أنه بينما تعد هذه المقايضات حقيقية، فإن النتائج المحددة غالبًا ما تكون غير متوقعة. واكتشفوا أن الطريقة التي تُبنى بها الأداة — بقواعدها المحددة، وكيفية تصفيتها للبيانات، وكيفية تعاملها مع السياق — هي التي تحدد ما إذا كان خيار التصميم سيساعد أم سيضر. وهذا يعني أن الفريق الأمني لا يمكنه ببساطة نسخ خيارات التصميم من أداة ناجحة وتوقع الحصول على نفس النتائج؛ فما ينجح مع أداة واحدة ليس مضمون العمل مع أداة أخرى.
في الختام، تجادل الورقة البحثية بضرورة انتقال المجتمع الأمني من قبول الافتراضات كحقائق. لقد أثبت الباحثون أنه من خلال استخدام التحليل السببي، يمكن اختبار هذه الافتراضات بصرامة وفهم كيفية تأثيرها على الأداء بدقة. ووجدوا أنه بينما تكون بعض الافتراضات صالحة، فإن الكثير منها ليس كذلك، وأن صلاحيتها تعتمد كليًا على السياق المحدد للأداة المستخدمة. وتخلص الدراسة إلى أن على مصممي الأدوات عدم وراثة الافتراضات من الأعمال السابقة دون اختبارها في بيئتهم الخاصة، بل يجب عليهم معاملة كل خيار تصميمي كفرضية تحتاج إلى اختبار، لضمان أن الأدوات التي يبنونها تعتمد على الأدلة وليس على الحدس. ويوفر هذا النهج مسارًا أوضح لبناء أدوات أمنية ليست سريعة فحسب، بل فعالة حقًا في حماية البرمجيات.
غارق في أبحاث مجالك؟
تصلك نشرة يومية بأحدث الأبحاث المطابقة لكلماتك البحثية المفتاحية — مع ملخصات تقنية، بلغتك.