تظهر بيانات Android المحدّثة لعام 2025 أن ثغرات سلامة الذاكرة انخفضت إلى أقل من 20% من إجمالي الثغرات للمرة الأولى، بالتزامن مع توسع استخدام Rust في الأجزاء الجديدة والنشطة من المنصة. ووفق تحليل منشور على مدونة Google Security Blog في 12 نوفمبر 2025، لا يقتصر أثر الانتقال من C وC++ إلى Rust على تقليل المخاطر الأمنية، بل يمتد إلى تسريع مراجعة الشيفرة وتحسين استقرار التغييرات.
تستند البيانات إلى تغييرات في كود Android، سواء الذي تطوره Google مباشرة أو كود المصادر المفتوحة التابع لجهات خارجية، وتشمل لغات C وC++ وJava وKotlin وRust. وبما أن التحليل نُشر قبل نهاية عام 2025 ببضعة أشهر، أوضحت Google أن نافذة التصحيح القياسية البالغة 90 يوماً تجعل النتائج قريبة جداً من الأرقام النهائية، مع إمكانية تسريع التصحيح عند الضرورة.
أمان أعلى وتسليم أسرع
أدخلت Google Rust إلى Android بديلاً مباشراً لـ C وC++ في البرمجة منخفضة المستوى، مع الحفاظ على مستوى مماثل من التحكم وقابلية التنبؤ، لكن مع تقليل كثير من المخاطر المرتبطة بسلامة الذاكرة. ويشير التحليل إلى ارتفاع حاد في حجم شيفرة Rust الجديدة، بالتوازي مع تراجع أبطأ ومستمر في شيفرة C++ الجديدة، حتى أصبح حجم Rust المضاف حديثاً قريباً من حجم C++، ما أتاح إجراء مقارنات أكثر موثوقية بين مساري التطوير.
استخدمت Google إطار DORA لقياس جانبَي الإنتاجية والاستقرار. ولتقليل صعوبات المقارنة بين اللغات، ركزت على تغييرات متقاربة في الحجم، ومجموعات مطورين متشابهة من العاملين على منصة Android، كما تابعت الاتجاهات عبر الزمن مع ارتفاع اعتماد Rust.
تحتاج تغييرات Rust ذات الحجم المماثل إلى مراجعات أقل بنحو 20% من نظيراتها في C++. كما تقضي حالياً وقتاً أقل بنحو 25% في مراجعة الشيفرة. وتعزو Google، على سبيل التكهن لا الجزم، التحسن الملحوظ بين عامي 2023 و2024 إلى زيادة خبرة فريق Android بلغة Rust.
أما في جانب الاستقرار، فتسجل تغييرات Rust المتوسطة والكبيرة معدل تراجع أدنى بنحو أربعة أضعاف من تغييرات C++. وتؤكد Google أن انخفاض عمليات التراجع لا يعكس جودة التغييرات فحسب، بل يرفع الإنتاجية أيضاً، لأن التراجع قد يؤدي إلى إعادة العمل، ومراجعات إضافية، وإعادة بناء، وتقارير ما بعد الحوادث، وتعطيل فرق أخرى.
توسع Rust خارج خدمات النظام والمكتبات
تقول Google إن دعم Rust أصبح ناضجاً لبناء خدمات نظام Android ومكتباته، ولذلك تعمل على توسيع استخدامه إلى طبقات أخرى من المنظومة:
- النواة: تُعد نواة Linux 6.12 الخاصة بـ Android أول نواة لدى Google مفعّلاً فيها دعم Rust، كما تتضمن أول برنامج تشغيل Rust إنتاجي. وتواصل Google تعاونها مع Arm وCollabora على برنامج تشغيل لوحدة معالجة الرسومات يعمل في وضع النواة.
- البرامج الثابتة: ترى Google أن ارتفاع الصلاحيات وقيود الأداء ومحدودية بعض إجراءات الحماية تجعل البرامج الثابتة عالية المخاطر وصعبة التأمين. وتقول إنها تستخدم Rust في البرامج الثابتة منذ سنوات، وأتاحت دروساً تدريبية وشيفرة للمجتمع، مع تركيز خاص على تعاونها مع Arm ضمن Rusted Firmware-A.
- تطبيقات Google: يعمل بروتوكول Nearby Presence، المستخدم لاكتشاف الأجهزة المحلية عبر Bluetooth بصورة آمنة وخاصة، بلغة Rust داخل Google Play Services. كما سيُضمّن بروتوكول MLS الخاص بالرسائل الآمنة عبر RCS في تطبيق Google Messages ضمن إصدار مستقبلي.
- Chromium: استُبدلت محللات PNG وJSON وخطوط الويب بتنفيذات آمنة للذاكرة مكتوبة بـ Rust، بما يسهل على مهندسي Chromium التعامل مع البيانات القادمة من الويب مع اتباع Rule of 2.
ثغرة كادت تصل إلى المستخدمين
رغم التركيز على مزايا Rust، تستعرض Google حالة قريبة من تسجيل أول ثغرة سلامة ذاكرة مبنية على Rust في Android. فقد اكتُشف تجاوز خطي لسعة المخزن المؤقت في CrabbyAVIF قبل وصوله إلى إصدار عام، وحمل التصحيح المعرف CVE-2025-48530 لضمان إعطائه أولوية عالية وتتبع وصوله عبر قنوات الإصدارات.
أظهر التحليل أن مخصص الذاكرة Scudo Hardened Allocator جعل استغلال الثغرة غير ممكن بصورة حتمية، بفضل صفحات الحماية المحيطة بالتخصيصات الثانوية. كما حوّل Scudo التجاوز من تلف صامت للذاكرة إلى انهيار واضح، ما ساعد على اكتشاف المشكلة. في المقابل، كشفت الحادثة عن قصور في نظام الإبلاغ عن الأعطال، إذ لم يوضح بجلاء أن الانهيار ناتج عن تجاوز، وهو ما أبطأ الفرز والاستجابة. وتقول Google إن هذا القصور عولج وأصبح النظام يقدم إشارة واضحة عند حدوث تجاوزات إلى صفحات حماية Scudo.
لماذا يظل Rust مهماً رغم وجود unsafe؟
لا ترى Google أن حظر الشيفرة غير الآمنة، سواء في C أو C++ أو Rust، حل عملي لتطوير أنظمة التشغيل، بسبب الحاجة إلى التعامل مع واجهات الربط البرمجية والعتاد. لذلك تطور وحدة متقدمة حول الشيفرة غير الآمنة ضمن تدريب Comprehensive Rust، لتعليم المطورين كيفية تقييم سلامة هذه الشيفرة والسلوك غير المحدد، واستخدام تعليقات السلامة وتغليف الأجزاء غير الآمنة داخل تجريدات آمنة.
وبناءً على نحو خمسة ملايين سطر من Rust في منصة Android ووجود حالة محتملة واحدة عولجت قبل الإطلاق، تقدر Google كثافة ثغرات سلامة الذاكرة في Rust بنحو 0.2 ثغرة لكل مليون سطر. وتقارن ذلك بكثافة تاريخية تقارب 1,000 ثغرة لكل مليون سطر في C وC++، ما يعني انخفاضاً يتجاوز 1000 مرة وفق تقديرها. كما تشير إلى أن نحو 4% من الشيفرة مكتوب داخل كتل unsafe{}، لكنها تقول إن افتراض تعرض كل سطر غير آمن للمخاطر نفسها الموجودة في C أو C++ يبالغ في تقدير الخطر، نظراً لاستمرار معظم فحوص Rust، وإمكان تغليف الشيفرة غير الآمنة، وخضوعها لتدقيق إضافي.
تخلص Google إلى أن اعتماد Rust يغير المعادلة التقليدية التي ربطت تحسين الأمن بتكاليف إضافية في الأداء أو الإجراءات أو سرعة إطلاق الميزات. ومع استمرار أهمية C وC++ وآليات الحماية البرمجية والعتادية ضمن دفاع متعدد الطبقات، ترى الشركة أن الانتقال إلى Rust يوفر مساراً أكثر أماناً وكفاءة في الوقت نفسه، بدلاً من الإسراع أولاً ثم معالجة العواقب لاحقاً.
كيف أعددنا هذا الخبر؟
اعتمد الخبر على المصدر الأصلي الموضح أعلاه. قد نستخدم أدوات آلية للمساعدة في الاستخراج والتصنيف والصياغة،
لكن النشر يخضع لقواعد تمنع المحتوى المكرر والقصير أو الروتيني منخفض القيمة.
اقرأ سياستنا التحريرية.