المخاطر الخفية للبرمجة باستخدام الذكاء الاصطناعي

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

التعليمات البرمجية التي يتم توليدها بواسطة الذكاء الاصطناعي

عندما تتولى النماذج اللغوية الكبيرة توليد التعليمات البرمجية، فإنها قد تشتمل على أخطاء أو عيوب أمنية. ويُعزى ذلك إلى أن هذه النماذج يتم تدريبها استنادًا إلى بيانات متاحة للجمهور على شبكة الإنترنت، والتي تتضمن آلاف الأمثلة من التعليمات البرمجية متدنية الجودة. وكشفت دراسة حديثة أجرتها شركة Veracode أن نماذج الذكاء الاصطناعي الرائدة تنتج الآن تعليمات برمجية يمكن تحويلها بنجاح في 90% من الحالات. وقبل أقل من عامين، كان هذا الرقم أقل من 20%. ومع ذلك، لم يتحسن أمان هذه التعليمات البرمجية – لا تزال نسبة 45% منها تحتوي على ثغرات أمنية كلاسيكية من قائمة OWASP للعشرة الأوائل، مع حدوث تغير طفيف في العامين الماضيين. وشملت الدراسة أكثر من مائة نموذج لغوي كبير (LLM) شائعة، بالإضافة إلى أجزاء من التعليمات البرمجية بلغات Java وPython وC# وJavaScript. لذلك، وبغض النظر عما إذا كان النموذج اللغوي الكبير يُستخدم “لإكمال التعليمات البرمجية” في Windsurf أو “البرمجة بالإحساس» في Loveable، فيجب أن يخضع التطبيق النهائي لاختبارات شاملة للثغرات الأمنية. لكن من الناحية العملية، نادرًا ما يحدث هذا: وفقًا لدراسة أجرتها Wiz، تحتوي 20% من التطبيقات المنتجة باستخدام البرمجة بالإحساس على ثغرات أمنية خطيرة أو أخطاء في التكوين.

كمثال على هذه العيوب، غالبًا ما تُستخدم قضية تطبيق المواعدة الخاص بالنساء، Tea، الذي أصبح سيئ السمعة بعد تسربين كبيرين للبيانات. ومع ذلك، يسبق هذا التطبيق ظهور مفهوم البرمجة بالإحساس. وسيُحدد القضاء ما إذا كان الذكاء الاصطناعي هو المسؤول عن خطأ تطبيق “Tea” من عدمه. لكن في حالة الشركة الناشئة Enrichlead، كان الذكاء الاصطناعي هو الجاني بالتأكيد. وقد تباهى مؤسسها على وسائل التواصل الاجتماعي بأن 100% من التعليمات البرمجية لمنصته كُتبت بواسطة Cursor AI، مع “عدم وجود أي تعليمات برمجية مكتوبة يدويًا”. وبعد أيام قليلة من إطلاقه، وجد أنه مليء بثغرات أمنية بمستوى المبتدئين – مما سمح لأي شخص بالوصول إلى الميزات المدفوعة أو تغيير البيانات. وتم إغلاق المشروع بعد فشل المؤسس في رفع مستوى أمان التعليمات البرمجية إلى معيار مقبول باستخدام Cursor. ومع ذلك، يظل مصممًا على موقفه وقد بدأ منذ ذلك الحين مشاريع جديدة تعتمد على “البرمجة بالإحساس”.

الثغرات الأمنية الشائعة في التعليمات البرمجية التي يتم توليدها بواسطة الذكاء الاصطناعي

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

• الافتقار إلى التحقق من صحة المدخلات، وعدم تصحيح مدخلات المستخدم من الأحرف الدخيلة، والأخطاء الأساسية الأخرى التي تؤدي إلى ثغرات أمنية كلاسيكية مثل البرمجة النصية عبر المواقع (XSS) وحقن SQL.
• مفاتيح واجهة برمجة التطبيقات وغيرها من البيانات السرية المدرج بشكل ثابت مباشرة داخل صفحة الويب، والمكشوفة للمستخدمين في تعليماتها البرمجية.
• منطق المصادقة المُنفذ بالكامل في جانب العميل، مباشرةً في التعليمات البرمجية للموقع الذي يعمل في المستعرض. ويمكن تعديل هذا المنطق بسهولة لتجاوز أي عمليات تحقق.
• أخطاء التسجيل – من التصفية غير الكافية عند الكتابة إلى السجلات، إلى الغياب التام للسجلات.
• الدوال مفرطة القوة والخطيرة – يتم تحسين نماذج الذكاء الاصطناعي لإنتاج تعليمات برمجية تُنجز المهمة بأقصر طريقة ممكنة. لكن الطريق الأقصر غالباً ما يكون غير آمن. ويعد المثال النموذجي لذلك هو استخدام دالة eval لتنفيذ عمليات رياضية على مدخلات المستخدم. وهذا يفتح الباب أمام تنفيذ التعليمات البرمجية العشوائية في التطبيق الذي يتم إنشاؤه.
• التبعيات القديمة أو غير الموجودة. غالبًا ما تشير التعليمات البرمجية التي يولدها الذكاء الاصطناعي إلى إصدارات قديمة من المكتبات، أو ينفذ استدعاءات واجهة برمجة تطبيقات قديمة أو غير آمنة، أو حتى تحاول استيراد مكتبات وهمية. وهذا الاحتمال الأخير خطير بشكل خاص لأن المهاجمين يمكنهم إنشاء مكتبة ضارة باسم “معقول”، وسيقوم وكيل الذكاء الاصطناعي بتضمينها في مشروع حقيقي.

