لم تعد مشكلة Chrome هي العثور على الثغرات بقدر ما أصبحت في استيعاب سرعتها.
خلال إصدارين رئيسيين فقط في يونيو، أصلح فريق Chrome عددًا وصل إلى 1,072 ثغرة أمنية، وهو رقم يفوق مجموع الإصلاحات التي صدرت عبر 23 إصدارًا رئيسيًا سابقًا. هذا الارتفاع لم يكن نتيجة تدفق تقارير الباحثين وحده، بل ارتبط بشكل كبير بتوسع Google في استخدام أدوات الذكاء الاصطناعي داخل عمليات اكتشاف الثغرات، وفرزها، والمساعدة في تطوير الإصلاحات.
النتيجة كانت ضغطًا مباشرًا على دورة التحديث نفسها. Chrome، الذي يتجه أصلًا إلى إصدار رئيسي كل أسبوعين مع تحديثات أمنية أسبوعية إضافية، بدأ الآن تجربة إصدار ترقيعات أمنية مرتين في الأسبوع للتعامل مع الكم المتزايد من المشكلات المكتشفة.
المشهد هنا لا يتعلق فقط بسرعة Patch Management. ما يحدث داخل Chrome يعكس تحولًا أوسع في أمن البرمجيات: عندما تصبح أدوات AI قادرة على فهم تاريخ مشروع ضخم مثل Chromium، وربط كل سطر كود تقريبًا بسياق تغييره والثغرات السابقة المرتبطة به، فإن عملية البحث عن العيوب تبدأ بالتحول من نشاط بشري كثيف إلى عملية مستمرة ومدعومة بنماذج تعرف تاريخ المشروع نفسه.
#TL;DR
- أصلح Chrome خلال إصدارين رئيسيين في يونيو 1,072 ثغرة أمنية، أكثر مما أُصلح في 23 إصدارًا رئيسيًا سابقًا مجتمعة.
- الزيادة جاءت بدرجة كبيرة من توسع فريق Chrome في استخدام أدوات AI لاكتشاف الثغرات وفرزها والمساعدة في إصلاحها.
- Google تختبر حاليًا إصدار تحديثات أمنية لـ Chrome مرتين أسبوعيًا.
- Chrome كان يتجه أصلًا إلى إصدار رئيسي كل أسبوعين، مع تحديثات أمنية أسبوعية إضافية.
- نماذج الفريق تُدرّب على تاريخ ثغرات المشروع وتغييرات كود Chromium لفهم سبب تعديل الأسطر عبر الزمن.
- الفريق لا يركز فقط على الترقيعات، بل أيضًا على تقليل فئات كاملة من العيوب عبر إعادة كتابة أجزاء من C++ بلغة Rust الآمنة للذاكرة.
#من ستة أسابيع إلى مرتين في الأسبوع
كان Chrome من أوائل المتصفحات التي دفعت بقوة نحو نموذج التحديث التلقائي، وهو توجه كان مثيرًا للجدل قبل نحو عقد، عندما كان إصدار تحديث كل ستة أسابيع يُعد سريعًا نسبيًا.
اليوم تغيّر المعيار. أصبح من الطبيعي أن تتلقى البرمجيات واسعة الاستخدام تحديثات أمنية كل بضعة أسابيع، لكن دخول أدوات الذكاء الاصطناعي إلى اكتشاف الثغرات رفع وتيرة المشكلة نفسها: كلما أصبح العثور على الأخطاء أسرع، أصبح على فرق التطوير أيضًا أن تكون أسرع في التحقق منها، وتحديد خطورتها، وتطوير إصلاحاتها، ثم شحن تلك الإصلاحات للمستخدمين.
وفق تقرير نشره فريق Chrome الأمني، فإن الإصدارين الرئيسيين في يونيو تضمنا إصلاحات لـ 1,072 مشكلة أمنية. ويشير التقرير إلى أن جزءًا من هذه الثغرات جاء من بلاغات باحثين خارجيين، لكن الارتفاع الكبير ارتبط أيضًا بتطور العمليات الداخلية التي يستخدم فيها الفريق أدوات AI ضمن دورة اكتشاف الثغرات والتعامل معها.
هذه الزيادة دفعت Chrome إلى تجربة إيقاع أسرع لتحديثاته الأمنية. الفريق يعمل بالفعل باتجاه إصدار رئيسي كل أسبوعين، مع تحديثات أمنية أسبوعية إضافية، لكنه بدأ حاليًا اختبار إصدار إصلاحات أمنية مرتين أسبوعيًا.
Doug Turner، مدير الهندسة في Chrome، أوضح أن السبب مباشر: عدد إصلاحات الثغرات أصبح كبيرًا لدرجة أن توفير تحديثين أسبوعيًا كان الخيار المنطقي خلال هذه المرحلة. لكنه لم يعتبر ذلك بالضرورة جدولًا دائمًا.
#الذكاء الاصطناعي لم يدخل أمن Chrome حديثًا
استخدام تقنيات الذكاء الاصطناعي داخل Chrome ليس ظاهرة بدأت مع موجة النماذج التوليدية الحالية.
Parisa Tabriz، نائبة الرئيس والمديرة العامة لـ Chrome، تقول إن الفريق يستخدم Machine Learning منذ عام 2012 على الأقل للمساعدة في العثور على الثغرات وأتمتة أعمال Fuzz Testing.
الـ Fuzzing يعتمد على تمرير مدخلات كثيرة، غير متوقعة أو مشوهة، إلى البرامج بهدف دفعها إلى حالات لم يتوقعها المطورون، ثم مراقبة الأعطال أو السلوكيات الشاذة التي قد تكشف أخطاء أمنية.
لكن الفارق في الفترة الحالية، بحسب Tabriz، هو أن مستوى القدرات تغيّر بصورة كبيرة. الذكاء الاصطناعي لم يعد مجرد أداة مساعدة لتوسيع نطاق الاختبار، بل أصبح قادرًا على التعامل مع كم أكبر بكثير من السياق المتعلق بتاريخ المشروع والثغرات السابقة.
وهنا تبدأ النقلة الأهم.
#نموذج يعرف كل CVE تقريبًا وتاريخ كل سطر كود
بحسب Turner، يعمل الفريق على تدريب نماذجه بحيث تعرف كل ثغرة أمنية سبق للفريق التعامل معها.
بمعنى آخر، كل CVE وكل Bug أمني سابق يصبح جزءًا من السياق الذي يستطيع النموذج الاستفادة منه عند تحليل أجزاء أخرى من المشروع.
لكن الميزة الثانية أكثر لفتًا للانتباه: النموذج لا يتعامل مع الحالة الحالية من كود Chromium فقط، بل يتعلم أيضًا تاريخ تغييرات الكود والسبب وراء تعديل كل سطر عبر عمر المشروع.
هذا النوع من السياق التاريخي يغيّر طريقة البحث عن الثغرات جذريًا. بدل تحليل وظيفة أو Module بمعزل عن الماضي، يمكن للأداة أن تربط بين:
- سلوك حالي داخل الكود.
- ثغرات ظهرت سابقًا في أجزاء مشابهة.
- تغييرات أمنية حدثت عبر الزمن.
- مناطق قديمة في المشروع لم تعد تحظى بنفس مستوى المراجعة البشرية.
هذه القدرة تصبح أكثر أهمية في مشروع بحجم Chromium، حيث يحتوي المستودع على كمية ضخمة من المكونات والميزات المتراكمة عبر سنوات طويلة.
#لماذا تصبح الميزات القديمة هدفًا مثاليًا للتحليل؟
أحد الأمثلة التي أشار إليها الفريق هو ميزات مثل الطباعة.
بعض مكونات المشروع لا تخضع لتطوير نشط مستمر، لكنها تبقى جزءًا من Codebase ضخم ويعتمد عليها المستخدمون. هذه الأجزاء قد لا تتلقى نفس كمية المراجعة البشرية التي تحصل عليها الميزات الجديدة أو المناطق التي يعمل عليها المطورون يوميًا.
هنا يمكن لأدوات AI أن تلعب دورًا مختلفًا عن الباحث البشري.
بدل الاعتماد فقط على اهتمام الباحث بميزة معينة، يمكن للنموذج فحص مساحات كبيرة من المشروع وربطها بتاريخ الثغرات والتغييرات السابقة، ثم تضييق نطاق البحث باتجاه مواضع يحتمل أن تحتوي على مشاكل.
بالنسبة إلى Chrome، هذا يعني أن أدوات الذكاء الاصطناعي قد تساعد في إعادة فتح مناطق من المشروع لم تكن بالضرورة في صدارة أعمال المراجعة الأمنية.
#طفرة الثغرات قد لا تستمر إلى الأبد
الزيادة الحالية في الثغرات المكتشفة لا تعني بالضرورة أن عدد العيوب سيستمر في الارتفاع بالمعدل نفسه إلى ما لا نهاية.
Turner يشير إلى احتمال الوصول إلى نقطة يبدأ عندها عدد الثغرات الجديدة في الانخفاض، خصوصًا في المنتجات الناضجة والمستقرة مثل Chrome، بعد إصلاح الجزء الأكبر من العيوب التي تستطيع أدوات AI الحالية العثور عليها.
الفكرة قريبة من عملية تمشيط شاملة لقاعدة كود ضخمة: في البداية، قد تُظهر الأدوات عددًا كبيرًا من الأخطاء المتراكمة، لكن بعد إصلاحها تصبح المناطق المتبقية أصعب وأقل عددًا.
Tabriz تتوقع بدورها أن تكون الزيادة الحالية مرحلة مؤقتة قبل الوصول إلى مستوى جديد من التوازن، لكنها لا تفترض أن إدخال الذكاء الاصطناعي سيجعل البرمجيات أكثر أمانًا تلقائيًا أو بلا تكلفة.
#المشكلة ليست في الترقيع وحده
إرسال ترقيعات بوتيرة أعلى يحل مشكلة آنية، لكنه لا يمنع ظهور فئات كاملة من الثغرات مستقبلًا.
ولهذا يركز فريق Chrome أيضًا على تغييرات هيكلية في تصميم المتصفح، من بينها إعادة كتابة أجزاء من كود C++ باستخدام Rust.
لغة Rust مصممة بخصائص تجعلها أكثر أمانًا من ناحية إدارة الذاكرة، وهو ما يساعد على تقليل فئات من العيوب المرتبطة بأخطاء الذاكرة.
من منظور هندسي، الفارق كبير بين إصلاح Bug بعد العثور عليه وبين تغيير بنية البرنامج بحيث يصبح نوع كامل من الأخطاء أقل احتمالًا للظهور أصلًا.
ولهذا فإن استراتيجية Chrome تبدو وكأنها تعمل على مسارين متوازيين:
- زيادة سرعة اكتشاف الثغرات وإصلاحها.
- تقليل المساحة التي يمكن لبعض فئات الثغرات أن تظهر داخلها مستقبلًا.
#ماذا يعني هذا لأمن البرمجيات؟
القصة لا تتعلق بعدد تحديثات Chrome فقط، بل بتغير العلاقة بين اكتشاف الثغرات ودورة تطوير البرمجيات.
عندما تصبح أدوات AI قادرة على استيعاب تاريخ كامل لمشروع ضخم، ومعرفة الثغرات السابقة، وربط تغييرات الكود بأسبابها، فإن فرق الأمن تحصل على قدرة تحليلية لم تكن عملية بنفس الحجم سابقًا.
لكن هذه القدرة تنتج أثرًا تشغيليًا مباشرًا: مزيد من الثغرات المكتشفة يعني مزيدًا من أعمال التحقق، والتصنيف، والإصلاح، والاختبار، والإصدار.
لذلك فإن تسريع جدول التحديثات ليس مجرد قرار إداري، بل استجابة لزيادة معدل اكتشاف المشكلات نفسها.
#الإصلاح والتحديث
المصدر لا يتحدث عن ثغرة واحدة أو إصدار مصحح بعينه، بل عن تغيير أوسع في آلية إصدار تحديثات Chrome.
Chrome يتجه إلى:
- إصدار رئيسي كل أسبوعين.
- تحديثات أمنية إضافية أسبوعيًا.
- تجربة إصدار ترقيعات أمنية مرتين أسبوعيًا خلال الفترة الحالية.
لا يشير المصدر إلى أن الجدول الأخير سيصبح دائمًا، والفريق نفسه لا يجزم بذلك.
في Chrome، الذكاء الاصطناعي لا يغيّر فقط طريقة العثور على الثغرات؛ بل بدأ يفرض إيقاعًا جديدًا على هندسة البرمجيات نفسها. عندما يستطيع نموذج الرجوع إلى تاريخ المشروع، والثغرات السابقة، وأسباب تغييرات الكود، تصبح سرعة الاكتشاف أعلى من قدرة جداول التحديث التقليدية على الاستيعاب. التحدي التالي لن يكون فقط العثور على Bugs أكثر، بل إعادة تصميم البرمجيات بحيث يبقى عدد أقل منها قابلًا للوجود أصلًا.
