اطلب من وكيل برمجة بالذكاء الاصطناعي نقطة رفع ملفات وسيمنحك واحدة. الكود يُترجم بلا أخطاء. العرض التجريبي يعمل. وطلب الدمج يبدو أنيقاً في السادسة مساءً. وفي مكان ما داخله ثغرة path traversal لن يلاحظها أحد حتى يقرر أحدهم أن ينظر.
هذا لم يعد قلقاً نظرياً. إنه نتيجة مقيسة، والرقم غير مريح: أفضل وكيل برمجة في اختبار جديد تماماً أنتج كوداً يعمل وآمناً معاً في 25.1% فقط من المهام.
رقم الـ 25% ولماذا يجب أن يقلقك
في 14 أكتوبر، قدّمت ورقة نُشرت على Hugging Face ما يُعرف بـ Last Secure Code Benchmark (LSCB)، بعنوان فرعي «Is the Code You Vibe Secure?». التصميم بسيط بقسوة، وواقعي هذه المرة. أخذ الباحثون 150 ثغرة حقيقية، ووسّعوها إلى 450 مهمة موزعة على ثلاثة سيناريوهات للبرمجة بالذكاء الاصطناعي، ثم أطلقوا عليها ستة وكلاء من الطراز الأول، بسبع لغات من بينها Java و C و C++ و JavaScript و Python و PHP و Go. وتغطي الضعف مراقبة 24 نوعاً من CWE، من بينها 21 من قائمة CWE Top 25 لعام 2025 و8 من قائمة أفضل 10 للثغرات المستغَلة فعلياً.
تنقسم النتائج إلى رقمين يحكيان قصتين مختلفتين تماماً:
- وظيفياً، يبدو الوكلاء ممتازين. بين 73.6% و91.3% من المهام تجتاز اختبارات الوظائف المخفية. الكود يفعل ما طُلب منه.
- وظيفياً وآمناً في الوقت ذاته، تنهار الصورة. أقوى وكيل، Claude Fable 5، يصل إلى 25.1%. أما الخمسة الآخرون فيتراوحون بين 16.4% و24.7%.
ولأن نسب النجاح الوظيفي أعلى بكثير، فإن معظم هذا الفشل يتعلق بالأمان وليس بتعطل الكود. الكود يعمل، والميزة تُعرض، والثغرة تُنشر. ويضيف الباحثون أن أفضل نموذج لا يجتاز سوى 12% من سيناريوهات الثغرات في جميع بيئات البرمجة بالذكاء الاصطناعي.
كيف بُني الاختبار ولماذا هو منصف
أهم قرار في التصميم هو ما تتجاهله التعليمات. كل مواصفة مهمة تطلب وظيفة فقط ولا تذكر الأمان إطلاقاً. وهذا يحاكي طريقة تكليف الفرق للوكلاء فعلاً: أضف نقطة رفع ملفات، لا أضف نقطة رفع ملفات تقاوم path traversal.
ثم قُيّمت كل مهمة من المهام الـ450 مرتين عبر اختبارات مخفية. مجموعة تتحقق مما إذا كان الكود يفعل ما طُلب. ومجموعة ثانية تتحقق مما إذا كان يتجنب الضعف المحدد الذي تمثله الثغرة الحقيقية الأصلية. واستخدام ثغرات حقيقية بدلاً من أخطاء مصطنعة مهم، والاختبارات المخفية تقلل احتمال أن يخدع النموذج مدققاً ظاهراً للعيان.
ويستحق الأمر أن نبقى صادقين في التحفظات، لأن الباحثين كانوا حريصين عليها. الاختبار يقيس السلوك الافتراضي: لم تُعطَ النماذج تعليمات أمنية ولا مهارة برمجة آمنة ولا حلقة مراجعة. ومن المرجح أن يحقق الوكلاء الذين يتلقون متطلباً أمنياً صريحاً ومرور مراجعة آلية نتائج أفضل بكثير. واجتياز المهمة يعني أن الكود تجنب الضعف الذي جرى اختباره، لا أن كل سطر آخر فيه آمن. وبيئات الوكلاء تتغير شهرياً، لذا هذه لقطة لحظية وليست حكماً نهائياً.
هذه ليست نتيجة معزولة
لو كان LSCB الدراسة الوحيدة التي تشير إلى هذا الاتجاه، لكان من السهل تصنيفه كعنوان مثير ومواصلة الطريق. لكنه ليس كذلك. اختبر تحديث Veracode لربيع 2026 حول أمان الكود المولَّد بالذكاء الاصطناعي أكثر من 150 نموذجاً عبر 80 مهمة برمجية بأربع لغات، مع التحقق بالتحليل الساكن، فوجد الشكل نفسه من المشكلة:
- الصحة النحوية: أكثر من 95%
- نسبة النجاح الأمني دون تعليمات أمنية: نحو 55%
- هجمات cross-site scripting: نحو 15%
- حقن السجلات (log injection): نحو 13%
- حقن SQL: 82%
- عامان من إصدارات النماذج: من نحو 55% إلى نحو 55%
السطر الأخير هو ما يستحق التوقف. كل إصدار في تلك الفترة قُدّم كقفزة إلى الأمام، وعلى هذا المقياس لم تتحرك المؤشرة. أما النماذج التي تركز على الاستدلال فجاءت أفضل بنحو 70-72%، وهو تحسن حقيقي ومع ذلك يظل شيئاً لا يُنشر دون مراجعة. والأمر مشابه على مستوى المستودع: أفاد اختبار SusVibes بأن معظم حلول الوكلاء التي نجحت وظيفياً كانت غير آمنة، وأفضل نتيجة معلنة عند حوالي 11.8% صحيحة وآمنة.
نمط الفشل الثاني: حزم لا وجود لها
أخطاء الأمان هي المخاطر الواضحة. أما الأغرب فهي سلسلة التوريد، وقد أصبحت هجوماً صامتاً.
وجدت دراسة أنتجت 576 ألف عيّنة برمجية عبر 16 نموذجاً أن 19.7% من الحزم الموصى بها غير موجودة، بما يزيد على 205 آلاف اسم مبتكر. وقد هلوس النماذج المفتوحة بنسبة 21.7% في المتوسط، والتجارية بنسبة 5.2%. النسبة ليست الجزء المثير. المثير هو التالي: عند تكرار التعليمات نفسها عشر مرات، عاد 43% من أسماء الحزم المهلوسة في كل مرة. الابتكارات منهجية وليست عشوائية.
والاسم القابل للتوقع هو اسم يمكن لشخص ما تسجيله قبل أن تطلبه. هذا الهجوم له الآن اسم، slopsquatting، وقد أظهره أحد الباحثين بنشر حزمة فارغة تحت اسم مهلوس معقول، فجرى تنزيلها عشرات الآلاف من المرات. والآن سلّم تثبيت التبعيات إلى وكيل مستقل، وستختفي بهدوء نقطة التحقق البشرية الوحيدة في تلك السلسلة: ملاحظة اسم الحزمة والقرر بتثبيتها.
ما ننصح به عملاءنا
لا شيء من هذا يعني التباطؤ أو التخلي عن مكاسب الإنتاجية. إنه يعني تغيير المكان الذي يتوجه إليه الاهتمام البشري. خمس قواعد نستخدمها:
- سمّ الخطر في التعليمة قبل وجود أي كود. هذا التغيير يمس بيانات المستخدمين وتسجيل الدخول: اذكر متطلبات الأمان أولاً، وسنبني وفق تلك القائمة. تكلفة ذلك جملة واحدة، ويشير الاختبار إلى أنها أهم من اختيار النموذج.
- تحقق من الفئات التي تفشل فعلاً. لا تسأل: هل هذا آمن؟ لأنك ستحصل على مقال طويل. اسأل تحديداً عن المخارج التي تصل إلى الصفحة دون تهريب، وعن مدخلات المستخدم التي تصل إلى السجل أو الاستعلام دون فحص، وعن كل شيء يُبنى بدمج النصوص.
- تعامل مع كل تبعية جديدة كحدث في سلسلة التوريد. لكل حزمة: هل توجد في السجل الرسمي، من ينشرها، متى نُشرت أول مرة، كم عدد إصداراتها. أنت لا تدقق الكود، بل تتحقق مما إذا كان لهذا الشيء ماضٍ.
- أبقِ بوابة بشرية عند الفرق (diff). الوكلاء ينتجون كوداً أكثر، لا برمجيات أكثر مراجعة. المراجعة هي عنق الزجاجة الآن، وهي أرخص ضابط تملكه.
- افترض أن الإعدادات الافتراضية غير آمنة وراقب ذلك. أضف SAST وفحص التبعيات إلى خط الإنتاج بدلاً من الاعتماد على حرص الوكيل.
الخلاصة لفريقك
حلّت البرمجة الوكيلة مسألة التوليد. أما ما لم يُحل بعد فهو الصحة والأمان، وهذا الجزء غير المحلول كان بالضبط ما يُدفع للمهندسين مقابله. والفرق التي ستكسب العامين المقبلين ليست تلك التي تكتب أفضل تعليمة، بل تلك التي تلتقط خطوط إنتاجها ما تركه الوكيل: متطلبات تُكتب قبل التعليمة، وفحص آلي بعدها، ومراجع يعرف أربع أو خمس فئات من الضعف تتكرر مرة بعد مرة.
السرعة أصبحت الحد الأدنى. أما ما ينجو من المراجعة والماسح واختبار الاختراق، فهو المنتج.