الكود اشتغل.. لكن من قال إنه آمن؟ الأمن السيبراني في عصر الـ Vibe Coding
جميل، صح؟
خليني أسألك سؤال واحد: هل تعرف ماذا يوجد داخل هذا الكود؟
إذا كانت إجابتك "لا، بس المهم أنه يشتغل"، فهذا المقال مكتوب لك تحديدًا. لأن الفرق بين "كود يعمل" و"كود آمن" هو بالضبط الفرق بين باب مغلق وباب مغلق ومقفول. الاثنان يبدوان متطابقين من بعيد.. حتى يأتي شخص ويدفع الباب.
الوهم الجميل
الـ Vibe Coding غيّر قواعد اللعبة فعلًا. اليوم أي شخص يقدر يبني تطبيق، موقع، أو حتى SaaS كامل خلال أيام بدل شهور. وأنا شخصيًا من أكبر المستفيدين من هذه الثورة ومن المدافعين عنها.
لكن هناك حقيقة لا أحد يخبرك بها:
الـ AI مدرَّب على أن يجعل الكود "يعمل".. وليس على أن يجعله "آمنًا".
النموذج تعلّم من ملايين المشاريع على GitHub، وجزء كبير منها مكتوب بطريقة غير آمنة أصلًا. فعندما تطلب منه "اعمل لي صفحة تسجيل دخول"، هو يعطيك النمط الأكثر شيوعًا في بيانات تدريبه.. وليس النمط الأكثر أمانًا.
والنتيجة؟ ثغرات لا تراها، لأنك أصلًا لا تعرف كيف تبحث عنها.
خمس كوارث أمنية يصنعها الـ AI وأنت لا تشعر
1. الأسرار المكشوفة (Hardcoded Secrets)
أكثر خطأ أشوفه في مشاريع الـ Vibe Coding: مفتاح الـ API مكتوب مباشرة داخل الكود.
const apiKey = "sk-proj-abc123..."; // كارثة تنتظر الحدوث
ترفع المشروع على GitHub؟ خلاص، مفتاحك صار ملك العالم. هناك bots تمسح GitHub على مدار الساعة تبحث عن مفاتيح مسرّبة، وخلال دقائق من رفع المشروع ستجد فاتورة بآلاف الدولارات على حسابك، أو أسوأ: بياناتك وبيانات مستخدميك بيد شخص آخر.
وهذه ليست مبالغة نظرية. تقارير أمن سلسلة التوريد (مثل تقارير GitGuardian السنوية) توثّق ملايين الأسرار المسرّبة على GitHub كل عام، والأرقام في تصاعد مستمر مع انتشار الكود المولّد بالـ AI — لأن النموذج، ببساطة، يكتب المفتاح حيث "يعمل الكود" ولا يفكر في اليوم الذي سترفع فيه المشروع للعلن.
2. الثقة العمياء بالمدخلات (Missing Input Validation)
الـ AI يفترض دائمًا أن المستخدم "شخص لطيف" سيدخل بياناته بشكل صحيح.
الواقع؟ المستخدم قد يكون مهاجمًا يُدخل في خانة الاسم شيئًا مثل:
'; DROP TABLE users; --
هذه هي الـ SQL Injection، واحدة من أقدم الثغرات في التاريخ، وما زالت تظهر في أكواد الـ AI حتى اليوم. والأخطر منها في تطبيقات الويب: الـ XSS، حيث يُحقن كود خبيث يُنفَّذ في متصفحات مستخدميك أنت.
3. التحقق في الواجهة فقط (Client-Side Only Validation)
هذه لطيفة جدًا. تطلب من الـ AI: "تأكد أن المستخدم لا يقدر يشتري بسعر سالب"، فيضيف التحقق في الـ Frontend فقط.
يبدو أنه اشتغل. تجرب من المتصفح، فعلًا لا يقبل السعر السالب. ممتاز!
لكن أي شخص يفتح Developer Tools أو يرسل request مباشرة للـ API يتجاوز كل هذا "الأمان" في ثوانٍ. القاعدة الذهبية: أي تحقق في الواجهة هو تجميل، والتحقق الحقيقي مكانه الـ Backend. والـ AI بدون توجيه صريح، غالبًا ينفذ الأول وينسى الثاني.
4. الثغرة المكررة (Duplicated Vulnerabilities)
هنا نصل للجزء المعماري الذي تكلمت عنه سابقًا، لكن من زاوية أخطر.
الـ AI يميل لتكرار نفس المنطق في كل ملف بدل بناء دالة مركزية واحدة. المشكلة الأمنية؟ إذا اكتشفت ثغرة في هذا المنطق وأصلحتها في مكان واحد.. النسخ العشرون الأخرى ما زالت مثقوبة.
في المعمارية السليمة، تصلح الثغرة مرة واحدة فتُصلَح في كل النظام. في فوضى الـ Vibe Coding، أنت تلعب لعبة "اضرب الخُلد" مع ثغراتك الخاصة، وأنت لا تعرف حتى كم خُلدًا تبقّى.
5. مكتبات لا تعرف عنها شيئًا (Dependency Blindness)
الـ AI أضاف لمشروعك 40 مكتبة خارجية. هل تعرف واحدة منها؟
كل مكتبة هي باب إضافي في بيتك. بعضها قديم ومليء بثغرات معروفة وموثقة، وبعضها قد يكون خبيثًا أصلًا (وظهرت حالات حقيقية لنماذج AI "تهلوس" أسماء مكتبات غير موجودة، فيسارع المهاجمون لنشر مكتبات خبيثة بنفس الأسماء — هجوم يُعرف بالـ Slopsquatting).
الحل البسيط هنا؟ فعّل Dependabot في مستودعك على GitHub — أداة مجانية تراقب مكتباتك وتنبهك (بل وتفتح لك Pull Request جاهز) عند اكتشاف ثغرة في أي منها. خمس دقائق إعداد، وحارس أمني يشتغل عنك للأبد.
طيب.. ما الحل؟ (ولا يحتاج أن تكون خبير أمن)
الخبر الجيد: نفس الـ AI الذي صنع المشكلة يقدر يساعدك في حلها.. إذا عرفت كيف تسأله. إليك خمس عادات عملية:
أولًا: اجعل الأمن جزءًا من الـ prompt من البداية. لا تقل "اعمل لي صفحة تسجيل دخول" وخلاص. قل: "اعمل صفحة تسجيل دخول مع تشفير كلمات المرور بـ bcrypt، وتحقق من المدخلات في الـ Backend، وحماية من الـ SQL Injection باستخدام parameterized queries".
لا تحفظ هذه المصطلحات؟ لا مشكلة. احفظ هذا السطر السحري وأضفه لأي prompt:
"Apply security best practices: validate all inputs server-side, never hardcode secrets, use environment variables, and protect against OWASP Top 10 vulnerabilities."
وحتى ترى الفرق بعينك، هذا مثال حقيقي — نفس الطلب، قبل وبعد التوجيه:
قبل — الـ prompt: "اعمل endpoint لجلب بيانات مستخدم":
// ما يكتبه الـ AI غالبًا بدون توجيه
app.get('/user', (req, res) => {const id = req.query.id;db.query(`SELECT * FROM users WHERE id = ${id}`, (err, result) => {res.json(result);});});
يعمل؟ نعم. آمن؟ أبدًا. المدخل يدخل الاستعلام مباشرة (SQL Injection جاهزة)، لا تحقق من الهوية، ولا معالجة للأخطاء.
بعد — نفس الطلب + السطر السحري:
// نفس الوظيفة بعد التوجيه الأمني
app.get('/user', authenticate, (req, res) => {const id = parseInt(req.query.id, 10);if (isNaN(id)) return res.status(400).json({ error: 'Invalid ID' });db.query('SELECT id, name, email FROM users WHERE id = ?', [id], (err, result) => {if (err) return res.status(500).json({ error: 'Server error' });res.json(result);});});
parameterized query، تحقق من المدخل، مصادقة، معالجة أخطاء، وحتى الأعمدة الحساسة (مثل كلمة المرور) لم تعد تُرجع. سطر واحد في الـ prompt غيّر كل هذا.
ثانيًا: اطلب مراجعة أمنية من الـ AI نفسه. بعد كل ميزة جديدة، افتح محادثة جديدة والصق الكود مع هذا الطلب:
"راجع هذا الكود كخبير أمن سيبراني. ابحث عن ثغرات، أسرار مكشوفة، ومدخلات غير محمية. اشرح لي كل مشكلة بلغة بسيطة مع طريقة الإصلاح."
لماذا محادثة جديدة؟ لأن الـ AI في نفس المحادثة يميل للدفاع عن كوده. في محادثة جديدة، يتحول لمراجع محايد.
ثالثًا: الأسرار في ملف .env دائمًا. اطلب من الـ AI: "انقل كل المفاتيح والأسرار إلى environment variables وأضف ملف .env إلى .gitignore". جملة واحدة تنقذك من أكبر كارثة شائعة.
رابعًا: اسأل قبل أن ترفع. قبل نشر أي مشروع، اسأل الـ AI: "لو كنت مهاجمًا، كيف ستخترق هذا التطبيق؟" ستتفاجأ بجودة الإجابات. أنت عمليًا تحصل على penetration test مجاني بمستوى مبدئي.
خامسًا: افحص مكتباتك. أمر واحد في الطرفية: npm audit (أو ما يعادله في لغتك) يخبرك بالمكتبات المصابة بثغرات معروفة. اجعله عادة قبل كل نشر، وفعّل Dependabot كما ذكرنا ليقوم بالمهمة عنك تلقائيًا.
تنبيه مهم: هذه العادات لا تُغني عن خبير الأمن السيبراني
خليني أكون واضحًا معك حتى لا تفهم الرسالة بشكل خاطئ.
كل ما سبق يرفعك من مستوى "هدف سهل" إلى مستوى "محمي بشكل معقول". لكن هناك فرق جوهري بين الاثنين: الـ AI الذي يراجع كوده يشبه الكاتب الذي يدقق مقالته بنفسه — سيلتقط الأخطاء الواضحة، لكنه أعمى عن نفس النقاط العمياء التي أوقعته في الخطأ أصلًا.
الـ AI ممتاز في اكتشاف الأنماط المعروفة: SQL Injection، أسرار مكشوفة، مدخلات غير محمية. لكنه ضعيف جدًا في:
ثغرات منطق العمل (Business Logic Flaws): هل يستطيع المستخدم تطبيق كوبون الخصم مرتين؟ هل يقدر يشوف طلبات مستخدم آخر بتغيير رقم في الرابط؟ هذه الثغرات لا يكتشفها إلا من يفهم كيف يُفترض أن يعمل نظامك تحديدًا — والـ AI لا يعرف نموذج عملك.
الاختراق الفعلي (Penetration Testing): المهاجم الحقيقي يسلسل عدة ثغرات صغيرة "غير خطيرة" منفردة ليصنع منها اختراقًا كاملًا. هذا فن لا تؤديه مراجعة كود آلية.
نمذجة التهديدات (Threat Modeling): من قد يهاجمك؟ لماذا؟ ما أثمن ما تملك؟ إجابات هذه الأسئلة تحدد أولويات حمايتك، وهي قرارات استراتيجية بشرية.
الامتثال والمسؤولية القانونية: إذا كنت تتعامل مع بيانات مالية أو صحية أو تخضع لأنظمة مثل PDPL، فالتوقيع على سلامة نظامك مسؤولية لا يحملها لك نموذج لغوي.
النصيحة العملية — متى تستعين بخبير؟ استخدم هذه القاعدة البسيطة: اسأل نفسك "ماذا أخسر لو اختُرق تطبيقي غدًا؟"
مشروع تجريبي أو أداة شخصية بدون بيانات مستخدمين؟ العادات الخمس أعلاه تكفيك.
تطبيق فيه حسابات مستخدمين وبياناتهم؟ العادات الخمس إلزامية + فحص دوري بأدوات آلية.
تطبيق يتعامل مع مدفوعات، بيانات حساسة، أو عملاء شركات؟ هنا خبير الأمن ليس رفاهية بل تكلفة تشغيل أساسية — penetration test واحد قبل الإطلاق أرخص بكثير من حادثة اختراق واحدة بعده، بسمعتك قبل أموالك.
الـ AI رفع الحد الأدنى للجميع، لكنه لم يُلغِ القمة. بالعكس — كلما زاد الكود المولّد آليًا في العالم، زادت قيمة العين البشرية الخبيرة التي تعرف أين تنظر.
الخلاصة: الأمن ليس ميزة تضيفها لاحقًا
الـ Vibe Coding ليس المشكلة. الـ Vibe Coding بدون وعي أمني هو المشكلة.
الكود الذي يعمل يجعلك سعيدًا اليوم. الكود الآمن يجعلك نائمًا بهدوء بعد سنة، عندما يصبح لتطبيقك مستخدمون حقيقيون ببيانات حقيقية.. ومهاجمون حقيقيون.
والفرق بينهما يبدأ بعادات بسيطة وأسئلة صحيحة توجهها للـ AI.. وينتهي بمعرفة اللحظة التي تحتاج فيها عينًا بشرية خبيرة تنظر حيث لا ينظر النموذج.
الذكاء الاصطناعي موظف تنفيذي خارق.. لكنه ينفذ ما تطلبه أنت. اطلب الأمان، تحصل على أساسه. اسكت عنه، تدفع ثمنه. وعندما ترتفع قيمة ما تحميه، ارفع معها مستوى من يحميه.
المقال منقول من صفحة Fadi AlAswadi
التعليقات