💻 computer science

Residual Risk Analysis in Benign Code: How Far Are We? A Multi-Model Semantic and Structural Similarity Approach

تقدم هذه الورقة تقييم مخاطر المتبقي (RRS)، وهو إطار عمل يجمع بين تحليل التشابه الدلالي والهيكلي ليكشف أن ما يقرب من 61% من الدوال التي تم إصلاحها في معيار PrimeVul لا تزال تحتفظ بمخاطر أمنية متبقية كبيرة، مما يتحدى الافتراض بأن الكود الذي تم إصلاحه هو بطبيعته حميد.

المؤلفون الأصليون: Mohammad Farhad, Shuvalaxmi Dass

نُشر 2026-04-24

📖 5 دقيقة قراءة🧠 قراءة متعمّقة

CC BY 4.0

المؤلفون الأصليون: Mohammad Farhad, Shuvalaxmi Dass

البحث الأصلي مرخَّص بموجب CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل

إليك شرح للورقة البحثية، مترجم إلى لغة يومية مع بعض التشبيهات الإبداعية.

الفكرة الكبرى: "مشكلة الضمادة"

تخيل أن لديك سقفًا يسرب الماء. تضع عليه "ضمادة" (Band-Aid) لإيقاف تسرب الماء مؤقتًا. من الناحية التقنية، تم "إصلاح" التسريب، ولم يعد المنزل "عرضة للخطر" من أجل قطرات الماء المباشرة.

لكن هنا تكمن المشكلة: بقية السقف لا تزال قديمة، متآكلة، ومليئة بنقاط الضعف. إذا نظرت إلى السقف فقط، سيبدو تقريبًا كما كان تمامًا قبل وضع الضمادة عليه.

تطرح هذه الورقة سؤالًا مخيفًا: هل مجرد قيامنا بسد الثقب يعني أن المنزل أصبح آمنًا حقًا؟ أم أننا قمنا فقط بتغطية مشكلة بينما تركنا بقية الهيكل قريبًا جدًا من حالته الخطيرة السابقة؟

يطلق المؤلفون على هذا اسم "المخاطر المتبقية" (Residual Risk). وهي الخطر الخفي الذي يظل موجودًا حتى بعد تطبيق "الإصلاح".

المشكلة: نحن نفترض أن "تم الإصلاح" تعني "أصبح آمنًا"

في عالم البرمجيات (مثل التطبيقات الموجودة على هاتفك أو الأكواد التي تشغل الإنترنت)، يجد المطورون أخطاءً برمجية (Bugs) باستمرار ويقومون بإصلاحها. عادةً، عندما يتم إصدار "رقعة" (Patch)، تفترض أدوات الأمن أن الكود أصبح الآن "حميدًا" (Benign) أي آمنًا، وتتوقف عن مراقبته.

يجادل المؤلفون بأن هذا خطأ. فغالبًا ما يقوم المطورون بـ إصلاحات جراحية صغيرة جدًا لإيقاف انهيار محدد دون إعادة كتابة البرنامج بالكامل.

النتيجة: الكود "الآمن" يبدو متطابقًا بنسبة 99% مع الكود "الخطير" الذي استبدله.
الخطر: نظرًا لأن التشابه كبير جدًا، فقد تظل الأخطار الخفية الأخرى (مثل مسمار مرتخٍ أو سلك ضعيف قريب) موجودة، في انتظار التسبب في مشكلة جديدة لاحقًا.

الحل: نظام "المحقق ثلاثي الأجزاء"

للعثور على هذه المخاطر الخفية، بنى المؤلفون أداة جديدة تسمى "درجة المخاطر المتبقية" (Residual Risk Scoring - RRS). فكر فيها كفريق تحقيق مكون من ثلاثة فرق، يحقق في قطعة الكود "المُصلحة" ليرى ما إذا كانت آمنة حقًا.

1. المحقق الدلالي (قارئ "المعنى")

