Les données actualisées d’Android pour 2025 montrent que les vulnérabilités liées à la sécurité de la mémoire sont passées sous la barre des 20 % de l’ensemble des vulnérabilités pour la première fois, parallèlement à l’extension de l’utilisation de Rust dans les nouvelles parties actives de la plateforme. Selon une analyse publiée sur le blog Google Security Blog le 12 novembre 2025, l’abandon de C et C++ au profit de Rust ne réduit pas seulement les risques de sécurité : il accélère également la revue du code et améliore la stabilité des modifications.
Les données portent sur des modifications du code Android, qu’il soit développé directement par Google ou qu’il s’agisse de code open source provenant de tiers, et couvrent les langages C, C++, Java, Kotlin et Rust. Comme l’analyse a été publiée quelques mois avant la fin de l’année 2025, Google a précisé que la fenêtre standard de correction de 90 jours rendait les résultats très proches des chiffres définitifs, avec la possibilité d’accélérer la correction si nécessaire.
Une sécurité accrue et une livraison plus rapide
Google a introduit Rust dans Android comme solution de remplacement direct de C et C++ pour la programmation bas niveau, en conservant un niveau similaire de contrôle et de prévisibilité, mais en réduisant considérablement les risques liés à la sécurité de la mémoire. L’analyse indique une forte augmentation du volume de nouveau code Rust, parallèlement à un recul plus lent et continu du nouveau code C++, jusqu’à ce que le volume de Rust nouvellement ajouté soit proche de celui de C++, ce qui a permis des comparaisons plus fiables entre les deux parcours de développement.
Google a utilisé le cadre DORA pour mesurer les aspects de productivité et de stabilité. Afin de réduire les difficultés de comparaison entre les langages, elle s’est concentrée sur des modifications de taille similaire et sur des groupes de développeurs comparables travaillant sur la plateforme Android, tout en suivant les tendances au fil du temps à mesure que l’adoption de Rust augmentait.
Les modifications en Rust de taille comparable nécessitent environ 20 % de revues en moins que leurs équivalentes en C++. Elles passent également aujourd’hui environ 25 % moins de temps en revue de code. Google attribue, à titre de conjecture et non de certitude, l’amélioration notable observée entre 2023 et 2024 à l’expérience accrue de l’équipe Android avec le langage Rust.
Sur le plan de la stabilité, les modifications Rust de taille moyenne et grande affichent un taux de régression environ quatre fois inférieur à celui des modifications C++. Google souligne que la diminution des retours en arrière ne reflète pas seulement la qualité des modifications, mais accroît également la productivité, car un retour en arrière peut entraîner du travail supplémentaire, des revues additionnelles, des reconstructions, des rapports post-incident et la perturbation d’autres équipes.
L’expansion de Rust au-delà des services système et des bibliothèques
Google affirme que la prise en charge de Rust est désormais mature pour la création de services système et de bibliothèques Android. Elle travaille donc à étendre son utilisation à d’autres couches de l’écosystème :
- Noyau : le noyau Linux 6.12 d’Android est le premier noyau de Google à activer la prise en charge de Rust et comprend également le premier pilote Rust destiné à la production. Google poursuit sa collaboration avec Arm et Collabora sur un pilote de processeur graphique fonctionnant en mode noyau.
- Micrologiciels : Google estime que le niveau élevé de privilèges, les contraintes de performance et la disponibilité limitée de certaines mesures de protection rendent les micrologiciels très risqués et difficiles à sécuriser. Elle indique utiliser Rust dans les micrologiciels depuis des années et avoir mis à la disposition de la communauté des formations et du code, avec un accent particulier sur sa collaboration avec Arm dans le cadre de Rusted Firmware-A.
- Applications Google : le protocole Nearby Presence, utilisé pour détecter de manière sûre et privée les appareils locaux via Bluetooth, est écrit en Rust au sein de Google Play Services. Le protocole MLS destiné à la messagerie sécurisée via RCS sera également intégré à l’application Google Messages dans une prochaine version.
- Chromium : les analyseurs PNG et JSON ainsi que les polices web ont été remplacés par des implémentations écrites en Rust et sûres pour la mémoire, ce qui facilite la gestion par les ingénieurs de Chromium des données provenant du web tout en respectant la Rule of 2.
Une vulnérabilité qui a failli atteindre les utilisateurs
Malgré l’accent mis sur les avantages de Rust, Google présente un cas qui a failli constituer la première vulnérabilité Android liée à la sécurité de la mémoire et basée sur Rust. Un dépassement linéaire de la capacité du tampon a été découvert dans CrabbyAVIF avant son arrivée dans une version publique, et le correctif a reçu l’identifiant CVE-2025-48530 afin de lui donner une priorité élevée et de suivre sa diffusion par les canaux de publication.
L’analyse a montré que l’allocateur Scudo Hardened Allocator rendait l’exploitation de la vulnérabilité nécessairement impossible, grâce aux pages de protection entourant les allocations secondaires. Scudo a également transformé le dépassement, qui aurait autrement provoqué une corruption silencieuse de la mémoire, en plantage explicite, ce qui a contribué à détecter le problème. En revanche, l’incident a révélé une insuffisance du système de signalement des plantages : celui-ci n’indiquait pas clairement que le plantage résultait d’un dépassement, ce qui a ralenti le triage et la réponse. Google affirme que cette insuffisance a été corrigée et que le système fournit désormais un signal clair lorsqu’un dépassement atteint les pages de protection de Scudo.
Pourquoi Rust reste-t-il important malgré la présence de unsafe ?
Google ne considère pas l’interdiction du code non sûr, qu’il soit en C, C++ ou Rust, comme une solution pratique pour développer des systèmes d’exploitation, en raison de la nécessité d’interagir avec les interfaces de programmation et le matériel. Elle développe donc un module avancé consacré au code non sûr dans le cadre de la formation Comprehensive Rust, afin d’enseigner aux développeurs comment évaluer la sécurité de ce code et les comportements indéfinis, utiliser des commentaires de sécurité et encapsuler les parties non sûres dans des abstractions sûres.
Sur la base d’environ cinq millions de lignes de Rust dans la plateforme Android et de l’existence d’un seul cas potentiel traité avant le lancement, Google estime la densité des vulnérabilités liées à la sécurité de la mémoire en Rust à environ 0,2 vulnérabilité par million de lignes. Elle compare ce chiffre à une densité historique proche de 1 000 vulnérabilités par million de lignes en C et C++, ce qui représente, selon son estimation, une baisse de plus de 1 000 fois. Elle indique également qu’environ 4 % du code est écrit dans des blocs unsafe{}, mais précise que supposer que chaque ligne non sûre est exposée aux mêmes risques que celles en C ou C++ surestime le danger, compte tenu du maintien de la plupart des vérifications de Rust, de la possibilité d’encapsuler le code non sûr et de la soumission de celui-ci à un audit supplémentaire.
Google conclut que l’adoption de Rust modifie l’équation traditionnelle qui associait l’amélioration de la sécurité à des coûts supplémentaires en matière de performance, de procédures ou de vitesse de lancement des fonctionnalités. Alors que C et C++, ainsi que les mécanismes de protection logiciels et matériels, restent importants dans le cadre d’une défense en profondeur, l’entreprise estime que la transition vers Rust offre simultanément une voie plus sûre et plus efficace, au lieu d’accélérer d’abord le développement pour en traiter ensuite les conséquences.