صار الانتقال من فكرة إلى تطبيق يعمل خلال أيام أمرًا معتادًا. فالنموذج الأولي المبني بـ Cursor أو Claude Code أو Lovable أو Bolt قد يبدو مثاليًا في العرض التجريبي. المشكلة أن المسافة بين "يعمل في العرض" و"يمكن فتحه لمستخدمين حقيقيين" غير مرئية.
نحاول في هذا المقال جعل تلك المسافة قابلة للقياس: ماذا تقول الأبحاث عن الكود المولَّد بالذكاء الاصطناعي، وما الثغرات الأكثر ظهورًا، وما الفحوص التي ينبغي إجراؤها قبل الإطلاق.
الكود الذي يعمل ليس بالضرورة كودًا آمنًا
النماذج اللغوية بارعة جدًا في كتابة كود يحقق السلوك المطلوب. لكن تلبية الطلب شيء، وضمان عدم إساءة استخدامه شيء آخر. اطلب "صفحة تعرض ملف المستخدم" وسيبني النموذج الصفحة. لكنه غالبًا لن يسأل "ماذا لو غيّر مستخدم آخر المعرّف في الرابط؟" ما لم تسأل أنت.
وطبيعة الـ vibe coding تضخّم ذلك. فحين يُقبل الكود دون قراءته سطرًا سطرًا، لا تُتخذ قرارات الأمان أصلًا. يعمل التطبيق لأن السيناريو الوحيد الذي اختبرته هو سيناريو المستخدم حسن النية.
ماذا تقول الأبحاث؟
لم يعد الأمر تخمينًا بل قياسًا. تبرز هنا دراستان.
اختبر تقرير Veracode لأمان كود الذكاء الاصطناعي التوليدي 2025 أكثر من 100 نموذج لغوي على مهام حساسة أمنيًا بلغات Java وJavaScript وPython وC#. وتبيّن أن 45% من عينات الكود المولَّدة أدخلت ثغرة من قائمة OWASP Top 10. وفي مهام cross-site scripting (XSS) ارتفع معدل الإخفاق إلى 86%.
أما تقرير CodeRabbit لعام 2025 فنظر في طلبات دمج حقيقية: 320 طلبًا بمساعدة الذكاء الاصطناعي مقابل 150 طلبًا كتبها بشر فقط. بلغ متوسط المشكلات في الطلبات المدعومة بالذكاء الاصطناعي 10.83، وفي الطلبات البشرية 6.45. وعلى مستوى الفئات يتضح الفارق أكثر:
| نوع الثغرة | في الكود المدعوم بالذكاء الاصطناعي |
|---|---|
| Cross-site scripting (XSS) | أكثر تكرارًا بـ 2.74 مرة |
| مرجع مباشر غير آمن للكائن (IDOR) | أكثر تكرارًا بـ 1.91 مرة |
| معالجة غير سليمة لكلمات المرور | أكثر تكرارًا بـ 1.88 مرة |
والأمانة مطلوبة هنا: العبارة المتداولة "كود الذكاء الاصطناعي فيه ثغرات أكثر بـ 2.74 مرة" تخص في الحقيقة فئة XSS وحدها. فالصورة العامة ليست "كل شيء أسوأ بثلاث مرات". لكن هناك ميلًا منهجيًا واضحًا في أنواع محددة من الثغرات، وهي بالضبط الأنواع الأعلى كلفة في الإنتاج.
قائمة تحقق من 8 نقاط قبل الإطلاق
تتكون هذه القائمة من أول ما ننظر إليه حين نستلم مشروعًا بُني بسرعة بالذكاء الاصطناعي. ويمكن فحصها كلها خلال تدقيق يستغرق أيامًا قليلة.
1. هل تسرّبت الأسرار إلى الكود أو إلى جهة العميل؟
مفاتيح API وسلاسل الاتصال بقاعدة البيانات وبيانات حسابات الخدمة هي أكثر مشكلة نصادفها. والمفاتيح المضمّنة في كود الواجهة الأمامية خصوصًا يمكن لأي أحد قراءتها من المتصفح. وافحص سجل git أيضًا: فالمفتاح المحذوف يبقى حيًا في سجل الـ commits.
2. هل يُتحقق من الصلاحيات على الخادم في كل طلب؟
المصادقة (من أنت) والتفويض (ما الذي يحق لك الوصول إليه) أمران مختلفان. إخفاء زر في الواجهة ليس تفويضًا. تحقق على الخادم في كل نقطة API من أن السجل المطلوب يخص هذا المستخدم. فثغرات IDOR تنشأ من هذه الفجوة تحديدًا.
3. هل قواعد الوصول إلى قاعدة البيانات مفتوحة؟
في المشاريع المبنية على خدمات مثل Supabase وFirebase يتحدث العميل مع قاعدة البيانات مباشرة. وحينها يكون خط الدفاع الوحيد هو قواعد الأمان على مستوى الصف (RLS في Supabase). والجدول بلا قواعد مفتوح لكل من يملك المفتاح المجهول.
4. هل تُتحقق مدخلات المستخدم وتُعقَّم؟
اعتبر كل بيانات تأتي من النماذج أو الروابط أو الواجهات البرمجية غير موثوقة. تحقق من المخطط على الخادم، وتجنب عرض HTML خام، واستخدم المعاملات في استعلامات قاعدة البيانات.
5. هل الاعتماديات حقيقية ومحدَّثة؟
تقترح النماذج أحيانًا أسماء حزم غير موجودة. ويمكن للمهاجمين تسجيل هذه الأسماء ووضع كود خبيث داخلها، ويُسمى هذا الهجوم "slopsquatting". تأكد أن كل اعتمادية جديدة هي فعلًا الحزمة المتوقعة، وشغّل فحصًا آليًا للثغرات المعروفة.
6. هل توجد حدود لمعدل الطلبات وحماية من إساءة الاستخدام؟
لا ينبغي فتح تسجيل الدخول والتسجيل واستعادة كلمة المرور، وخصوصًا النقاط التي تستدعي نموذجًا لغويًا، دون حد لمعدل الطلبات. وإلا فقد تستيقظ على محاولات استيلاء على الحسابات وفاتورة API غير متوقعة معًا.
7. هل تكشف رسائل الخطأ والسجلات أكثر من اللازم؟
في الإنتاج لا يجوز أن تُعاد للمستخدم تتبعات الأخطاء أو أخطاء SQL أو مسارات الملفات الداخلية. ولا يجوز أن تحتوي السجلات على كلمات مرور أو رموز وصول أو بيانات شخصية.
8. هل بيئة التطوير منفصلة عن بيئة الإنتاج؟
قاعدة بيانات منفصلة، ومفاتيح منفصلة، ونسخ احتياطية، وخطة للتراجع. ومن السيناريوهات الشائعة في مشاريع vibe code نقل قاعدة بيانات التطوير إلى الإنتاج كما هي.
قائمة التحقق وحدها لا تكفي
تلتقط هذه النقاط أكثر المشكلات شيوعًا، لكنها لا تغني عن تدقيق أمني. فالخطر الأكبر هو كود لم يفهمه أحد حقًا. وحين تُكتشف ثغرة، يحتاج من يصلحها إلى معرفة كيف يعمل النظام. تناولنا هذا بالتفصيل في مقال دين المعرفة.
ونضيف نقطة أخرى: كتابة الكود بالذكاء الاصطناعي ليست المشكلة. فمعظم الفرق تستخدم هذه الأدوات بالفعل، ومكسب السرعة حقيقي. المشكلة أن سرعة الإنتاج تتجاوز سرعة المراجعة. والحل ليس الإبطاء بل جعل المراجعة جزءًا من العملية: إضافة التحليل الساكن وفحص الاعتماديات إلى خط CI، وجعل مراجعة الكود إلزامية للنقاط الحرجة.
الخلاصة
الـ vibe coding أسرع طريقة لإخراج نموذج أولي خلال أيام. لكن قبل أن يتحول إلى منتج يحمل بيانات مستخدمين حقيقيين، يجب تحويل الكود الذي يعمل إلى كود آمن. والنقاط الثماني أعلاه هي نقطة البداية.
ننفذ تدقيق المشاريع المبنية بالذكاء الاصطناعي وتعزيز أمانها وإطلاقها ضمن خدمة Vibe Code to Production. ولإعداد الفحص الآلي وخطوط النشر راجع صفحة DevOps وCI/CD.
