Vibe Coding and Web Application Security: A Twin-Prompt Study
تُظهر هذه الدراسة الأولية أن إلحاق المتطلبات الأمنية صراحةً بالموجهات المكتوبة باللغة الطبيعية يقلل بشكل كبير من عدد الثغرات الأمنية المؤكدة في تطبيقات الويب المُنشأة بواسطة الذكاء الاصطناعي، حيث لم تحتوِ النسخ الواعية أمنياً على أي مشكلات حرجة أو عالية الخطورة مقارنة بنظيراتها الأساسية.
في العالم الرقمي الحديث، غالباً ما يتم بناء البرمجيات من خلال الطلب من الحاسوب أن يكتبها لنا. نحن نكتب وصفاً لما نريد — مدونة، أو متجراً، أو مدير مهام — ويقوم ذكاء اصطناعي قوي، تدرب على ملايين الأسطر من الأكواد، بتوليد التعليمات اللازمة لجعل ذلك يعمل. هذه الممارسة، التي تُسمى أحياناً "برمجة النبض" (vibe coding)، تعتمد على فكرة أن الآلة لا تفهم وظيفة البرنامج فحسب، بل تفهم أيضاً القواعد الخفية التي تحافظ على سلامته. ومع ذلك، يبقى هناك شك يلوح في الأفق: هل تضع الآلة بشكل طبيعي الأقفال والإنذارات الضرورية، أم أنها ببساطة تبني باباً يعمل دون الاهتمام بمن قد يحاول اقتحامه؟ إن الأمن في البرمجيات لا يقتصر فقط على جعل البرنامج يعمل؛ بل يتعلق بضمان بقاء الأسرار سرية، وعدم قدرة المستخدمين على التظاهر بأنهم أشخاص آخرون، وعدم السماح للنظام عن طريق الخطأ بدخول الغرباء. ومع ازدياد شيوع أدوات الذكاء الاصطناعي هذه، ينتقل السؤال من ما إذا كانت قادرة على بناء الكود، إلى ما إذا كانت قادرة على بناء كود آمن دون أن تُؤمر بذلك صراحة.
لقد شرع باحث في جامعة زغرب في الإجابة على هذا السؤال عبر معاملة الذكاء الاصطناعي كطالب قد يحتاج إلى تعليمات محددة للقيام بالشيء الصحيح. تضمنت الدراسة إنشاء ستة تطبيقات ويب مختلفة، تتراوح من مدونة بسيطة إلى متجر يحتوي على لوحة تحكم إدارية. ولكل تطبيق، طلب الباحث من الذكاء الاصطناعي بناءه مرتين. كان الطلب الأول عبارة عن وصف قياسي لما يجب أن يفعله البرنامج. أما الطلب الثاني فكان مطابقاً تماماً في كل شيء، باستثناء إضافة واحدة: قائمة واضحة من قواعد الأمن، مثل "لا تخزن كلمات المرور بنص صريح" و"تحقق من أن كل مستخدم هو بالفعل من يدعي أنه هو". سمح هذا الإعداد بإجراء مقارنة مباشرة بين نسخة بُنيت بوصف عام ونسخة بُنيت بتذكير أمني محدد، مع إبقاء كل شيء آخر — النموذج المستخدم، والأدوات، وعملية التوليد — متطابقاً تماماً.
ولمعرفة ما حدث، لم يكتفِ الباحث بالنظر إلى الكود فحسب؛ بل أخضع جميع التطبيقات الاثني عشر لسلسلة صارمة من الاختبارات. استخدم ماسحات آلية تقرأ الكود المصدري بحثاً عن أنماط خطيرة، وأدوات فحصت البرمجيات أثناء تشغيلها لمعرفة ما إذا كان يمكن خداعها، وجولة أخيرة من الاختبار اليدوي حيث حاول خبير بشري اختراق الأنظمة باستخدام أساليب إبداعية قد تغفل عنها الآلات. كانت النتائج مذهلة. فالنسخ التي بُنيت مع التذكير الأمني احتوت على مشاكل أقل بكثير من النسخ الأساسية. وفي الواقع، لم تكن النسخ الآمنة تحتوي على أي ثغرات أمنية حرجة أو عالية المستوى، بينما عانت النسخ التي بدون التذكير من مشكلات خطيرة، بما في ذلك ثغرات قد تسم تسمح للمهاجم بالسيطرة على حساب مستخدم أو الوصول إلى بيانات خاصة. لم يجعل التذكير البرمجيات مثالية؛ فقد ترك خلفه بعض مشكلات الإعدادات البسيطة الشائعة في كلتا النسختين، لكنه نجح في القضاء على الأخطاء الأكثر خطورة.
كما كشفت الدراسة أن العثور على هذه العيوب ليس مهمة أداة واحدة. فالماسحات الآلية التي قرأت الكود وجدت العديد من المشكلات التي غفلت عنها الماسحات التي تراقب البرامج أثناء تشغيلها، والعكس صحيح. والأهم من ذلك، أن الثغرة الأكثر خطورة التي وُجدت في التجربة بأكملها — وهي ثغرة تسمح للمهاجم بتزوير هوية رقمية والسيطرة على حساب — لم تكتشفها أي من الأدوات الآلية. لقد تم اكتشافها فقط عندما قام إنسان باختبار النظام يدوياً. وهذا يشير إلى أنه بينما يساعد الطلب من الذكاء الاصطناعي أن يكون آمناً، إلا أنه لا يحل محل الحاجة إلى الإشراف البشري وطبقات متعددة من الفحص. وأشار الباحث إلى أنه نظراً لأن هذه كانت تجربة صغيرة مع تشغيل واحد فقط لكل تطبيق، فإن النتائج هي مجرد اقتراح قوي وليست إثباتاً نهائياً، لكن النمط كان ثابتاً في كل حالة على حدة. ويعمل هذا العمل كخطوة أولية، توضح أن طلباً بسيطاً وصريحاً للأمن يمكن أن يحسن بشكل كبير من سلامة البرمجيات التي يولدها الذكاء الاصطناعي، حتى وإن لم يكن قادراً على رصد كل خطأ بمفرده.
ملخص تقني: برمجة الـ "Vibe Coding" وأمن تطبيقات الويب
بيان المشكلة
إن الاعتماد السريع على النماذج اللغوية الكبيرة (LLMs) لتوليد تطبيقات ويب قابلة للتشغيل من أوصاف باللغة الطبيعية — وهي ممارسة تُسمى "برمجة الـ Vibe" (vibe coding) — يفوّض قرارات أمنية حرجة (مثل المصادقة، ومعالجة المدخلات، والتحكم في الوصول) إلى نماذج مُحسّنة في المقام الأول من أجل الصحة الوظيفية. وبينما يمكن للممارسين إلحاق متطلبات أمنية صريحة بالموجهات (prompts)، لا يزال من المسائل المفتوحة ما إذا كان "التوجيه الواعي أمنياً" يحسن بشكل ملموس الوضع الأمني للكود المولد مقارنة بالموجهات الأساسية. تقدم الأدبيات الحالية أدلة مختلطة: تشير بعض الدراسات إلى أن تلميحات الأمان الخفيفة لها تأثير ضئيل، بينما تشير دراسات أخرى إلى أن الصقل المتكرر قد يؤدي أحياناً إلى زيادة الثغرات الحرجة. هناك نقص في المقارنات المنضبطة على مستوى التطبيقات الكاملة والقابلة للنشر حيث يتم تثبيت المهمة، والنموذج، والبيئة، مع تغيير الموجه فقط.
المنهجية
تستخدم هذه الدراسة تصميماً ثنائي الموجهات لعزل تأثير المتطلبات الأمنية.
المجموعة (Corpus): تم توليد ستة تطبيقات ويب متميزة وظيفياً (تتنوع بين Python/Flask، وPython/FastAPI، وJavaScript/Express). تم إنشاء كل تطبيق مرتين، مما نتج عنه 12 برنامجاً إجمالاً.
متغيرات الموجه (Prompt Variants):
المتغير (أ) (الأساسي): مواصفات محايدة تصف الوظائف، والنقاط الطرفية (endpoints)، ونماذج البيانات، دون أي ذكر للأمن.
المتغير (ب) (الواعي أمنياً): مطابق تماماً للمتغير (أ) من حيث المحتوى، مع إضافة قسم يحتوي على متطلبات أمنية عامة مستمدة من قائمة OWASP Top 10 (2021). هذا القسم كان غير مرتبط بتطبيق معين وغير مضبوط (untuned).
قيود التوليد: تم توليد جميع الأكواد بواسطة Claude Code (باستخدام نموذج Claude Opus 4.8) في جولة واحدة غير تكرارية. لم تُستخدم تعليمات مخصصة، أو حلقات نقد ذاتي، أو نماذج حكم (judge models). تم تصميم بنية التوليد لتكون بسيطة للغاية لتمثيل سير عمل الممارس في "خطوة واحدة".
الضوابط:
استُخدمت ملفات Dockerfile متطابقة ومحايدة أمنياً لجميع المتغيرات لضمان عدم تأثير اختلافات تكوين الحاوية على النتائج.
لم تُجرَ أي تعديلات يدوية بعد التوليد.
تم التحقق من التكافؤ الوظيفي عبر اختبارات التدخين (smoke testing) لضمان تلبية كلا المتغيرين للمواصفات.
مسار التحليل: تم استخدام نهج متعدد الأساليب للكشف عن الثغرات:
التحليل الساكن (SAST): باستخدام Bandit وESLint وSemgrep.
تحليل التبعيات (SCA): باستخدام pip-audit وnpm audit.
التحليل الديناميكي (DAST): باستخدام OWASP ZAP (الفحص السلبي، والنشط، وفحص الـ API) وNikto.
الاختبار اليدوي: اختبار مستهدف للضعف المرتبط بالدلالات (semantics) (مثل: IDOR، وإساءة استخدام منطق العمل، وتزوير الرموز/tokens) باستخدام sqlmap وسكريبتات مخصصة.
تجميع البيانات: تم توحيد 249 نتيجة خام من الأدوات، وإزالة التكرار حسب فئة الثغرة، والمراجعة يدوياً لإنتاج 75 نتيجة مؤكدة (كانت هناك 10 نتائج إيجابية كاذبة).
المساهمات الرئيسية
مجموعة بيانات قابلة لإعادة الإنتاج: مجموعة من 12 تطبيقاً مولداً بواسطة LLM (6 أزواج) مع مسار تحليل كامل وشفاف.
مجموعة نتائج موثقة: مجموعة بيانات من 75 ثغرة مؤكدة بعد إزالة التكرار، مصنفة وفقاً لـ OWASP Top 10 وCWE.
أدلة وصفية: ملاحظة تجريبية لتأثير التوجيه الواعي أمنياً في عملية توليد بـ "خطوة واحدة"، على عكس الاختبارات المعيارية التي تغير النماذج أو المهام.
التحقق من المنهجية: إثبات التكامل بين SAST وDAST والاختبار اليدوي في اكتشاف ثغرات الكود المولد بواسطة LLM.
النتائج
التقليل من الثغرات: أنتج المتغير الواعي أمنياً (ب) عدداً أقل من النتائج المؤكدة في كل تطبيق مقارنة بالمتغير الأساسي (أ).
إجمالي النتائج: 51 في المتغير (أ) مقابل 24 في المتغير (ب).
المتوسط لكل تطبيق: 8.5 (أ) مقابل 4.0 (ب).
تحول الخطورة: لم يحتوي المتغير (ب) على أي نتائج مؤكدة ذات خطورة حرجة (Critical) أو عالية (High). كانت جميع النتائج (2 حرجة و11 عالية) موجودة فقط في المتغير (أ). أما النتائج المتبقية في المتغير (ب) فكانت في الغالب تتعلق بمشاكل تكوين منخفضة الخطورة.
فئات الثغرات: كانت أكثر النتائج المؤكدة شيوعاً هي سوء التكوين الأمني (A05)، تليها كسر التحكم في الوصول (A01) وفشل تحديد الهوية والمصادقة (A07).
تكامل الكشف: كانت طرق الكشف الثلاث غير متداخلة إلى حد كبير.
28 نتيجة وجدها SAST فقط.
24 نتيجة وجدها DAST فقط.
11 نتيجة وجدها الاختبار اليدوي فقط.
12 نتيجة فقط تم تأكيدها بواسطة عدة طرق.
نتيجة حاسمة: أخطر مشكلة (تزوير JWT يسمح بالاستيلاء على الحساب في النسخة الأساسية) تم اكتشافها فقط بواسطة الاختبار اليدوي؛ حيث أخفقت الماسحات الآلية في رصدها. وعلى العكس من ذلك، فإن أخطر تنبيه آلي (حقن SQL) كان نتيجة إيجابية كاذبة.
اختلافات اللغة: أظهرت تطبيقات Python متوسط نتائج أعلى (14.25) من تطبيقات JavaScript (9.0)، رغم أن المؤلف يشير إلى أن هذا يتأثر بعدم التساوي في عدد التطبيقات والاختلافات الوظيفية، مما يمنع استخلاص استنتاج نهائي على مستوى اللغة.
الأهمية والادعاءات
تضع هذه الورقة نفسها كـ دراسة أولية تهدف إلى تأسيس والتحقق من مسار عمل بدلاً من تقديم آثار سببية مثبتة إحصائياً. ويذكر المؤلف صراحة أنه نظراً لصغر حجم العينة (ستة تطبيقات، وجولة توليد واحدة لكل متغير)، فإن النتائج هي ملاحظات وصفية وليست إثباتات ذات دلالة إحصائية.
تكمن الأهمية الأساسية في ملاحظة أن مجرد إضافة موجه أمني بسيط وغير مضبوط إلى مواصفات أساسية يمكن أن يقضي على جميع الثغرات ذات الخطورة الحرجة أو العالية في عملية توليد بـ "خطوة واحدة". وهذا يتناقض مع بعض أدبيات الاختبارات المعيارية التي تشير إلى أن التلميحات الخفيفة غير فعالة، وإن كان المؤلف يعزو هذا الاختلاف إلى شمولية قسم المتطلبات المستمد من OWASP المستخدم هنا مقارنة بـ "التحفيزات" الموجزة في الدراسات الأخرى.
كما تسلط الدراسة الضوء على الضرورة القصوى للاختبار اليدوي والتحليل متعدد الأساليب، حيث كانت أخطر ثغرة حقيقية غير مرئية للأدوات الآلية، بينما كان أخطر تنبيه آلي هو نتيجة إيجابية كاذبة. ويخلص المؤلف إلى أنه بينما يظهر التوجيه الواعي أمنياً بوادر واعدة، يجب على العمل المستقبلي معالجة التباين بين عمليات التشغيل من خلال تكرار جولات التوليد، والتوسع ليشمل نماذج متعددة، ومقارنة الموجهات ذات "الخطوة الواحدة" مقابل بنيات التكرار الصقلية.