لماذا يُكسر رمز الأمان المُولَّد بواسطة الذكاء الاصطناعي نموذج إدارة الثغرات الأمنية الخاص بك

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

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

مشكلة الاعتماد أصبحت مشكلة الذكاء الاصطناعي

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

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

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

فحص ما بعد الحادثة ليس استراتيجية

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

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

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

التبدیل الذي يعمل بالفعل: التحكم في ما يدخل

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

هذا النهج يُحول الأمان إلى اليسار في أكثر المعاني الحرفية. يتم حظر الثغرات الأمنية في نقطة الاستهلاك، قبل أن تدخل خط أنابيب البناء. يستخدم المطورون نفس الأدوات التي كانوا يستخدمونها دائمًا. تُحَلّ зависимости مساعدات الترميز الذكية من نفس المصدر المحكوم. يحدد فريق الأمان السياسة مرة واحدة، وتتطبق هذه السياسة في كل مكان، بما في ذلك الرمز الذي تم توليده بواسطة نموذج في الساعة 2 صباحًا دون أي استعراض بشري.

ما يبدو عليه هذا في الممارسة

لمن يبحث في هذا الموضوع، هناك بعض الأمور التي تهم أكثر من غيرها:

1. حدد مجموعة المكونات المعتمدة قبل أن توسع في اعتماد الذكاء الاصطناعي. إذا كانت أدوات الترميز الذكية الخاصة بك تحل الاعتماديات من السجلات العامة، فعملية الموافقة الخاصة بك موجودة فقط على الورق. أنشئ سجلًا داخليًا محكومًا، ووجه كل شيء من خلاله، واطلب أن يتم بناء المكونات من المصدر مع إثبات الأصل.
2. عامل الإصلاح كعملية محكومة، وليس كطابوق تذاكر. المنظمات التي تظل متقدمة على الديون الأمنية لا تتحرك بسرعة أكبر في الإصلاح اليدوي. لقد أزالوا الإصلاح اليدوي من المعادلة. عندما يكون هناك تصحيح موافق من المجتمع متاح، يتم إعادة بناؤه تلقائيًا في الفهرس. يحصل المطورون على التحديث في المرة التالية التي يسحبون فيها. لا أحد يُعيّن تذكرة. لا أحد ينتظر 60 يومًا.
3. رسم خريطة لسلسلة أدوات الذكاء الاصطناعي إلى التزاماتك بالامتثال قبل أن يُجبر عليك ذلك. لقد شاهدت فرقًا تبني على أدوات الذكاء الاصطناعي لشهر، فقط ليتعرضوا لجدار عندما يطلب عميل توافق FedRAMP أو دليل إثبات SOC 2. فهرسك المُحكَم هو أيضًا سجل تدقيق الامتثال الخاص بك. يجب أن تُرفق سجلات مصدر البنية (SBOMs) وسجلات الأصل مع كل مكون، وليس تجميعها بشكل استرجاعي تحت ضغط الموعد.
4. تعيين ملكية واضحة على مستوى الحوكمة، وليس على مستوى التذاكر. الفرق التي تتحرك بسرعة أكبر في الإصلاح هي ليس تلك التي لديها أكثر المطورين. بل تلك التي يملك فيها فريق الأمان السياسة، ويملك فريق المنصة التسليم، ولا ينتظر أي منهما على الآخر للعمل.

أمان يمكّن بدلاً من حظر

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

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