Vibe-Code to Production

يخرج التطبيق اليوم من بضع جمل تعليمات في ساعات قليلة: تُطلب ميزة في Cursor، وتُصمَّم واجهة في Lovable، وتنهض خلفية في Replit، ويربط Codex أو Claude Code تكاملا ما. الشاشات تعمل، والنموذج يحفظ البيانات، وتسجيل الدخول جاهز. لكن النموذج الذي كتب هذا الكود كان يحسّن إنهاء الطلب لا الصمود في الإنتاج. ووجد تقرير Veracode لعام 2025، الذي اختبر أكثر من مئة نموذج، أن 45 بالمئة من الكود المولّد يحمل ثغرة من قائمة OWASP Top 10، وحجم النموذج لم يغيّر هذه النسبة. وفي تدقيق مستقل لتطبيقات بُنيت بأسلوب vibe coding، كان 10.5 بالمئة فقط منها آمنا. والمشكلة لا تقتصر على الأمان: تكاملات مثل المدفوعات أو التوثيق تبقى ناقصة، والتطبيق لم يُختبر قط تحت حمل مستخدمين حقيقي، واستدعاءات الذكاء الاصطناعي تخرج من دون سقف إنفاق أو حد لمعدل الطلبات. وهذه الخدمة قائمة على هذه النقطة بالذات: فرق أوصلت منتجها إلى مكان معين بهذه الأدوات، ولا تعرف الآن ما الناقص قبل الإطلاق.

ثلاثة سيناريوهات، ثلاث نقاط دخول مختلفة

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

ثلاث مراحل: اكتشف، أصلح، ركّب البوابة

يسلّم أغلب تدقيق vibe code شيئا واحدا: تقريرا يرتب النتائج. وقائمة النتائج لا تغيّر قاعدة الكود لديكم، بل تخبركم فقط أين موقعكم. وعملنا يسير في ثلاث مراحل: الأولى التدقيق، ولا يشمل ثغرات الأمان فقط بل أيضا التكاملات الناقصة، والنقاط التي لم تُختبر قط تحت حمل، ومخاطر التكلفة الناتجة عن استدعاءات ذكاء اصطناعي بلا حدود؛ والثانية الإصلاح؛ والثالثة بوابة أمان دائمة مثبتة في خط CI/CD الخاص بكم، أي النظام الذي يبني الكود ويجهزه للإصدار تلقائيا مع كل تحديث. وبلا المرحلة الثالثة تصير الأولى والثانية مؤقتتين، لأن أي تعديل قادم بمساعدة الذكاء الاصطناعي يعيد إنتاج فئة الخطأ نفسها. وبعد تركيب البوابة يُفحص كل تعديل جديد ترسلونه أنتم أو أداتكم الذكية تلقائيا ويُوقف قبل الدمج.

أين ننظر أثناء التدقيق

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

التحكم بالوصول وصلاحيات الظهور

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

تسرب الأسرار وبيانات الاعتماد

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

التبعيات والحزم المتوهَّمة

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

التحقق من المدخلات وأخطاء فئة الحقن

وفي التقرير نفسه لـVeracode كان 86 بالمئة من الكود المختبَر عرضة لهجمات XSS، أي أن يُكتب مدخل من المستخدم مباشرة في الصفحة ويُنفَّذ في المتصفح، وكان 88 بالمئة عرضة لحقن السجلات الناتج عن كتابة بيانات غير مفحوصة في سجلات الخادم. وكلاهما من الجذر نفسه: البيانات القادمة من المستخدم لا تُنظَّف قبل كتابتها على الشاشة أو إدراجها في استعلام. والكود المولَّد بالنموذج يعمل غالبا بشكل صحيح للاستخدام المتوقع، لا للمدخل الخبيث. وأثناء التدقيق نتتبع كل مدخل مستخدم لمعرفة أين ينتهي: على الشاشة، أم في استعلام، أم في مسار ملف، وهل هناك تحقق عند تلك النقطة. وحقل واحد غير مُتحقَّق منه يكفي ليحمل خطرا مستقلا في كل شاشة وكل نقطة نهاية تغذيه.

الإصلاح والحماية الدائمة

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

الإصلاح: كود قابل للدمج، لا تقرير

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

بوابة أمان مثبتة في CI/CD

الإصلاح ليس دائما، لأن أداتكم الذكية قد تعيد إنتاج الخطأ نفسه غدا. ولهذا فالخطوة الأخيرة هي تثبيت التحليل الساكن وفحص التبعيات وفحص الأسرار في خط الإصدار لديكم: يُفحص كل طلب دمج تلقائيا، وتوقف نتيجة حرجة عملية الدمج. وتعمل البوابة بالطريقة نفسها بصرف النظر عمن أرسل التعديل: سواء كتبتموه بأيديكم أو التزم به وكيل ذكاء اصطناعي، لا فرق. وتُضاف هذه البوابة إلى خط CI/CD قائم لديكم، أو تُبنى مع خدمة DevOps والتكامل والنشر المستمر إن لم يكن لديكم خط بعد. وبعد تركيب البوابة تتوقف الفئة نفسها من الأخطاء عن الوصول إلى الإنتاج نهائيا، ويستطيع فريقكم صيانتها بأنفسكم من دون الحاجة إلينا مجددا.

كيف يُحدَّد النطاق

يتحدد النطاق كتابة أثناء مكالمة تحديد النطاق: أي مستودع، وأي بيئة، وأي تكاملات مشمولة. والأداة التي أنتجت الكود لا تغيّر نطاق التدقيق؛ فالجميع يمر بالعملية نفسها. يفحص التدقيق فئات الخطأ المعروفة القابلة للاكتشاف بالمعرفة الحالية، وتُختتم كل فئة نفحصها إما بإصلاح أو بملاحظة مكتوبة بمخاطرة مقبولة عن وعي. أما القرار المعماري، مثل إعادة تصميم نموذج البيانات كاملا، فيخرج بطبيعته عن حدود هذا التدقيق؛ وإن ظهرت حاجة كهذه ينتقل العمل إلى توسيع نطاق الخلفية أو CTO as a Service. وبما أن هذا الوضوح مبني منذ البداية، يصير ما يحصل عليه كل طرف واضحا منذ اليوم الأول للمحادثة.

نتائج الفحص الأول

في أول فحص لتطبيق بُني بأسلوب vibe coding، وبصرف النظر عن الأداة التي أنتجت الكود، تظهر تقريبا الأشياء الثلاثة نفسها دائما: شاشة إدارة يمكن الوصول إليها من دون توثيق، ومفتاح API واحد على الأقل مكتوب مباشرة في الكود، ومدخل مستخدم واحد على الأقل من دون تحقق حقيقي. وفي فحص مستقل لأكثر من خمسة آلاف تطبيق منشور علنا بأسلوب vibe coding في مايو 2026، كشف نحو 40 بالمئة منها بيانات حساسة كالسجلات الطبية أو المالية، ولم يكن لدى أكثر من ألفي تطبيق مؤسسي أي تحكم بالوصول أصلا. وحين تظهر هذه النتائج الثلاث معا يكون الرابط بينها واحدا غالبا: خطوة أُسقطت من أجل السرعة ولم يُعَد النظر فيها قط. ونطبق على أنفسنا الانضباط نفسه: كل كود ننتجه، بما فيه هذا الموقع، يمر عبر طبقة تنقية لا تمرر أي وسم يتجاوز القائمة المسموحة، وعبر مراجعة آلية قبل كل التزام. ولا نوصي بطريقة لا نطبقها نحن أنفسنا على عملنا.

سير العمل: من أول اتصال إلى الكود المسلَّم

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