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

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

ما المقصود باكتشافات الأمان بالذكاء الاصطناعي في GitHub؟

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

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

كيف تعمل الميزة داخل طلبات السحب؟

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

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

ما أنواع المخاطر التي تغطيها؟

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

والجانب العملي هنا أن GitHub لا تطرح الميزة كبديل شامل لكل أدوات الأمن، بل كطبقة توسعة ذكية داخل سير العمل نفسه. إذا كنت تتابع أيضًا مسار جودة الكود في المنصة، فستلاحظ أن هذا الاتجاه ينسجم مع مقالنا عن GitHub Code Quality، حيث تحاول GitHub جمع الجودة والأمن والإصلاح الذكي في مكان واحد بدل تشتيت الفريق بين خدمات متعددة.

ما الذي تحتاجه المؤسسة لتفعيلها؟

هنا تظهر التفاصيل التي تهم فرق المنصات وفرق الأمن أكثر من العنوان التسويقي. فالميزة ليست مفعلة افتراضيًا على مستوى المؤسسة. توضّح GitHub أن المؤسسة يجب أن تسمح أولًا بسياسة AI Findings، وبعدها يمكن لمسؤولي المؤسسة أو المنظمة تفعيلها على المستودعات المناسبة. كذلك يجب أن يكون CodeQL default setup مفعّلًا في المستودع، لأن المحرك الجديد يعتمد على هذا السياق حتى لو لم يكن CodeQL هو الأداة التي تجري التحليل نفسه.

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

هل تدعم لغات غير مشمولة جيدًا في CodeQL؟

نعم، وهذه إحدى أهم نقاط القوة. توضح الوثائق أن الميزة مصممة لتوسيع التغطية إلى لغات وأطر عمل لا تحصل على دعم أصلي كامل من CodeQL، مثل بعض حالات PHP وShell وTerraform وDockerfiles، إلى جانب فجوات تغطية في أطر مثل JSP وBlazor. عمليًا، هذا يمنح الفرق التي تبني أنظمة هجينة أو بنى تحتية معقدة فرصة أفضل لرؤية إشارات أمنية كانت تضيع سابقًا بين الأدوات المختلفة.

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

أين تظهر النتائج؟ وهل يمكن إصلاحها بسرعة؟

بحسب GitHub، تظهر النتائج على تبويبي Conversation وFiles changed داخل طلب السحب، وهو موضع ذكي لأنها تضع التنبيه في المكان الذي يتخذ فيه الفريق قرار الدمج أصلًا. وعندما تتوفر معالجة مقترحة، يمكن أن يظهر معها Copilot Autofix ليقترح تعديلًا يساعد المطور على إصلاح الخلل بسرعة أكبر.

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

ما القيود الحالية التي يجب الانتباه لها؟

حتى الآن، تؤكد GitHub أن اكتشافات الأمان بالذكاء الاصطناعي في GitHub ما تزال في معاينة عامة، وأنها تركز على طلبات السحب فقط، ولا تنتج backlog alerts كاملة على مستوى المستودع كما تفعل بعض نتائج CodeQL. كما لا يمكن استخدام هذه النتائج في rulesets لفرض منع الدمج تلقائيًا في هذه المرحلة.

إضافة إلى ذلك، تذكر الوثائق أن الميزة تحتاج إلى GitHub Advanced Security مع رخصة GitHub Copilot خلال فترة المعاينة، وأن استخدامها يستهلك AI credits. هذه نقطة مهمة لأن التبني هنا ليس قرارًا تقنيًا فقط، بل قرار ميزانية أيضًا، خصوصًا لدى المؤسسات التي تراقب استهلاك الذكاء الاصطناعي بدقة متزايدة.

لماذا قد يهم هذا التحديث فرق التطوير الآن؟

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

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

الخلاصة

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

إذا كانت مؤسستك تستخدم GitHub Code Scanning وCodeQL بالفعل، فقد يكون هذا التحديث من أكثر الإضافات العملية التي تستحق التجربة خلال النصف الثاني من 2026، خاصة إذا كانت لديك مستودعات متعددة اللغات أو رغبة في رفع مستوى المراجعة الأمنية دون تفكيك سير العمل الحالي.