آخر الأخبار: نموذج GPT-6.1 Sol يوسّع فحص الثغرات داخل CodeRabbit

٢٧ أكتوبر ٢٠٢٦
الذكاء الاصطناعي والأعمال

نموذج GPT-6.1 Sol يوسّع فحص الثغرات داخل CodeRabbit

تستخدم CodeRabbit نموذج GPT-6.1 Sol لتحليل المخاطر الأمنية عبر مستودعات برمجية معقدة، وربط نتائج الفحص باقتراحات إصلاح قابلة للمراجعة البشرية.

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

صورة تعبيرية مولّدة بالذكاء الاصطناعي

شارك الخبر

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

تفاصيل الخبر

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

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

وتقول OpenAI إن النظام يستخدم GPT-6.1 Sol إلى جانب نماذج متقدمة أخرى وأدوات مخصصة لأمن البرمجيات، ما يعني أن النموذج ليس طبقة وحيدة تتولى كامل عملية التحقق. هذا النهج يجمع بين الاستدلال على بنية الشيفرة والفحوص الآلية المعروفة، مع إبقاء مراجعة النتائج ضمن سير العمل المعتاد لفرق التطوير.

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

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

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

وتؤكد OpenAI أن القرار النهائي بشأن التغييرات التي ستدخل إلى الإنتاج يبقى بيد المراجعين البشريين. لذلك تبدو قيمة GPT-6.1 Sol هنا مرتبطة بتقليل وقت التحقيق وتوسيع نطاق البحث، لا بإلغاء دور مهندسي الأمن أو تحويل الإصلاحات الآلية إلى تغييرات غير خاضعة للتدقيق.

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

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

شاركنا رأيك في التعليقات
العودة إلى جميع الأخبار

التعليقات

٠

كن أول من يشارك رأيه في هذا الخبر.