في دراسة منهجية، فحص المؤلفون التعليمات البرمجية التي ولدها الذكاء الاصطناعي بحثًا عن نقاط الضعف المدرجة في قائمة MITER CWE لأخطر 25 خطأ. وكانت المشكلات الأكثر شيوعًا هي CWE-94 (حقن التعليمات البرمجية) وCWE-78 (حقن أمر نظام التشغيل) وCWE-190 (تجاوز سعة العدد الصحيح) وCWE-306 (غياب المصادقة) وCWE-434 (تحميل الملفات دون قيود).

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

المطالبات الخطيرة

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

لكن الطريقة الأكثر فعالية هي استخدام إرشادات أمان مفصلة خاصة بكل لغة، بالاستناد إلى قوائم أخطاء MITRE أو OWASP. وتتوفر مجموعة كبيرة من تعليمات الأمان هذه من Wiz Research على GitHub؛ ويوصى بإضافتها إلى مطالبات نظام مساعدي الذكاء الاصطناعي عبر ملفات مثل claude.md أو .windsurfrules أو ما شابه ذلك.

تدهور الأمان أثناء المراجعات

عند مراجعة التعليمات البرمجية التي يتم إنشاؤها بواسطة الذكاء الاصطناعي بشكل متكرر من خلال مطالبات المتابعة، يتدهور مستوى الأمان الخاص بها. وفي دراسة حديثة طُلب من نموذج GPT-4o تعديل تعليمات برمجية مكتوبة مسبقًا بما يصل إلى 40 مرة، بينما فحص الباحثون كل نسخة بحثًا عن الثغرات الأمنية بعد كل جولة. وبعد خمس جولات فقط، احتوت التعليمات البرمجية على ثغرات أمنية حرجة أكثر بنسبة 37% مما كانت عليه في النسخة الأولي. واختبرت الدراسة أربع إستراتيجيات للمطالبة، ركزت ثلاث منها على مجالات مختلف: (1) الأداء و(2) الأمان و(3) الوظائف الجديدة؛ بينما كُتبت الرابعة بمُطالبات غير واضحة.

عندما ركزت المطالبات على إضافة ميزات جديدة، ظهرت 158 ثغرة أمنية – من بينها 29 ثغرة حرجة. وعندما أكدت المطالبة على البرمجة الآمنة، انخفض هذا العدد بشكل كبير – لكنه ظل يتضمن 38 ثغرة أمنية جديدة، سبع منها حرجة.

من المثير للاهتمام أن المطالبات التي “ركزت على الأمان” أسفرت عن أعلى نسبة من الأخطاء في الوظائف المتعلقة بالتشفير.

تجاهل سياق الصناعة

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

التكوين الخاطئ للتطبيق

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

• يتم إنشاء قواعد البيانات التي يحتاجها التطبيق باستخدام أذونات وصول خارجية واسعة النطاق بشكل مفرط. وينتج عن هذا عمليات تسريب مثلما حدث مع Tea/Sapphos، حيث لا يحتاج المهاجم حتى إلى استخدام التطبيق لتنزيل أو حذف قاعدة البيانات بأكملها.
• تُترك التطبيقات الداخلية للشركات متاحة للجمهور دون الحاجة إلى مصادقة.
• تُمنح التطبيقات صلاحيات عالية للوصول إلى قواعد البيانات الهامة. وإذا ما اقترن هذا بالثغرات الأمنية في التعليمات البرمجية المُولدة بواسطة الذكاء الاصطناعي، فإن ذلك يبسّط من عمليات حقن SQL والهجمات المماثلة.

الثغرات الأمنية في المنصات

تُشغّل معظم منصات البرمجة بالإحساس التطبيقات المولدة من المطالبات مباشرة على خوادمها الخاصة. ويؤدي ذلك إلى ربط المطورين بالمنصة – بما في ذلك تعرضهم للثغرات الأمنية واعتمادهم على ممارسات الأمان الخاصة بها. على سبيل المثال، تم اكتشاف ثغرة أمنية في منصة Base44 في شهر يوليو سمحت للمهاجمين الذين لم يتم مصادقتهم بالوصول إلى أي تطبيق خاص.

تهديدات مرحلة التطوير

إن مجرد وجود مساعد يتمتع بصلاحيات وصول واسعة على كمبيوتر المطور يولد مخاطر. وإليك بعض الأمثلة على ذلك:

