💻 computer science

Leveraging Large Language Models for Trustworthiness Assessment of Web Applications

تقترح هذه الورقة منهجية تجريبية تسخر النماذج اللغوية الكبيرة لأتمتة تقييم موثوقية تطبيقات الويب من خلال التحقق من ممارسات الترميز الآمن ودمج مخرجاتها في نموذج جودة هرمي لتوليد درجة موثوقية شاملة.

المؤلفون الأصليون: Oleksandr Yarotskyi, José D'Abruzzo Pereira, João R. Campos

نُشر 2026-03-26

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

CC BY 4.0

المؤلفون الأصليون: Oleksandr Yarotskyi, José D'Abruzzo Pereira, João R. Campos

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

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

في العالم الرقمي، تسمى هذه "السلامة" بـ الموثوقية (Trustworthiness).

لسنوات طويلة، كان التحقق مما إذا كان المطعم آمنًا يشبه استئجار فريق من مفتشي الصحة ذوي الخبرة الفائقة للمرور عبر المطبخ، وتذوق كل طبق، وقراءة كل كتاب وصفات. كانت هذه العملية بطيئة، ومكلفة، ويصعب توسيع نطاقها. فإذا افتتحت 1,000 مطعم جديد يوميًا، فلن تتمكن من توظيف 1,000 مفتش.

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

إليك قصة كيف حاولوا ذلك، وما الذي سار بشكل خاطئ، وما الذي نجح في النهاية.

المشكلة: "قائمة التحقق" صعبة للغاية

تقليديًا، تبحث أدوات الأمن عن "أخطاء" محددة (مثل قفل مكسور على باب). ولكن ماذا لو كان القفل سليمًا، لكن الطاهي كسول فقط وترك الباب الخلفي مفتوحًا؟ هذه مشكلة ممارسة برمجة آمنة (Secure Coding Practice).

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

التجربة: المفتش الآلي

قرر الباحثون اختبار خمسة "مفتشين" مختلفين من الذكاء الاصطناعي (مثل GPT-4، Gemini، إلخ) لمعرفة ما إذا كان بإمكانهم قراءة الكود والتحقق مما إذا كان الطهاة يتبعون القواعد. ركزوا على قاعدة واحدة محددة: التحقق من المدخلات (Input Validation) (التأكد من عدم تسلل أي شخص بمكونات ملوثة إلى المطبخ).

لقد جربوا أربع طرق مختلفة للتحدث مع الذكاء الاصطناعي (تسمى استراتيجيات التلقين - Prompting Strategies):

1. نهج "اسأل فقط" (الأساس - Baseline)

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

2. نهج "أرني الأمثلة السيئة" (التعلم من أمثلة قليلة - Few-Shot)

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

3. نهج "أرني المطبخ بأكمله" (السياق الهيكلي - Structural Context)

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

4. نهج "كتيب القواعد الصارم" (القائم على القواعد - Rule-Based)

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

النتيجة النهائية: "درجة الثقة"

لم يرد الباحثون من الذكاء الاصطناعي أن يقول فقط "نعم" أو "لا". بل أرادوا درجة ثقة (Trust Score) (من 0 إلى 100) للتطبيق بأكل.

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

النتائج الرئيسية

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

لماذا هذا مهم؟

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

إليك ملخص تقني مفصل للورقة البحثية بعنوان "استغلال النماذج اللغوية الكبيرة لتقييم موثوقية تطبيقات الويب".

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

تعد أمن تطبيقات الويب أمراً بالغ الأهمية، ومع ذلك تواجه طرق التقييم التقليدية قيوداً كبيرة:

