في زمن تزايد الاعتماد على نماذج اللغات الضخمة (LLMs) في عمليات تطوير البرمجيات، فإن السؤال الذي يطرح نفسه هو: هل يمكن لهذه النماذج إنتاج كود مصادقة آمن بشكل مستقل؟

دراسة جديدة، عُرضت على منصة أرشيف الأبحاث arXiv، قامت بتحليل بنية الأمان لأنظمة المصادقة التي تنتجها خمسة من أبرز المساعدين البرمجيين المعتمدين على الذكاء الاصطناعي، مستخدمةً إطار عمل تقييم ثنائي الأبعاد يجمع بين تحليل الكود الثابت واختبار الاختراق الديناميكي، وفقًا لإرشادات معهد المعايير والتكنولوجيا الوطني (NIST SP 800-63B).

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

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

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