أتلقى نسخة من هذا السؤال في كل مكالمة تأهيل تقريبًا، عادةً بصياغة حذرة، وكأن السائل يتوقع نصف توقع أن يُقنع بعدم القلق. لا ينبغي إقناعه بذلك. الأمان أحد المجالات القليلة التي يكون فيها قدر صحي من الحذر معايرًا بشكل صحيح، سواء كتب الكود إنسان أو نموذج. فيما يلي الأسئلة التي أتلقاها فعلًا، مُجابة بأكبر قدر ممكن من المباشرة.
هل الكود المكتوب بالذكاء الاصطناعي أقل أمانًا من الكود الذي يكتبه إنسان؟
في المتوسط، وبدون رقابة، نعم — بشكل طفيف. دراسة من ستانفورد قبل بضع سنوات (Perry وآخرون، غالبًا ما تُذكر كأول نظرة حقيقية في هذا الموضوع) وجدت أن المطورين الذين استخدموا مساعد برمجة بالذكاء الاصطناعي أنتجوا كودًا أقل أمانًا من مجموعة ضابطة، والأهم — وهذا ما يجب أن يقلقك أكثر — قيّموا كودهم الخاص على أنه أكثر أمانًا مما كان عليه فعلًا. ارتفعت الثقة بينما انخفضت الجودة. عمليات فحص أمان الكود من Veracode لأدوات GenAI الأحدث تضع رقمًا تقريبيًا لذلك أيضًا: نحو 4 من كل 10 عيّنات كود مولّدة بالذكاء الاصطناعي اختبروها احتوت على ثغرة واحدة قابلة للاستغلال على الأقل، عادةً شيء بسيط مثل فحص إدخال مفقود أو إعداد افتراضي ضعيف. لا يعني شيء من هذا أن الكود المكتوب بالذكاء الاصطناعي محكوم عليه بالفشل حتمًا. بل يعني أن الكود غير المُراجَع المكتوب بالذكاء الاصطناعي يحمل نفس مخاطر الكود البشري غير المُراجَع، وجزء "غير المُراجَع" هو حيث يكمن الخطر فعليًا. النموذج الذي يكتب بسرعة ولا يُفحص أبدًا سيسلّم نفس الأخطاء التي يرتكبها مطور مبتدئ في عصر يوم جمعة — لكن أسرع، وبكمية أكبر.
ماذا يحدث لمفاتيح API والأسرار الخاصة بي؟
هذا هو الأمر الذي يفقدني النوم فعلًا، لأنه الخطأ الذي يبقى غير مرئي إلى أن يصبح كذلك. طريقة الفشل ليست درامية — لا يُخترق خادوم أحد بأسلوب هوليوودي. إنه مفتاح يُلصق في محادثة، ثم يُعاد إظهاره في ملف مُولَّد، يُودَع في نظام التحكم بالإصدارات، ويبقى بهدوء بنص واضح في مستودع بعد ستة أشهر عندما يشغّل أحدهم أداة فحص أسرار عليه بدافع الفضول. على هذه المنصة، لا تعيش الأسرار مطلقًا في الكود المصدري المُولَّد — بل تُحقَن وقت التشغيل من مخزن مشفّر، مخصص لمستأجرك، ووكلاء البناء موجَّهون للإشارة إليها بالاسم فقط، لا بالقيمة أبدًا. لكن إذا كنت تبني في مكان آخر، أو تلصق بيانات اعتماد مباشرة في نافذة محادثة أي أداة كانت، افترض أن ذلك النص أصبح الآن جزءًا من سجل ذي صلة بالتدريب في مكان ما ما لم يذكر المزوّد صراحةً غير ذلك. أدر أي شيء كتبته يومًا في مربع محادثة، من باب المبدأ، في نفس اليوم الذي تنتهي فيه من اختباره.
هل يمكن لأحد اختراق موقعي عبر طلب توجيهي (prompt)، مثل هجوم حقن الأوامر (prompt injection)؟
يُخلط هنا بين أمرين مختلفين، والفرق مهم. حقن الأوامر ضد أداة البناء — أي أن يخدع شخص ما الذكاء الاصطناعي الذي يبني تطبيقك ليفعل شيئًا لم تطلبه — خطر حقيقي ومدروس، وهو السبب في أن وكلاء البناء يعملون بصلاحيات أدوات محددة النطاق بدلًا من صلاحية shell شاملة، وسبب أن أي شيء يمس نظام الملفات لديك أو خط أنابيب النشر يمر عبر سجل إجراءات صريح يمكنك مراجعته لاحقًا. أما حقن الأوامر ضد تطبيقك المُطلَق فهو أمر منفصل ينطبق فقط إذا كان تطبيقك نفسه يضمّن نموذجًا لغويًا وقت التشغيل — روبوت دردشة للدعم، ميزة بحث بالذكاء الاصطناعي، ذلك النوع من الأشياء. إذا كان الأمر كذلك، تعامل مع أي نص يمكن للمستخدم كتابته كمدخل غير موثوق لذلك النموذج، تمامًا كما تتعامل معه كمدخل غير موثوق لاستعلام SQL. القاعدة قديمة، الجديد فقط هو أي نظام يحلّل السلسلة النصية.
هل تفحص أداة البناء الكود الخاص بها بحثًا عن ثغرات قبل إطلاقه؟
تلتقط الفحوصات الآلية بشكل موثوق الأمور المملة عالية التكرار: الأسرار المُدرَجة مباشرة في الكود، غياب المصادقة على نقطة نهاية تحتاجها بوضوح، استعلامات SQL مبنية بدمج النصوص بدلًا من المعاملات، تبعيات تحمل ثغرة CVE معروفة. ما لا تلتقطه بشكل جيد هو عيوب منطق الأعمال — النوع الذي يكون فيه كل سطر كود على حدة سليمًا والثغرة كامنة في الفجوة بين ميزتين لم يفكر أحد في فحصهما معًا. كود خصم يتراكم إلى ما لا نهاية مع مكافأة إحالة. تدفق إعادة تعيين كلمة مرور يكشف عن وجود بريد إلكتروني في النظام. تلك تتطلب شخصًا يفهم الغرض من التطبيق، لا فقط ما يفعله الكود، ولا توجد أداة فحص — بالذكاء الاصطناعي أو غيره — تجدها بشكل موثوق بعد. المراجعة الآلية أرضية، لا سقف.
وماذا عن الحزم الخارجية التي تُثبَّت — هل هذا خطر في سلسلة التوريد؟
نعم، وهو في الواقع خطر أكبر على أرض الواقع من الكود الذي يكتبه الذكاء الاصطناعي نفسه. معظم التطبيقات تتكون من 80-95% من الاعتماديات من حيث عدد الأسطر؛ والكود الذي يكتبه الباني هو طبقة رقيقة فوق npm أو PyPI أو أي نظام بيئي تعتمده حزمة التقنيات. يمكن لحزمة ضارة أو تم اختراقها أن تعرّضك للخطر بغض النظر عن هوية من كتب الكود الرابط حولها — راجع حادثتي event-stream و colors.js لترى كيف يحدث ذلك على أرض الواقع. الإجراءات الوقائية بسيطة وفعّالة: ثبّت إصدارات محددة بدلاً من تتبع الأحدث، وفضّل الحزم ذات تاريخ صيانة حقيقي على تلك التي نُشرت الأسبوع الماضي، واجعل تدقيق الاعتماديات (`npm audit`، أو `pip-audit`، أو ما يناسب حزمة تقنياتك) عادة مستمرة، لا خطوة تُنفَّذ مرة واحدة قبل الإطلاق.
| الخطر | من يتسبب فيه | كيف يُكتشف عادةً | من مسؤول عن إصلاحه |
|---|---|---|---|
| سر مُضمَّن مباشرة في الكود المُولَّد | عملية البناء، إذا لم تُحقَن الأسرار بشكل صحيح | فحص ثابت (static scan)، أو تحقق ما قبل النشر | المنصة |
| غياب التحقق من صحة المدخلات | النموذج أو الإنسان، كلاهما وارد | مراجعة كود آلية ويدوية | كلاهما |
| اعتمادية ضعيفة (ثغرة CVE) | القائم على صيانة الحزمة الأصلية | تدقيق الاعتماديات | أنت، بشكل مستمر |
| خلل في منطق العمل (ثغرات تراكمية، IDOR) | من حدد الميزة بشكل ناقص | الاختبار اليدوي، وعادةً فقط إذا انتبه أحدهم لذلك | أنت |
| حقن أوامر (prompt injection) في ميزة نموذج لغوي مُضمَّن | مستخدمو تطبيقك النهائيون | تعقيم المدخلات + صلاحيات محدودة للنموذج | أنت |
من المسؤول قانونيًا في حال حدوث اختراق؟
أنت — قانونيًا، وفي الغالب دائمًا، إذا كان التطبيق تطبيقك وبيانات المستخدمين هي بياناتك. هذا يفاجئ من يفترض أن "الذكاء الاصطناعي كتب الكود" ينقل المسؤولية إلى مكان آخر. لا ينقلها، تمامًا كما أن توظيف مقاول لا ينقل المسؤولية عن مخالفة كود البناء بعيدًا عن مالك العقار. المنصات تتحمل مسؤولية البنية التحتية التي تتحكم بها: كيفية تخزين الأسرار، وكيفية عزل بيانات المستأجرين، وما إذا كانت طبقة الاستضافة نفسها محدَّثة. أما منطق التطبيق الذي حددته أنت، والبيانات التي اخترت جمعها، والشروط التي قدمتها لمستخدميك، فهي مسؤوليتك أنت. إذا كنت تتعامل مع أي بيانات حساسة — تفاصيل دفع، معلومات صحية، أي شيء يخضع لـ GDPR أو CCPA — اقرأ اتفاقية معالجة البيانات الفعلية للمنصة التي تستخدمها بدلاً من افتراض أن "مبني بالذكاء الاصطناعي" يعني وجود طبقة حماية قانونية إضافية. فهو لا يعني ذلك.
أخبرتني مؤسِّسة مرة، بشكل شبه هزلي، أنها تثق بكود الذكاء الاصطناعي أكثر من كودها الخاص لأنه "على الأقل لا يتعب في الثانية صباحًا." ربما. لكن البشر المتعبين عادةً يعرفون أنهم متعبون. أما الذكاء الاصطناعي فلا يدرك أنه ارتكب للتو خطأً، وسيخبرك أن الكود جاهز بنفس النبرة الواثقة سواء كان خاليًا من العيوب أو مليئًا بالثغرات. الثقة ليست مؤشر أمان، سواء جاءت من هذا المصدر أو ذاك.
هل يجب أن أدفع مقابل تدقيق أمني حقيقي قبل الإطلاق؟
إذا كنت تستقبل مدفوعات، أو تخزّن أي شيء قد يعتبره المنظِّم بيانات شخصية (PII)، أو تبني لعميل شركات سيطلب تقرير SOC 2 على أي حال — فنعم، ولا تدع التكلفة تثنيك عن ذلك. التدقيق المركّز على تطبيق صغير يتراوح بين بضع مئات وآلاف قليلة من الدولارات حسب النطاق، وهو مبلغ زهيد مقارنةً برسالة الإفصاح عن اختراق. أما إذا كنت تبني مشروعًا هوائيًا أو أداة داخلية أو شيئًا لا توجد فيه بيانات مستخدمين حقيقية على المحك، فالتدقيق المدفوع مبالغة؛ اكتفِ بالطبقة المجانية والرخيصة بدلًا من ذلك — فحص الاعتماديات، ومراجعة يدوية لكل حدود المصادقة (هل يمكن للمستخدم أ رؤية بيانات المستخدم ب بمجرد تغيير رابط؟)، وعين بشرية إضافية على أي شيء يتعامل مع المال أو كلمات المرور.
ما هو الخطأ الأمني الأكثر شيوعًا الذي يرتكبه الناس، ومتى يحدث؟
ليس عند الإطلاق — بل بعد ثلاثة أشهر، حين يكون التطبيق يعمل ولم يعد أحد ينتبه إليه. إنه مسار إداري تُرك بلا حماية لأنه لم يُختبر إلا من قِبل من بناه، وهو مسجَّل الدخول بحسابه الخاص. إنه نقطة تصحيح أخطاء (debug endpoint) تُرجع تتبعات كاملة للأعطال في بيئة الإنتاج. إنه كلمة مرور افتراضية على قاعدة بيانات كان من المفترض أن تكون "للاختبار فقط" ولم تُغيَّر أبدًا. لا شيء من هذا غريب أو نادر. إنها النسخة الأمنية من ترك مفتاح احتياطي تحت الباب لأنك كنت مستعجلًا في تلك المرة ثم نسيت وجوده. الحل ليس أداة أفضل، بل عادة تستغرق خمس دقائق: مرة كل شهر، انظر إلى تطبيقك كما لو كنت مهاجمًا لمدة خمس دقائق قبل أن تنظر إليه بعين الباني الفخور.