كيف يعمل: يستخدم هذا الجزء ذكاءً اصطناعيًا متطورًا (نماذج لغوية برمجية - Code LMs) لقراءة الكود وفهم ماذا يفعل، وليس فقط ما هي الكلمات المكتوبة.
التشبيه: تخيل شخصين يكتبان قصة. إحدى القصتين بها خطأ مطبعي يجعل الشخصية تموت. يقوم المحرر بتصحيح الخطأ المطبعي. المحقق الدلالي يقرأ القصتين ويقول: "القصتان متطابقتان بنسبة 99%. الحبكة، والشخصيات، والمزاج العام لم يتغيروا".
الدليل: إذا كانت القصة "الآمنة" مشابهة جدًا للقصة "الخطيرة"، يرفع المحقق علم التحذير.

2. المحقق الهيكلي (مفتش "المخطط الهندسي")

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

3. قاضي الاتساق (مدقق "تفكير المجموعة")

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

تجميع كل شيء: "درجة المخاطر"

يجمع النظام هذه الأدلة الثلاثة في "درجة مخاطر متبقية" (RRS) واحدة.

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

ماذا وجدوا؟

اختبر المؤلفون هذا النظام على آلاف الإصلاحات البرمجية الحقيقية (من مجموعة بيانات "PrimeVul"). وإليكم ما اكتشفوه:

"الضمادة" حقيقية: حوالي 61% من الرقعات التي بدت "آمنة" للأدوات التقليدية، كانت لا تزال تحتوي في الواقع على مشاكل خفية.
المشاكل حقيقية: عندما مرروا هذه الرقعات "عالية المخاطر" عبر ماسحات أمنية احترافية، وجدت الماسحات مشكلات حقيقية مثل:
- إلغاء مرجع المؤشر الفارغ (Null Pointer Dereferences): محاولة فتح باب غير موجود (مما يؤدي لانهيار البرنامج).
- تسريب الذاكرة (Memory Leaks): ترك الصنبور مفتوحًا، مما يستنزف موارد النظام ببطء.
- تجاوز السعة (Buffer Overflows): محاولة صب جالون من الماء في كوب، مما يؤدي لانسكابه في كل مكان (خرق أمني).
الطريقة القديمة أخطأت: افترضت الأدوات التقليدية أنه نظرًا لأن الكود قد تم "إصلاحه"، فإنه أصبح آمنًا. لقد فاتتهم هذه الـ 61% من الحالات لأنهم لم ينظروا إلى مدى تشابه الكود الجديد مع الكود القديم المعطل.

الخلاصة

تعلمنا هذه الورقة البحثية أنه في البرمجيات، "تم الإصلاح" لا يعني دائمًا "أصبح آمنًا".

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

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

إليك ملخص تقني مفصل للورقة البحثية بعنوان: "تحليل المخاطر المتبقية في الكود الحميد: إلى أي مدى نحن بعيدون؟ نهج متعدد النماذج للتشابه الدلالي والهيكلي."

1. بيان المشكلة

تعالج الورقة فجوة حرجة في أمن البرمجيات: الافتراض القائل بأنه بمجرد إصلاح الثغرة الأمنية، يصبح الكود حميداً بطبيعته. في الواقع، غالباً ما يطبق المطورون إصلاحات طفيفة وموضعية لمعالجة عيوب محددة دون إعادة هيكلة المنطق الأوسع. وبناءً على ذلك، فإن الكود "الحميد" (المُصلح) غالباً ما يحتفظ بـ تشابهات دلالية وهيكلية كبيرة مع سلفه الضعيف (المصاب بالثغرة).

هذا "الاستمرار التمثيلي" يخلق مخاطر متبقية (Residual Risk): وهي احتمالية استمرار وجود ثغرات كامنة (مثل تفريغ المؤشر الفارغ/null pointer dereference، أو تخصيص الذاكرة غير الآمن) رغم عملية الإصلاح. تفشل أدوات التحليل الساكن (static analysis) ومعايير قياس الثغرات الحالية غالباً في اكتشاف هذه المخاطر لأنها تعامل الكود المُصلح ككود آمن، أو تعتمد على كشف ثنائي للثغرات يغفل عن العيوب المنطقية الدقيقة التي تلي عملية الإصلاح. ويجادل المؤلفون بأن التشابه العالي بين الكود الضعيف والحميد ليس مجرد نتاج عرضي للإصلاح الفعال، بل هو إشارة لوجود خطر متبقٍ محتمل يتطلب مزيداً من الفحص.