القيود المتمحورة حول الثغرات: تركز الأدوات الحالية (SAST، DAST) على اكتشاف الثغرات المعروفة. وغالباً ما تفشل في تحديد نقاط الضعف الكامنة أو ضمان الموثوقية في حال عدم وجود ثغرة محددة (CVE).
مشكلات القابلية للتوسع: يعتمد تقييم الالتزام بـ ممارسات البرمجة الآمنة (وهو نهج استباقي للموثوقية) حالياً على مراجعات الكود اليدوية من قبل الخبراء. وهذا الأمر يستغرق وقتاً طويلاً، ويتسم بالذاتية، ويصعب توسيعه ليتناسب مع مسارات التطوير الحديثة (CI/CD).
الفجوات السياقية: تفتقر أدوات التحليل الساكن غالباً إلى الفهم الدلالي المطلوب للتحقق من ممارسات البرمجة المعقدة (مثل منطق التحقق من المدخلات الذي يمتد عبر دوال متعددة)، مما يؤدي إلى ارتفاع معدلات الإنذارات الكاذبة (الإيجابية أو السلبية).

التحدي الجوهري هو أتمتة تقييم الموثوقية — المعرفة بأنها درجة الالتزام بمعايير البرمجة الآمنة — دون التضحية بالدقة أو القابلية للتوسع.

2. المنهجية

يقترح المؤلفون إطار عمل تجريبي يدمج النماذج اللغوية الكبيرة (LLMs) مع نموذج جودة هرمي (QM) يعتمد على درجة المنطق للتفضيل (LSP).

أ. مجموعة البيانات والنطاق

مجموعة البيانات: تستخدم الدراسة WSVD-Bench، وهي معيار عام يحتوي على 21 خدمة ويب بلغة Java تضم 80 عملية و158 ثغرة موثقة من نوع حقن SQL. وتتضمن نسخاً آمنة (Vx0) وأخرى معرضة للثغرات (VxA).
التركيز: ينصب تقييم النطاق على ممارسات التحقق من صحة المدخلات (OWASP Input Validation) (16 ممارسة محددة من دليل مرجع OWASP السريع لممارسات البرمجة الآمنة)، وهو مجال حيوي لمنع عيوب الحقن.
الحقيقة الأرضية (Ground Truth): تم إنشاء مجموعة بيانات منسقة يدوياً بواسطة خبراء أمنيين، حيث تم تصنيف 42 دالة لـ 16 ممارسة بثلاث حالات: متبعة (1)، غير متبعة (0)، أو غير قابلة للتطبيق (NA).

ب. التصميم التجريبي

تقيم الدراسة خمسة من أحدث النماذج اللغوية الكبيرة (gpt-3.5-turbo, gpt-4o-mini, gpt-4.1-mini, gpt-4.1, gemini-2.5-flash) باستخدام أربع استراتيجيات مختلفة لهندسة الأوامر (Prompt Engineering):

الأساس (Zero-Shot): يوفر فقط وصف الممارسة والكود البرمجي.
CWE + الأمثلة السيئة (Few-Shot): يضيف خرائط Common Weakness Enumeration (CWE) وأمثلة كود سلبية لتوجيه التعرف على الأنماط.
سياق استدعاء الدالة (Function Call Context): يعزز الأمر بكود الدوال المساعدة المستدعاة (المستخرجة عبر Joern) لتتبع المنطق عبر الإجراءات (inter-procedural logic).
القائم على القواعد (Rule-Based): يستبدل الأسئلة المفتوحة بمنطق قرار ثنائي صارم وخطوة بخطوة (على سبيل المثال: "إذا كان X، إذن متبعة؛ وإلا فهي غير متبعة").

ج. تجميع الموثوقية

للانتقال لما وراء التصنيف الثنائي، تستخدم الدراسة نهجين لـ RQ3:

التقدير المدفوع بالنماذج اللغوية (LLM-Driven Estimation): طلب توليد درجة موثوقية عددية (0–1) مباشرة من النموذج اللغوي.
تجميع QM + LSP: استخدام المخرجات الثنائية للنماذج اللغوية كمدخلات لـ نموذج جودة (Quality Model) رسمي. يستخدم النموذج درجة المنطق للتفضيل (LSP) مع عامل "التزامن الضعيف" ( $r = -1$ ). يضمن هذا أن فقدان ممارسة أمنية حرجة يخفض الدرجة الإجمالية بشكل كبير، مما يعكس مبدأ "أضعف حلقة". يتم اشتقاق أوزان الممارسات تجريبياً من بيانات الثغرات الواقعية (أعداد CVE).

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

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

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

RQ1: الأداء الأساسي

