آي بي إم تخطط لدمج Claude Mythos في اكتشاف الثغرات في مطلع 2027

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

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

ما الذي تعتزم آي بي إم ربطه

يصف إعلان آي بي إم ثلاث مراحل. سيحلل Mythos المستودعات التي يختارها العميل ويبحث عن ثغرات مجهولة سابقًا. وعلى Concert Protect أن يقيّم إمكانية الاستغلال مع مراعاة الشيفرة والإعدادات والبنية التحتية. بعد ذلك ستساعد أدوات آي بي إم وRed Hat في إعداد تغييرات يراجعها المطورون ويوافقون عليها. وتخطط الشركة للإتاحة العامة في مطلع 2027، وتحذّر من أن الخطط قد تتغير.

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

كيف يبدو ذلك في خدمة عادية

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

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

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

ما الذي يجب التحقق منه قبل التبني

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

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

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