2. المنهجية

يقترح المؤلفون إطار عمل موحداً يسمى درجة خطر المتبقي (Residual Risk Scoring - RRS) لقياس احتمالية وجود خطر متبقٍ في الكود المُصلح. يدمج هذا النهج ثلاث إشارات متميزة:

أ. التشابه الدلالي (القائم على التضمين - Embedding-Based)

الآلية: يستخدم المؤلفون نماذج لغة برمجية (Code LMs) متعددة مدربة مسبقاً لتوليد تضمينات متجهة (vector embeddings) لكل من الدالة الضعيفة ( $f_v$ ) والدالة الحميدة ( $f_b$ ).
النماذج المستخدمة: مجموعة متنوعة تشمل النماذج القائمة على الترميز (CodeBERT, UniXCoder, GraphCodeBERT) والنماذج القائمة على الترميز وفك الترميز (CodeT5-base, CodeT5-770M).
المقياس: تُستخدم تشابه جيب التمام (Cosine Similarity) لقياس المسافة بين التضمينات. يشير التشابه العالي إلى أن السلوك الوظيفي الذي يمثله النموذج لم يتغير بشكل كبير.
المبرر: تم اختيار تشابه جيب التمام لقوته وعدم تأثره بحجم المتجه، مما يوفر درجات مستقرة (المتوسط ~0.99) عبر النماذج المختلفة.

ب. التشابه الهيكلي (القائم على شجرة الإعراب المجردة - AST-Based)

الآلية: يحلل المؤلفون أشجار الإعراب المجردة (ASTs) لأزواج الكود باستخدام Tree-sitter.
المقياس: بدلاً من استخدام مسافة تحرير الشجرة العالمية (Global Tree Edit Distance - TED)، والتي قد تتضخم بسبب المناطق الكبيرة غير المتغيرة، يقترح المؤلفون تشابه مسافة تحرير الشجرة الموضعي (Localized TED Similarity - LTS). يركز هذا على الأجزاء الفرعية (subtrees) التي تم تعديلها بواسطة الإصلاح.
المبرر: المقاييس العالمية غالباً ما تحجب التغييرات الدقيقة ذات الصلة بالأمن. ينجح التحليل الموضعي في التقاط التحولات الهيكلية الدنيا النموذجية للإصلاحات (مثل تغيير استدعاء دالة إلى وصول إلى حقل) مع الحفاظ على هيكل الشجرة العام.

ج. الاتفاق بين النماذج (Cross-Model Agreement)

الآلية: لضمان أن التشابه الدلالي ليس مجرد نتاج انحياز نموذج معين، يحسب إطار العمل تباين (variance) درجات التشابه عبر نماذج اللغة البرمجية المتعددة المستخدمة.
المقياس: يتم اشتقاق درجة الاتفاق بين النماذج ( $C_{agree}$ ) من مقلوب التباين. يشير التباين المنخفض (الاتفاق العالي) إلى قوة الدليل على أن الكود قد تم الحفاظ على دلالته.

د. صيغة درجة خطر المتبقي (RRS Formula)

إن درجة خطر المتبقي (RRS) النهائية هي مجموع مرجح لهذه المكونات الثلاثة:
$RRS(f_v, f_b) = \alpha \cdot \bar{S}_{sem} + \beta \cdot R_{struct} + \gamma \cdot C_{agree}$
حيث أن:

$\bar{S}_{sem}$ : متوسط التشابه الدلالي عبر النماذج.
$R_{struct}$ : التشابه الهيكلي الموضعي.
$C_{agree}$ : درجة الاتفاق بين النماذج.
$\alpha, \beta, \gamma$ : معاملات الوزن (على سبيل المثال 0.5، 0.3، 0.2) التي توازن المساهمات.

3. المساهمات الرئيسية