النتائج: يختلف أداء النموذج الأساسي (zero-shot) بشكل كبير حسب النموذج. حقق gpt-4.1 أعلى درجة Macro F1 بلغت (0.89)، بينما عانت النماذج الأصغر مثل gpt-3.5-turbo (F1 ~0.52).
القصور: تؤدي النماذج الأساسية أداءً جيداً في الفحوصات النحوية المحلية ولكنها تفشل في المهام التي تتطلب استدلال تدفق التحكم أو السياق المعماري (مثل التحقق مما إذا كان منطق التحقق ينهي التنفيذ).

RQ2: تأثير استراتيجيات الأوامر

السياق الدلالي (Prompt 2): حسن الأداء للنماذج ذات السعة العالية (ارتفع F1 لـ gpt-4.1 إلى 0.93) ولكنه تسبب في تراجع للنماذج الأصغر (مثل gemini-2.5-flash الذي انخفض إلى 0.68) بسبب "الحمل السياقي الزائد".
السياق الهيكلي (Prompt 3): تأثير سلبي. أدى إضافة كود الدوال المساعدة الخام إلى إدخال ضوضاء، مما قلل من الاستدعاء (Recall) في جميع النماذج. حتى gpt-4.1 انخفض F1 الخاص به من 0.89 إلى 0.75، حيث فشلت النماذج في تصفية الكود ذي الصلة، مما أدى إلى تفويت عمليات الكشف.
الأوامر القائمة على القواعد (Prompt 4): الاستراتيجية الأكثر متانة. حسنت التعليمات الصريحة خطوة بخطوة الأداء بشكل كبير للنماذج المتوسطة والصغيرة.
- شهد gpt-4o-mini أكبر مكسب (+0.1288)، ليصل إلى F1 قدره 0.74.
- تحسن gpt-4.1-mini ليصل إلى 0.84.
- عوضت هذه الاستراتيجية بفعالية عن ضعف قدرات الاستدلال، مما جعل النماذج خفيفة الوزن صالحة للتقييم الأمني.

RQ3: موثوقية تسجيل الموثوقية

التسجيل المباشر بالنماذج اللغية: فشلت النماذج اللغية في توليد درجات شمولية موثوقة (متوسط الخطأ المطلق 0.40–0.60). لم تستطع النماذج دمج أوزان المعايير والأهمية بشكل ضمني.
تجميع QM + LSP: عندما تم تغذية المخرجات الثنائية للنماذج اللغية في نموذج LSP الرسمي، نجح النظام في التمييز بين الكود الآمن والمعرض للثغرات.
- الدلالة الإحصائية: أكدت اختبارات Mann-Whitney U أن استراتيجية القواعد (Prompt 4) خلقت فصلاً ذا دلالة إحصائية بين توزيعات الكود الآمن والمعرض للثغرات ( $p < 0.05$ ).
- القدرة التمييزية: قلل نهج LSP من التشتت وألغى التداخل بين توزيعات درجات الكود الآمن والمعرض للثغرات، على عكس نهج السياق غير المنظم.

5. الأهمية والخاتمة

القابلية للتوسع: تثبت الدراسة أن تقييم الموثوقية يمكن أتمتته وتوسيع نطاقه ليتناسب مع مسارات التطوير الحديثة، مما يزيل عقبة المراجعة اليدوية للكود.
كفاءة التكلفة: من خلال إثبات أن الأوامر القائمة على القواعد تسمح للنماذج الأصغر والأسرع والأرخص (مثل gpt-4o-mini) بتحقيق دقة تقارب النماذج الأكبر، فإن النهج يعد مجدياً اقتصادياً لعمليات التكامل المستمر.
التحول المنهجي: تدعو الورقة إلى تحول من "عد الثغرات" إلى "تقييم الالتزام بالممارسات" باستخدام منهج هجين (ذكاء اصطوي-رسمي).
العمل المستقبلي: يخطط المؤلفون لتوسيع هذا الإطار ليشمل لغات برمجة أخرى، وأنواع ثغرات مختلفة، ودمجه مباشرة في مسارات CI/CD للمراقبة الأمنية المستمرة.

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