برامج الذكاء الاصطناعي الخبيثة تفرض: توسيع Zero Trust ليشمل الكود

لطالما بُني أمن البرمجيات حول التطوير البشري. كان البشر يكتبون التعليمات البرمجية ويراجعونها وينشرونها. أما الآن، فقد أصبحت الآلات تتولى هذه المهام.

في ورقة بحثية حديثة، أفادت شركة Anthropic أن أكثر من 80% من التعليمات البرمجية المدمجة في قاعدة بياناتها الإنتاجية يتم تأليفها بواسطة نموذج الذكاء الاصطناعي الخاص بها، Claude.

إن نفس القدرات التي تزيد من إنتاجية المطورين تُغير اقتصاديات الهجمات السيبرانية.

بينما لا يزال الخصوم يحددون الهدف، تستطيع الآلات توليد الحمولات الخبيثة، واختبار المتغيرات، وتكييف التعليمات البرمجية مع بيئات مختلفة، وتكرار العملية بسرعة لا تستطيع برامج الأمن مجاراتها.

السرعة تُهمّش ضوابط الأمن

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

ينهار هذا النموذج عندما ينتقل البرنامج من مجرد توجيه إلى تنفيذ في غضون دقائق.

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

لم يعد المراجعون البشريون جزءًا من العملية.

يمكن للمهاجمين استخدام نفس الآليات لتوليد الثغرات، واختبار تقنيات التهرب، وتعديل سلوك الحمولات الخبيثة لأهداف مختلفة. وهذا يخلق تنوعًا أكبر مع مؤشرات مستقرة أقل يمكن للمدافعين التعرف عليها.

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

الآلات تُغير نموذج الهجوم

المهاجمون البشريون لن يختفوا، لكن جزءًا أكبر من سلسلة الهجوم أصبح يُنفذ بواسطة الآلات.

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

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

إن ما تستطيع التعليمات البرمجية الخبيثة فعله هو الإشارة الأمنية الأكثر ديمومة.

الأمن يحتاج إلى طرح سؤال مختلف

لقد تحسن أمن سلسلة توريد البرمجيات، لكن جزءًا كبيرًا منه لا يزال يتحقق من خصائص الأثر قبل التنفيذ بدلاً من التحكم في التنفيذ نفسه.

توفر قوائم مكونات البرمجيات (SBOMs)، والتوقيع، والمصدر فرق الأمن ثقة أكبر في تكوين التعليمات البرمجية، وأصلها، وتاريخ بنائها. لكن معرفة مصدر البرنامج لا يكشف عما سيفعله عند تشغيله.

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

الكشف بعد التنفيذ يأتي متأخرًا جدًا

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

يُقلص الذكاء الاصطناعي هذه النافذة الزمنية بشكل كبير. فالتعليمات البرمجية يمكن إنشاؤها وتعديلها ونشرها بسرعة تفوق قدرة البشر على مراجعتها. والانتظار حتى ظهور أدلة ما بعد التنفيذ يمنح المهاجمين مساحة كبيرة جدًا للعمل.

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

هذا لا يعني استبدال الضوابط الحالية، بل تغيير مكان البوابة الأمنية الحاسمة.

الثقة المعدومة للتعليمات البرمجية

غيّر مبدأ الثقة المعدومة (Zero Trust) أمن المؤسسات برفضه الثقة الضمنية. فلا يُوثق بالمستخدمين أو الأجهزة أو الجلسات أو طلبات الوصول لمجرد أنها تبدو مألوفة، بل يجب التحقق منها جميعًا وفقًا للسياسات المحددة.

ويتطلب تنفيذ البرمجيات نفس مستوى التحقق هذا.

لا ينبغي الوثوق بالتعليمات البرمجية لمجرد أنها جاءت من مستودع معروف، أو تم توقيعها من قبل ناشر معترف به، أو مرت عبر مسار بناء (build pipeline)، أو لم يسبق لها أن أظهرت سلوكًا خبيثًا. هذه مؤشرات مفيدة، لكنها ليست حاسمة.

يعالج مبدأ الثقة المعدومة للتعليمات البرمجية (Zero Trust for Code) هذه المشكلة. فقبل تشغيل أي برنامج، يجب تقييم سلوكه المتوقع مقابل السياسات. إذا كان السلوك مقبولاً، يمكن أن يستمر التنفيذ. وإذا لم يكن كذلك، يجب حظر العنصر، أو تقييده، أو عزله، أو تصعيده للمراجعة. تُبرز هذه الحاجة أهمية وضع قواعد وأطر واضحة للذكاء الاصطناعي تتجاوز مجرد السياسات.

يمكن للمؤسسات البدء بتحديد كل مسار تدخل من خلاله التعليمات البرمجية إلى البيئة أو تُنفذ بامتيازات مهمة. يشمل ذلك قنوات التطوير الرسمية مثل المستودعات (repositories)، وحزم المصادر المفتوحة (open-source packages)، والحاويات (containers)، ومسارات التكامل المستمر/النشر المستمر (CI/CD pipelines)، بالإضافة إلى مرفقات البريد الإلكتروني، والملفات التي يتم تنزيلها، ووحدات الماكرو (macros)، وإضافات المتصفح، ومثبتات نقاط النهاية (endpoint installers)، وعمليات التكامل مع جهات خارجية، والبرامج النصية التي تُدخل عبر أدوات الذكاء الاصطناعي أو الأتمتة.

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

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

لقد أدرجنا أفضل مجموعات أمان الإنترنت لأجهزة الكمبيوتر الشخصية و Mac والأجهزة المحمولة.