صياغة رسمية للمخاطر المتبقية: يعد هذا أول عمل يصيغ الخطر المتبقي كدالة لتقارب مستوى التمثيل (الدلالي والهيكلي) بين الكود الضعيف والحميد.
تحليل AST موضعي: تثبت الورقة أن مسافة TED الموضعية تتفوق على مقاييس الشجرة العالمية في تحليل الإصلاحات، لأنها تتجنب تخفيف التغييرات ذات الصلة بالأمن عبر مناطق الكود غير المتغيرة.
| 3. إطار عمل موحد (RRS): تقديم نظام تسجيل متعدد الإشارات يجمع بين التضمينات، والتحليل الهيكلي، وإجماع النماذج لتحديد أولويات الفحص ما بعد الإصلاح.
التحقق التجريبي: تم التحقق من صحة إطار العمل مقابل أدوات التحليل الساكن الحديثة (Cppcheck, Clang-Tidy, Facebook Infer) والتدقيق اليدوي، مما يثبت فائدته في السيناريوهات الواقعية.

4. النتائج التجريبية

أجريت الدراسة على مجموعة بيانات PrimeVul، حيث تم تحليل 3,789 زوجاً من الدوال الضعيفة والحميدة (7,578 دالة) بلغة C/C++.

الحفاظ العالي على الخصائص (RQ1):
- دلالياً: أظهرت الدوال الحميدة تشابهاً عالياً جداً في جيب التمام مع نظيراتها الضعيفة عبر جميع النماذج (المتوسط $\approx$ 0.98–0.99).
- هيكلياً: كان التشابه الهيكلي الموضعي عالياً أيضاً (الوسيط $\approx$ 0.93)، مما يؤكد أن الإصلاحات عادة ما تكون دنيا وموضعية.
- الاستنتاج: غالباً ما تحافظ الإصلاحات على "شكل" و"معنى" الكود الأصلي، مما يترك الأنماط المتبقية قائمة.
تقدير قوي للمخاطر (RQ2):
- صنف المؤلفون أزواج الكود إلى أربعة أرباع بناءً على مستويات التشابه. احتوى الربع الأول (تشابه دلالي عالٍ + تشابه هيكلي عالٍ) على ~29.5% من الأزواج، وتم تحديده كمنطقة الخطر الأعلى.
- أظهر تحليل الحساسية أن ترتيب RRS ظل مستقراً عبر تكوينات الأوزان المختلفة ( $\alpha, \beta$ )، مما يثبت قوة إطار العمل.
التحقق عبر التحليل الساكن (RQ3):
- عند تحليل الدوال ذات الـ RRS العالي باستخدام Cppcheck وClang-Tidy وFacebook Infer:
  - تم رصد 61% من الدوال ذات الـ RRS العالي كإشكاليات ذات صلة أمنية (مثل انتهاكات سلامة الذاكرة، تفريغ المؤشر الفارغ، المتغيرات غير المهيأة).
  - تم رصد 43% بواسطة أداتين، و27% بواسطة الأدوات الثلاث معاً.
- حددت الدراسة 13 فئة متميزة من المشكلات المتبقية، مما يؤكد أن التشابه العالي يرتبط فعلياً بوجود عيوف أمنية قابلة للكشف.

5. الأهمية والأثر

تحول في النموذج الأمني: تتحدى الورقة الرؤية الثنائية لـ "ضعيف مقابل حميد". فهي تفترض أن الكود "الحميد" يتطلب تدقيقاً مستمراً إذا ظل مشابهاً جداً لسلفه الضعيف.
أداة لتحديد الأولويات: يعمل RRS كإشارة عملية لفرق الأمن لتحديد أولويات الدوال التي تحتاج إلى مراجعة يدوية عميقة أو اختبار إضافي، بدلاً من معاملة جميع الإصلاحات على أنها آمنة بالتساوي.
القابلية للتوسع: من خلال الاستفيد من النماذج المدربة مسبقاً وتحليل AST الآلي، يوفر النهج طريقة قابلة للتوسع لتقييم المخاطر في الأنظمة البيئية مفتوحة المصدر الضخمة (مثل Linux وOpenSSL) حيث تكون المراجعة اليدية لكل إصلاح أمراً مستحيلاً.
التوجهات المستقبلية: يقترح المؤلفون توسيع هذا النهج ليشمل التحليل الديناميكي ولغات برمجة متنوعة لتنقيح تقدير المخاطر وتقليل الإيجابيات الكاذبة.

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