GitHub Agentic Autofix: حين يصلح Copilot ثغرات CodeQL ويتحقق من إصلاحه بنفسه

في 15 أكتوبر 2026 أعلنت GitHub أن ميزة الإصلاح الوكيلي (Agentic Autofix) لتنبيهات فحص الشيفرة صارت متاحة للعموم بعد فترة معاينة عامة بدأت في يوليو. الفكرة المختصرة: بدل أن يقرأ المطوّر تنبيه CodeQL ثم يبحث بنفسه عن موضع الخلل ويكتب الإصلاح، يُسنِد التنبيه إلى Copilot فيستكشف الملفات ذات الصلة، ويقترح تعديلاً، ويعيد تشغيل CodeQL للتأكد من أن التنبيه أُغلق فعلاً، ثم يفتح طلب دمج بصيغة مسودة. في هذا المقال نشرح ما الجديد، وكيف يختلف عن الإصلاح التلقائي القديم، وما القيود التي ينبغي أن تعرفها قبل تفعيله في فريقك.

ما الذي تغيّر فعلاً؟

كان Copilot Autofix التقليدي يعمل بمنطق «اقتراح واحد»: ينظر إلى تنبيه واحد ويولّد تعديلاً مقترحاً مع شرح، ثم يُترك للمطوّر أن يطبّقه ويختبره. النسخة الوكيلية تضيف حلقة تحقق وتكرار:

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

الفارق الجوهري هو أن الوكيل لا يكتفي بالتخمين؛ لديه إشارة موضوعية (نجاح فحص CodeQL) يقيس بها عمله. وهذا ما يجعل الميزة أقرب إلى «زميل يجرّب ويتحقق» منها إلى «مولّد اقتراحات».

الإصلاح الذي لم يجتز فحص الأمان لا يستحق أن يصل إلى المراجعة أصلاً؛ قيمة الوكيل هنا في أنه يرفض تسليم ما لم يتحقق منه.

كيف تُسنِد التنبيه إلى Copilot؟

توفّر GitHub ثلاث طرق للتشغيل:

1. من صفحة التنبيه نفسها: افتح أي تنبيه فحص شيفرة على الفرع الافتراضي، وأسنده إلى Copilot.
2. من قائمة التنبيهات أو حملة أمنية (Security Campaign): حدّد حتى 25 تنبيهاً دفعة واحدة ليعالجها Copilot في طلب دمج واحد.
3. عبر واجهة REST: تحدّث تنبيه الفحص وتضبط المُسنَد إليه على الحساب copilot-swe-agent[bot]، وهذا يفتح الباب لأتمتة المعالجة داخل خطوط العمل لديك.

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

مقارنة سريعة بين النسختين

الجانب	الإصلاح التقليدي	الإصلاح الوكيلي
طريقة العمل	اقتراح واحد لتنبيه واحد	استكشاف وتجريب وتكرار
التحقق	يعتمد عليك	يعيد تشغيل CodeQL
المخرجات	تعديل مقترح وشرح	طلب دمج بصيغة مسودة
الحجم	تنبيه واحد	حتى 25 تنبيهاً معاً
التشغيل برمجياً	محدود	عبر REST API

القيود التي لا يذكرها العنوان

الإعلان مشجّع، لكن في التفاصيل ما يستحق القراءة قبل أن تبني عليه خطة:

• الفرع الافتراضي فقط: التنبيهات المكتشفة على طلبات دمج أو فروع أخرى لا يمكن إسنادها إلى Copilot.
• ترخيص مدفوع: الميزة متاحة لعملاء GitHub Code Security وGitHub Advanced Security على GitHub Enterprise Cloud، ويتطلب تفعيلها أن يمكّن مشرف المؤسسة سياسة الإصلاح الوكيلي ويضبط طريقة الفوترة.
• استهلاك مزدوج: يستهلك كل تشغيل رصيد AI Credits من ميزانية Code Security، ويستهلك كذلك دقائق GitHub Actions. أي أن تكلفته ليست صفراً حتى لو كانت الميزة مدمجة.
• لا ضمان للصحة: تقول GitHub صراحة إنه لا يضمن إصلاح كل ثغرة إصلاحاً صحيحاً، والمراجعة البشرية قبل الدمج مطلوبة.
• حدود التحقق: وفق وثائق المعاينة، لا يستطيع التحقق بإعادة CodeQL تأكيد التنبيهات الناتجة عن استعلامات مخصصة أو عن مجموعة security-extended. تحقق من بقاء هذا القيد بعد الإتاحة العامة.

الاستعمال الأمثل إذن هو التنبيهات القياسية المتكررة على الفرع الرئيسي، لا الاستعلامات الخاصة المعقدة.

كيف تدخله إلى فريقك بأمان؟

نقترح مساراً تدريجياً بدل التفعيل الشامل:

1. ابدأ بمستودع واحد منخفض المخاطر

اختر مستودعاً فيه اختبارات جيدة وتنبيهات من النوع المتكرر، وفعّل السياسة له وحده. راقب كم طلب دمج قُبل كما هو وكم احتاج تعديلاً.

2. اشترط اجتياز الاختبارات قبل المراجعة

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

3. ضع سقفاً للتكلفة

راقب ميزانية AI Credits ودقائق Actions منذ الأسبوع الأول. التجميع في دفعات من 25 تنبيهاً قد يوفّر الوقت لكنه يرفع حجم المراجعة في طلب واحد؛ ابدأ بدفعات أصغر.

4. راجع بعين مهندس لا بعين موافِق

المسودة ليست قراراً. اقرأ الفرق بين الشيفرتين كما تقرأ تعديل زميل جديد: هل عالج السبب الجذري أم أخفى العَرَض؟ هل أضاف تعقيداً غير لازم؟

أين يقع هذا من الصورة الأكبر؟

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

أمثلة على التنبيهات المناسبة وغير المناسبة

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

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

مؤشرات لقياس النجاح

• نسبة القبول: كم مسودة دُمجت دون تعديل جوهري.
• زمن المعالجة: المدة بين ظهور التنبيه وإغلاقه قبل التفعيل وبعده.
• الانحدار: عدد الأعطال التي نتجت عن إصلاح آلي وظهرت بعد الدمج.
• التكلفة لكل إصلاح: الرصيد ودقائق Actions مقسومة على التنبيهات المغلقة.

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

أسئلة شائعة

هل يدمج Copilot الإصلاح تلقائياً؟

لا. يفتح طلب دمج بصيغة مسودة، وتبقى المراجعة والموافقة على عاتق فريقك.

هل يعمل على أي تنبيه في أي فرع؟

لا. يعمل على التنبيهات المكتشفة على الفرع الافتراضي للمستودع، ولا يمكن إسناد تنبيهات الفروع الأخرى أو طلبات الدمج إليه.

هل الميزة مجانية؟

لا. تتطلب GitHub Code Security أو Advanced Security على Enterprise Cloud، وتستهلك AI Credits ودقائق GitHub Actions.

الخلاصة

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

المصادر: GitHub Changelog، daily.dev، WindowsForum