الذكاء الاصطناعي يكتب الكود ويثبّت الحزم: 5 فحوصات قبل إطلاق التطبيق في بيئة الإنتاج

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

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

بالنسبة إلى المطوّر، هذا سبب لإعادة النظر في مراجعة الكود. وبالنسبة إلى مدير المنتج والمؤسس، هو دعوة لإضافة عدة فحوصات إلى معيار «العرض التجريبي يعمل»، فبدونها يظل الإصدار أشبه باليانصيب.

ابدؤوا بملف مستخدم آخر

أكثر الفحوصات فائدة تبدو غالبًا مملّة. هل يستطيع المستخدم قراءة طلب شخص آخر بتغيير المعرّف في الطلب؟ هل الجدول متاح دون تفويض؟ وهل يصل الاسم المُدخل مباشرة إلى HTML؟

يورد المقال مثال تطبيق على Supabase. وجود مفتاح عام في الواجهة الأمامية لا يعني بحد ذاته تسريبًا: إذ يجب أن تقيّد سياسات Row Level Security الوصول إلى الصفوف. ويقع الخطأ عندما يكون التطبيق متصلًا بقاعدة البيانات بينما قواعد الوصول لم تُضبط بعد أو تسمح بأكثر من اللازم.

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

يساعد التحليل الساكن في البحث عن العمليات الخطرة وتسريبات الأسرار. لكنه عادةً لا يستطيع، دون قواعد منتجكم، أن يحدد من يحق له قراءة طلب بعينه. وهنا تلزم المراجعات وفحوصات التفويض.

الاعتمادية تبدأ بالتحقق من الاسم

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

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

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

كذلك لحظر سكربتات التثبيت حدود: فقد تنفّذ المكتبة كودًا خبيثًا لاحقًا، عندما يستورِدها التطبيق. وقد يفوّت ماسح الثغرات المعروفة منشورًا خبيثًا حديثًا. وهذه التدابير تكمّل التحقق من مصدر الحزمة.

الوكيل يحتاج إلى حدود صلاحيات

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

الجواب العملي هو منح الوصول بحسب المهمة. فلإصلاح واجهة المستخدم لا تلزم عادةً أسرار الإنتاج ولا حق نشر الحزم. وأوامر تثبيت الاعتماديات والوصول إلى الأسرار وتغيير البنية التحتية تستحق رقابة منفصلة.

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

ويبقى التحليل نفسه مراجعة عامة: فالأمثلة والدراسات المنفردة لا تتيح حساب احتمال اختراق خدمتكم تحديدًا. كما أن طلب «افحص الأمان» من النموذج لا يمنح ضمانًا. وتظهر النتيجة المفيدة حين يحوّل الفريق التوصيات إلى شروط إصدار قابلة للتحقق ويعيّن مسؤولًا عن كل منها.