سمحت الثغرة الأمنية “CurXecute (المسجلة بالرمز CVE-2025-54135) للمهاجمين بإصدار أوامر لأداة التطوير الشهيرة بالذكاء الاصطناعي، Cursor، لتنفيذ أوامر عشوائية على جهاز المطور. وكل ما تطلبه الأمر هو وجود خادم “بروتوكول سياق النموذج” (MCP) نشط متصل بأداة “Cursor”، والذي يمكن لطرف خارجي استخدامه للوصول. وهذا وضع نموذجي – حيث تمنح خوادم MCP وكلاء الذكاء الاصطناعي حق الوصول إلى رسائل “Slack” ومشكلات “Jira” وغيرها. ويمكن تنفيذ حقن المطالبة عبر أي من هذه القنوات.

سمحت الثغرة الأمنية “EscapeRoute” (المسجلة بالرمز CVE-2025-53109) بقراءة وكتابة ملفات عشوائية على قرص المطور. وكانت نقطة الضعف هذه موجودة في خادم “MCP” الشهير التابع لشركة Anthropic، الذي يتيح لوكلاء الذكاء الاصطناعي كتابة وقراءة الملفات في النظام. وببساطة، لم تعمل قيود الوصول الخاصة بالخادم.

قام خادم MCP ضار، كان يسمح لوكلاء الذكاء الاصطناعي بإرسال واستقبال البريد الإلكتروني عبر “Postmark”، بإعادة توجيه جميع المراسلات بشكل متزامن إلى عنوان مخفي. وكنا قد توقعنا ظهور خوادم MCP الضارة هذه في شهر سبتمبر الماضي.

سمحت ثغرة أمنية في واجهة سطر أوامر Gemini بتنفيذ أوامر عشوائية عندما طلب المطور ببساطة من مساعد الذكاء الاصطناعي تحليل تعليمات برمجية لمشروع جديد. وتم تشغيل الحقن الخبيث من ملف readme.md.

احتوى ملحق Q Developer من أمازون لأجل Visual Studio Code فترة وجيزة على تعليمات لمسح جميع البيانات من كمبيوتر المطور. وقد استغل مهاجم خطأً ارتكبه مطورو Amazon، وتمكّن من إدخال هذه المطالبة الضارة في التعليمات البرمجية العامة للمساعد دون الحاجة لامتيازات خاصة. ولحسن الحظ، منع خطأ برمجي بسيط تنفيذ هذا الأمر

سمحت ثغرة أمنية في وكيل Claude Code (المسجلة بالرمز CVE-2025-55284) بسحب البيانات من كمبيوتر المطور من خلال طلبات نظام أسماء النطاقات (DNS). وكان من الممكن تضمين هجوم حقن المطالبة، الذي اعتمد على أدوات مساعدة شائعة تعمل تلقائيًا دون تأكيد، في أي تعليمات برمجية يحللها الوكيل.

حذف وكيل الذكاء الاصطناعي المُستقل Replit قواعد البيانات الأساسية لمشروع كان يطوره، لأنه قرر أن قاعدة البيانات تحتاج إلى تنظيف. وقد انتهك هذا الأمر تعليمات مباشرة تحظر أي تعديلات (تجميد التعليمات البرمجية). ويكمن وراء هذا السلوك غير المتوقع للذكاء الاصطناعي عيب إنشائي رئيسي – وهو أنه في ذلك الوقت، لم تكن منصة “Replit” تفصل بين قواعد بيانات الاختبار والإنتاج.

تسبّب هجوم حقن المطالبة، الذي وُضع في تعليق ضمن التعليمات البرمجية المصدرية، في دفع بيئة التطوير “Windsurf” لتخزين تعليمات ضارة تلقائيًا في ذاكرتها طويلة الأمد، مما سمح لها بسرقة البيانات من النظام على مدار أشهر.

في حادثة اختراق منصة Nx، استُخدمت أدوات واجهة الأوامر الخاصة بكل من “Claude” و”Gemini” و”Q” للبحث عن كلمات المرور والمفاتيح التي يمكن سرقتها من النظام المُصاب.

كيفية استخدام الذكاء الاصطناعي بأمان

يمكن تقليل مستوى المخاطر الناجم عن التعليمات البرمجية المولدة بواسطة الذكاء الاصطناعي بشكل كبير، وإن لم يكن كلياً، من خلال مزيج من الإجراءات التنظيمية والتقنية:

• تنفيذ المراجعة التلقائية للتعليمات البرمجية المُولدة بواسطة الذكاء الاصطناعي أثناء كتابتها، باستخدام أدوات SAST (الفحص الأمني الثابت) المحسّنة.
• تضمين متطلبات الأمان في مطالبات النظام الخاصة بجميع بيئات الذكاء الاصطناعي.
• الاستعانة بمتخصصين بشريين ذوي خبرة لإجراء مراجعات مفصّلة للتعليمات البرمجية، بدعم من أدوات تحليل أمان متخصصة ومُعزّزة بالذكاء الاصطناعي لزيادة الفعالية.
• تدريب المطورين على كتابة مطالبات آمنة، وعلى نطاق أوسع، بتزويدهم بتعليم متعمق عن الاستخدام الآمن للذكاء الاصطناعي.