في الأشهر الأخيرة، تعجبنا من جودة الوجوه التي يتم إنشاؤها بواسطة الكمبيوتر، وصور القطط، ومقاطع الفيديو، والمقالات، وحتى الأعمال الفنية. كما انزلق الذكاء الاصطناعي (AI) والتعلم الآلي (ML) بهدوء إلى تطوير البرمجيات، باستخدام أدوات مثل GitHub Copilot، وTabnine، وPolycode، و اخرين اتخاذ الخطوة المنطقية التالية المتمثلة في وضع وظيفة الإكمال التلقائي للكود الحالي على منشطات الذكاء الاصطناعي. وعلى عكس صور القطط، فإن أصل كود التطبيق وجودته وأمانه يمكن أن يكون له آثار واسعة النطاق - وعلى الأقل بالنسبة للأمن، تظهر الأبحاث أن الخطر حقيقي.
قبل الأبحاث الأكاديمية لقد أظهر بالفعل أن GitHub Copilot غالبًا ما يقوم بإنشاء تعليمات برمجية تحتوي على ثغرات أمنية. وفي الآونة الأخيرة، أظهر التحليل العملي الذي أجراه مهندس الأمن في إنفيكتي، قادر أرسلان، ذلك اقتراحات التعليمات البرمجية غير الآمنة لا تزال هي القاعدة وليس الاستثناء مع مساعد الطيار. وجد أرسلان أن الاقتراحات الخاصة بالعديد من المهام الشائعة تتضمن فقط العناصر الأساسية المطلقة، وغالبًا ما تسلك الطريق الأكثر أساسية والأقل أمانًا، وأن قبولها دون تعديل قد يؤدي إلى تطبيقات وظيفية ولكنها ضعيفة.
أداة مثل Copilot هي (حسب تصميمها) ميزة الإكمال التلقائي، حيث تم تدريبها على تعليمات برمجية مفتوحة المصدر لاقتراح مقتطفات قد تكون ذات صلة في سياق مماثل. وهذا يجعل جودة الاقتراحات وأمنها مرتبطة ارتباطًا وثيقًا بجودة وأمان مجموعة التدريب. لذا فإن الأسئلة الأكبر لا تتعلق ببرنامج Copilot أو أي أداة محددة أخرى، بل تتعلق بالرمز البرمجي المولد بواسطة الذكاء الاصطناعي بشكل عام.
من المعقول أن نفترض أن مساعد الطيار هو مجرد رأس الرمح وأن المولدات المماثلة ستصبح شائعة في السنوات المقبلة. وهذا يعني أننا، في صناعة التكنولوجيا، بحاجة إلى البدء في التساؤل عن كيفية إنشاء مثل هذه التعليمات البرمجية، وكيفية استخدامها، ومن سيتحمل المسؤولية عندما تسوء الأمور.
متلازمة ساتناف
يعد الإكمال التلقائي للكود التقليدي الذي يبحث عن تعريفات الوظائف لإكمال أسماء الوظائف ويذكرك بالوسائط التي تحتاجها بمثابة توفير كبير للوقت. نظرًا لأن هذه الاقتراحات هي مجرد اختصار للبحث عن المستندات بنفسك، فقد تعلمنا أن نثق ضمنيًا في كل ما يقترحه IDE. بمجرد ظهور أداة تعمل بالذكاء الاصطناعي، لم يعد من المضمون أن تكون اقتراحاتها صحيحة، ولكنها لا تزال تشعر بالود والجديرة بالثقة، لذلك من المرجح أن يتم قبولها.
خاصة بالنسبة للمطورين الأقل خبرة، فإن سهولة الحصول على مجموعة مجانية من التعليمات البرمجية تشجع على التحول في العقلية من "هل هذا الرمز قريب بدرجة كافية مما سأكتبه" إلى "كيف يمكنني تعديل هذا الرمز حتى يناسبني".
ينص GitHub بوضوح شديد على أنه يجب دائمًا تحليل اقتراحات Copilot ومراجعتها واختبارها بعناية، ولكن الطبيعة البشرية تملي أنه حتى الكود الفرعي قد يصل أحيانًا إلى مرحلة الإنتاج. إنه يشبه إلى حد ما القيادة أثناء النظر إلى نظام تحديد المواقع العالمي (GPS) الخاص بك أكثر من النظر إلى الطريق.
قضايا أمن سلسلة التوريد
• الأزمة الأمنية Log4j لقد نقلت أمن سلسلة توريد البرمجيات، وعلى وجه التحديد، أمن المصادر المفتوحة إلى دائرة الضوء، مع أحدث التطورات مذكرة البيت الأبيض على تطوير البرمجيات الآمنة وجديدة مشروع قانون لتحسين أمن المصادر المفتوحة. مع هذه المبادرات وغيرها، قد يلزم قريبًا كتابة أي كود مفتوح المصدر في تطبيقاتك في قائمة مواد البرنامج (SBOM)، وهو أمر ممكن فقط إذا قمت عن قصد بتضمين تبعية محددة. تعتمد أدوات تحليل تكوين البرامج (SCA) أيضًا على تلك المعرفة لاكتشاف المكونات مفتوحة المصدر القديمة أو المعرضة للخطر ووضع علامة عليها.
ولكن ماذا لو كان تطبيقك يتضمن تعليمات برمجية تم إنشاؤها بواسطة الذكاء الاصطناعي والتي تنشأ في النهاية من مجموعة تدريب مفتوحة المصدر؟ من الناحية النظرية، إذا كان هناك اقتراح جوهري واحد مطابق للتعليمات البرمجية الموجودة وتم قبوله كما هو، فمن الممكن أن يكون لديك تعليمات برمجية مفتوحة المصدر في برنامجك ولكن ليس في SBOM الخاص بك. قد يؤدي هذا إلى مشكلات تتعلق بالامتثال، ناهيك عن احتمال تحمل المسؤولية إذا تبين أن التعليمات البرمجية غير آمنة وتؤدي إلى حدوث انتهاك - ولن يساعدك SCA، لأنه يمكنه فقط العثور على التبعيات الضعيفة، وليس نقاط الضعف في التعليمات البرمجية الخاصة بك .
مخاطر الترخيص والإسناد
لمواصلة هذا القطار الفكري، لاستخدام كود مفتوح المصدر، يجب عليك الالتزام بشروط الترخيص الخاصة به. اعتمادًا على الترخيص المحدد مفتوح المصدر، ستحتاج على الأقل إلى تقديم الإسناد أو في بعض الأحيان إصدار التعليمات البرمجية الخاصة بك كمصدر مفتوح. بعض التراخيص تحظر الاستخدام التجاري تمامًا. مهما كان الترخيص، فأنت بحاجة إلى معرفة مصدر الرمز وكيفية ترخيصه.
مرة أخرى، ماذا لو كان لديك تعليمات برمجية تم إنشاؤها بواسطة الذكاء الاصطناعي في تطبيقك والتي تتطابق مع التعليمات البرمجية مفتوحة المصدر الحالية؟ إذا قمت بإجراء تدقيق، فهل ستجد أنك تستخدم التعليمات البرمجية دون الإسناد المطلوب؟ أو ربما تحتاج إلى فتح مصدر لبعض التعليمات البرمجية التجارية الخاصة بك لتظل متوافقة؟ وربما لا يشكل هذا خطراً واقعياً بعد في ظل الأدوات الحالية، ولكن هذه هي الأسئلة التي ينبغي لنا جميعاً أن نطرحها اليوم، وليس بعد عشر سنوات. (ولتوضيح الأمر، يحتوي GitHub Copilot على مرشح اختياري لمنع الاقتراحات التي تتطابق مع التعليمات البرمجية الموجودة لتقليل مخاطر سلسلة التوريد.)
آثار أمنية أعمق
وبالعودة إلى الأمان، فإن نموذج الذكاء الاصطناعي/التعلم الآلي يكون جيدًا (وبنفس القدر من السوء) مثل مجموعة التدريب الخاصة به. لقد رأينا ذلك في الماضي - على سبيل المثال، في حالات خوارزميات التعرف على الوجوه تظهر التحيزات العنصرية بسبب البيانات التي تم تدريبهم عليها. لذلك، إذا كان لدينا بحث يوضح أن منشئ الأكواد ينتج في كثير من الأحيان اقتراحات دون أي اعتبار للأمان، فيمكننا أن نستنتج أن هذا هو ما كانت عليه مجموعة التعلم الخاصة به (أي التعليمات البرمجية المتاحة للجمهور). وماذا لو تم تغذية التعليمات البرمجية غير الآمنة التي تم إنشاؤها بواسطة الذكاء الاصطناعي إلى قاعدة التعليمات البرمجية تلك؟ هل يمكن أن تكون الاقتراحات آمنة على الإطلاق؟
الأسئلة الأمنية لا تتوقف عند هذا الحد. إذا اكتسبت مولدات الأكواد المستندة إلى الذكاء الاصطناعي شعبية وبدأت في حساب نسبة كبيرة من الأكواد الجديدة، فمن المحتمل أن يحاول شخص ما مهاجمتها. من الممكن بالفعل خداع التعرف على الصور بواسطة الذكاء الاصطناعي عن طريق تسميم مجموعة التعلم الخاصة به. عاجلاً أم آجلاً، ستحاول الجهات الخبيثة وضع تعليمات برمجية ضعيفة بشكل فريد في المستودعات العامة على أمل أن تظهر في الاقتراحات وينتهي بها الأمر في النهاية في تطبيق إنتاج، مما يفتحها أمام هجوم سهل.
وماذا عن الزراعة الأحادية؟ إذا انتهى الأمر بتطبيقات متعددة باستخدام نفس الاقتراح الضعيف للغاية، مهما كان مصدره، فيمكننا أن ننظر إلى أوبئة الضعف أو ربما حتى نقاط الضعف الخاصة بالذكاء الاصطناعي.
مراقبة الذكاء الاصطناعي
قد تبدو بعض هذه السيناريوهات بعيدة المنال اليوم، لكنها كلها أشياء نحتاج إلى مناقشتها في صناعة التكنولوجيا. مرة أخرى، يقع GitHub Copilot في دائرة الضوء فقط لأنه يقود الطريق حاليًا، ويقدم GitHub تحذيرات واضحة حول محاذير الاقتراحات التي يولدها الذكاء الاصطناعي. كما هو الحال مع الإكمال التلقائي على هاتفك أو اقتراحات المسار في نظام الملاحة عبر الأقمار الصناعية الخاص بك، فهي مجرد تلميحات لجعل حياتنا أسهل، والأمر متروك لنا أن نأخذها أو نتركها.
بفضل قدرتها على تحسين كفاءة التطوير بشكل كبير، من المرجح أن تصبح مولدات الأكواد المستندة إلى الذكاء الاصطناعي جزءًا دائمًا من عالم البرمجيات. فيما يتعلق بأمان التطبيق، يعد هذا مصدرًا آخر للتعليمات البرمجية التي يحتمل أن تكون عرضة للخطر والتي تحتاج إلى اجتياز اختبارات أمنية صارمة قبل السماح لها بالدخول في مرحلة الإنتاج. نحن نبحث عن طريقة جديدة تمامًا لإدخال الثغرات الأمنية (وربما التبعيات التي لم يتم التحقق منها) مباشرةً في كود الطرف الأول الخاص بك، لذلك فمن المنطقي التعامل مع قواعد التعليمات البرمجية المعززة بالذكاء الاصطناعي على أنها غير موثوقة حتى يتم اختبارها - وهذا يعني اختبار كل شيء بقدر ما تفعله يستطيع.
حتى حلول تعلم الآلة الشفافة نسبيًا مثل Copilot تثير بالفعل بعض الأسئلة القانونية والأخلاقية، ناهيك عن المخاوف الأمنية. لكن تخيل فقط أنه في يوم من الأيام، تبدأ أداة جديدة في إنشاء تعليمات برمجية تعمل بشكل مثالي وتجتاز اختبارات الأمان، باستثناء تفصيل واحد صغير: لا أحد يعرف كيف يعمل. وذلك عندما يحين وقت الذعر.
