فوضى صناعة البرمجيات تشتد: كيف تسرع الذكاء الاصطناعي من التحديات الأمنية

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

تراجع تكلفة كتابة الكود وارتفاع تكلفة الفهم

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

الذكاء الاصطناعي الذي يتصرف وليس فقط يتحدث

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

المخاطر الناتجة عن اتخاذ إجراءات من قبل الذكاء الاصطناعي

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

التحدي الحقيقي: التخطي والتجاوز

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

مخاطر الاعتماد على رموز وصول غير محكمة

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

الحاجة إلى هوية موثوقة لكل إجراء

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

الاعتمادية على رموز الوصول الرخيصة تُضاعف الأخطاء

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

تكرار الأخطاء في ظل الاندفاع الحالي

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

مبدأ أساسي لسلامة إدارة الذكاء الاصطناعي

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

اختبار سريع في حالة الطوارئ لليلة الثالثة فجراً

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

الخلاصة: كن حذرًا قبل أن تتفاقم الفوضى

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