قائمة التحقق الأمنية قبل إطلاق تطبيق مبني بـ vibe coding

قبل إطلاق تطبيق مبني بـ vibe coding، حدّد الـ commit الدقيق للإصدار، وافحصه، واختبر حدود الوصول فيه والتعامل مع الأسرار ومسارات الفشل في بيئة مضبوطة. واستخدم نتائج vetkit كأدلة تراجعها إلى جانب اختباراتك وإعدادات النشر. فالفحص الناجح ليس برهانًا على أن التطبيق قيد التشغيل آمن أو جاهز للإطلاق.

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

1. اربط الأدلة بالإصدار

• سجّل الـ commit SHA ومخرَج البناء الذي تخطط لنشره.
• تحقّق من أن تقرير التدقيق يذكر الـ commit نفسه. فتقرير يخص رأس فرع أقدم لا يغطي الإصلاحات اللاحقة أو الملفات المولّدة.
• ابنِ المشروع وشغّل اختباراته من ذلك الإصدار باستخدام إعدادات مضبوطة وبيانات اصطناعية. واحتفظ بنتائج الأوامر الفعلية، بما فيها حالات الفشل والاختبارات المتخطّاة.

2. تحقّق مما جرى تشغيله فعلًا

يتضمن Security Quick Scan فحص الوضع الأمني، واكتشاف الأسرار باستخدام gitleaks، وفحص الاعتماديات باستخدام OSV. ويمكن أن تتضمن التدقيقات الأشمل فحوصًا إضافية حيث يسمح بذلك حسابك والنطاق المختار. يختار قالب الإصدار في vetkit فحوصًا لمجالات مثل التحليل الأمني الساكن والبنية التحتية ومسارات العمل وقابلية التشغيل، لكنه لا يشمل كل المحلّلات المتاحة. فعلى سبيل المثال، secrets-history وllm-app منفصلان عن اختيار ذلك القالب.

التقرير الجزئي يعني أن محلّلًا واحدًا أو أكثر لم يكتمل، وأن الفئات المتأثرة قد تكون ممثَّلة بأقل من حقيقتها. عالج فجوات التغطية ذات الصلة أو وثّق التحقق البديل قبل الاعتماد على النتيجة.

3. اختبر حدود الوصول

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

في التطبيقات المبنية على Supabase، راجع سياسات الأمان على مستوى الصفوف وسياسات التخزين المنشورة باستخدام سجلات اصطناعية. يمكن لقواعد vibe-stack في vetkit أن تنبّه إلى أنماط مدعومة في الشيفرة المصدرية مثل غياب سياسات الأمان على مستوى الصفوف أو تساهلها، وحاويات التخزين العامة. لكن فحص الشيفرة المصدرية لا يحدّد الإعدادات الحالية لقاعدة بياناتك المستضافة ولا يثبت العزل بين المستأجرين.

4. افحص الأسرار وأصول المتصفح

راجع نتائج الأسرار وبادئات متغيرات البيئة العامة وأصول المتصفح المولّدة. وأبقِ بيانات اعتماد المزوّدين ومفاتيح service role على جانب الخادم. لا يستطيع تدقيق المستودع رؤية سرّ نشر غائب عن الملفات المفحوصة، ولا يفحص حزمة المتصفح المنشورة تلقائيًا. وإذا انكشفت بيانات اعتماد، فألغِها أو بدّلها؛ فإزالة السطر من الشيفرة المصدرية لا تكفي. ويشرح دليل الأسرار المسرَّبة الفحوص المنفصلة للمستودع والتاريخ والمتصفح.

5. راجع الاعتماديات وميزات الذكاء الاصطناعي

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

إذا كان تطبيقك يستدعي LLM، فاختبر ما يحدث مع المدخلات المفرطة الحجم وأخطاء المزوّد والمخرجات التي تطلب عملية ذات صلاحيات. اضبط حدود استخدام على جانب الخادم، واشترط التفويض حول الأدوات التي تغيّر البيانات. تحدّد قواعد llm-app في vetkit أنماطًا مدعومة مثل مخرجات النموذج التي تُنفَّذ كأوامر أو SQL، والاستدعاءات التي يقودها المستخدم دون حدّ لرموز المخرجات. لكنها لا تثبت أن كل محاولة لحقن الأوامر (prompt injection) ستفشل، ولا تقيس ضوابط الإنفاق لديك في الإنتاج.

6. اختبر مسارات الفشل والتعافي

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

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

7. وثّق قرار الإطلاق

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

المصادر والحدود

جرى التحقق في 1 نوفمبر 2026 مقابل إعداد Quick Scan في vetkit، وقوالب التدقيق، ومنسّق التقارير، وقواعد vibe-stack وllm-app وresilience وdata-access وoperability. يصف كتالوج الفحوص العام القواعد المطوّرة داخليًا واللغات التي تدعمها؛ وتصف الوثائق إعداد التدقيق. وتتأثر التغطية بتوفّر المحلّلات والأنماط المدعومة وحدود الفحص والنطاق المختار.

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