Google a adopté Rust pour des raisons de sécurité et a constaté une réduction de 1 000 fois des vulnérabilités liées à la sécurité de la mémoire

Comparé à C et C++

Google a adopté Rust pour des raisons de sécurité et a constaté une réduction de 1 000 fois des vulnérabilités liées à la sécurité de la mémoire, un taux de rollback 4 fois plus faible et une réduction de 25 % du temps consacré à la révision du code par rapport au C et au C++. Google a partagé comment une stratégie de sécurité mémoire axée sur la prévention des vulnérabilités ne se contente pas de corriger les problèmes, mais aide également à aller plus vite. Selon Google, les données de 2025 continuent de valider cette approche, les vulnérabilités liées à la sécurité mémoire passant pour la première fois sous la barre des 20 % du total des vulnérabilités.

Dans le monde de la programmation, les langages C et C++ ont longtemps dominé le développement de firmware. Cependant, Google a fait une déclaration audacieuse : remplacer ces langages par Rust serait non seulement possible, mais aussi relativement facile. Les ingénieurs d'Android avait notamment affirmé : "Vous verrez à quel point il est facile de renforcer la sécurité avec des remplacements Rust".

Rust est un langage de programmation polyvalent. Il est réputé pour l'importance qu'il accorde aux performances, à la sécurité des types, à la concurrence et à la sécurité de la mémoire. Rust est réputé pour garantir la sécurité de la mémoire (c'est-à-dire que toutes les références pointent vers une mémoire valide) sans collecteur de mémoire classique. À la place, les erreurs de sécurité de la mémoire et les conflits d'accès aux données sont évités grâce au « vérificateur d'emprunt », qui suit la durée de vie des objets référencés au moment de la compilation.

Mais en novembre 2024, Google a affirmé que la transition C++ vers Rust prendra plusieurs années. Pour garantir la sécurité de ces utilisateurs, Google a décidé d'appliquer également les principes de conception sécurisée à sa base de code C++ existante "chaque fois que cela est possible". Google avait alors partagé comment elle a déployé ses principes ainsi que l'impact qu'elle a constaté dans son code C++.

Récemment, un an après cette affirmation, Google partage comment une stratégie de sécurité mémoire axée sur la prévention des vulnérabilités ne se contente pas de corriger les problèmes, mais aide également à aller plus vite. Selon Google, les données de 2025 continuent de valider cette approche, les vulnérabilités liées à la sécurité mémoire passant pour la première fois sous la barre des 20 % du total des vulnérabilités, notamment dans Android.

Android est un système d'exploitation basé sur une version modifiée du noyau Linux et d'autres logiciels open source, conçu principalement pour les appareils mobiles à écran tactile tels que les smartphones et les tablettes. Android a été développé par un consortium de développeurs connu sous le nom d'Open Handset Alliance, mais sa version la plus largement utilisée est principalement développée par Google.


Google a adopté Rust pour sa sécurité et constate une réduction de 1 000 fois de la densité des vulnérabilités de sécurité de la mémoire par rapport au code C et C++ d'Android. Mais la plus grande surprise a été l'impact de Rust sur la livraison des logiciels. Avec un taux de rollback quatre fois plus faible et un temps de révision du code réduit de 25 %, la voie la plus sûre est désormais aussi la plus rapide.

Construire de meilleurs logiciels, plus rapidement

Le développement d'un système d'exploitation nécessite le contrôle de bas niveau et la prévisibilité des langages de programmation système tels que C, C++ et Rust. Si Java et Kotlin sont importants pour le développement de la plateforme Android, leur rôle est complémentaire à celui des langages système plutôt qu'interchangeable. Google a introduit Rust dans Android comme alternative directe à C et C++, offrant un niveau de contrôle similaire, mais sans la plupart de leurs risques. Ils ont concentré cette analyse sur le code nouveau et activement développé, car les données montrent que cette approche est efficace.

Lorsqu'on examine le développement dans les langages système (à l'exclusion de Java et Kotlin), deux tendances se dégagent : une forte augmentation de l'utilisation de Rust et un déclin plus lent mais constant du nouveau C++.


Le graphique montre que le volume de nouveau code Rust rivalise désormais avec celui de C++, ce qui permet de comparer de manière fiable les mesures du processus de développement logiciel. Pour mesurer cela, ils utilisent le cadre DORA, un programme de recherche mené depuis dix ans qui est devenu la norme industrielle pour évaluer les performances des équipes d'ingénierie logicielle. Les mesures DORA se concentrent sur :

- Débit : la vitesse de livraison des modifications logicielles.
- Stabilité : la qualité de ces modifications.

Les comparaisons entre langages peuvent être difficiles. Ils ont utilisé plusieurs techniques pour garantir la fiabilité des comparaisons.

- Changements de taille similaire : Rust et C++ ont une densité fonctionnelle similaire, bien que Rust soit légèrement plus dense. Cette différence favorise C++, mais la comparaison reste valable. Ils utilisent les définitions de taille de changement de Gerrit.

- Pools de développeurs similaires : l'équipe de Google ne prend en compte que les changements effectués par les développeurs de la plateforme Android. La plupart sont des ingénieurs logiciels chez Google, et il existe un chevauchement considérable entre les pools, beaucoup contribuant aux deux.

-Suivi des tendances au fil du temps : à mesure que l'adoption de Rust augmente, les indicateurs changent-ils de manière régulière, s'accélèrent-ils ou reviennent-ils à la moyenne ?

Débit

La révision du code est une partie du processus de développement qui prend beaucoup de temps et qui présente un temps de latence élevé. La refonte du code est l'une des principales sources de ces retards coûteux. Les données montrent que le code Rust nécessite moins de révisions. Cette tendance est constante depuis 2023. Les modifications Rust d'une taille similaire nécessitent environ 20 % de révisions en moins que leurs équivalents C++.


De plus, les modifications Rust prennent actuellement environ 25 % moins de temps en révision de code que celles en C++. Selon Google, le changement significatif en faveur de Rust entre 2023 et 2024 est dû à l'expertise accrue de l'équipe Android en matière de Rust.


Si la réduction des retouches et l'accélération de la révision du code offrent des gains de productivité modestes, les améliorations les plus significatives concernent la stabilité et la qualité des modifications.

Stabilité

Rust se distingue par des modifications stables et de haute qualité. DORA utilise le taux de rollback pour évaluer la stabilité des modifications. Le taux de rollback de Rust est très faible et continue de diminuer, même si son adoption dans Android dépasse celle du C++.


Pour les modifications moyennes et importantes, le taux de rollback des modifications Rust dans Android est environ quatre fois inférieur à celui du C++. Ce faible taux de rollback n'est pas seulement un gage de stabilité, il améliore aussi activement le débit global du développement. Les retours en arrière perturbent fortement la productivité, créant des frictions organisationnelles et mobilisant des ressources bien au-delà du développeur qui a soumis la modification défectueuse. Les retours en arrière nécessitent des retouches et davantage de révisions de code, et peuvent également entraîner des remaniements, des analyses a posteriori et le blocage d'autres équipes. Les analyses a posteriori qui en résultent introduisent souvent de nouvelles mesures de sécurité qui alourdissent encore davantage la charge de développement.

Dans une enquête auto-déclarée réalisée en 2022, les ingénieurs logiciels de Google ont indiqué que Rust était à la fois plus facile à réviser et plus susceptible d'être correct. Les données concrètes sur les taux de rollback et les délais de révision confirment ces impressions.

Pour résumer

Historiquement, les améliorations en matière de sécurité avaient souvent un coût. Une sécurité accrue impliquait davantage de processus, des performances plus lentes ou des fonctionnalités retardées, ce qui obligeait à faire des compromis entre la sécurité et d'autres objectifs liés au produit. Le passage à Rust est différent : Google améliore la sécurité, l'efficacité du développement et les indicateurs de stabilité des produits.

Élargir le champ d'action

La prise en charge de Rust étant désormais mature pour la création de services et de bibliothèques système Android, Google se concentre sur l'extension de ses avantages en matière de sécurité et de productivité à d'autres domaines.

- Noyau : le noyau Linux 6.12 d'Android est notre premier noyau avec prise en charge de Rust et notre premier pilote Rust en production. D'autres projets passionnants sont en cours, tels que la collaboration continue de Google avec Arm et Collabora sur un pilote GPU en mode noyau basé sur Rust.

- Micrologiciel : la combinaison de privilèges élevés, de contraintes de performances et d'une applicabilité limitée de nombreuses mesures de sécurité rend le micrologiciel à la fois très risqué et difficile à sécuriser. Le passage du micrologiciel à Rust peut apporter une amélioration majeure en matière de sécurité. Google déploit Rust dans le micrologiciel depuis des années et avons même publié des tutoriels, des formations et du code pour la communauté au sens large. Google déclare être particulièrement enthousiastes à l'idée de sa collaboration avec Arm sur Rusted Firmware-A.

- Applications propriétaires : Rust garantit la sécurité de la mémoire dès le départ dans plusieurs applications Google critiques pour la sécurité, telles que :

° Présence à proximité : le protocole permettant de détecter de manière sécurisée et privée les appareils locaux via Bluetooth est implémenté dans Rust et fonctionne actuellement dans Google Play Services.

° MLS : le protocole pour la messagerie RCS sécurisée est implémenté dans Rust et sera inclus dans l'application Google Messages dans une prochaine version.

° Chromium : les analyseurs syntaxiques pour les formats PNG, JSON et les polices web ont été remplacés par des implémentations sécurisées en Rust, ce qui permet aux ingénieurs Chromium de traiter plus facilement les données provenant du web tout en respectant la règle de 2.

Ces exemples soulignent le rôle de Rust dans la réduction des risques de sécurité, mais les langages sécurisés en mémoire ne sont qu'une partie d'une stratégie globale de sécurité en mémoire. Google continue à employer une approche de défense en profondeur, dont la valeur a été clairement démontrée lors d'un récent incident évité de justesse.


Une première vulnérabilité de sécurité mémoire Rust... ou presque

Google rapporte avoir évité de livrer sa toute première vulnérabilité de sécurité mémoire basée sur Rust : un débordement de tampon linéaire dans CrabbyAVIF. Pour garantir que le correctif soit traité en priorité et suivi tout au long du processus de publication, Google lui a attribué l'identifiant CVE-2025-48530.

Voici les principales conclusions de l'analyse rétrospective de Google :

Allocateur renforcé Scudo pour la victoire

Une conclusion importante est que l'allocateur renforcé Scudo d'Android a rendu cette vulnérabilité inexploitable de manière déterministe grâce aux pages de garde entourant les allocations secondaires. Bien que Scudo soit l'allocateur par défaut d'Android, utilisé sur Google Pixel et de nombreux autres appareils, Google continue à travailler avec ses partenaires pour le rendre obligatoire. En attendant, Ils publieront des CVE d'une gravité suffisante pour les vulnérabilités qui pourraient être évitées par Scudo.

En plus de protéger contre les débordements, l'utilisation de pages de garde par Scudo a permis d'identifier ce problème en transformant un débordement de mémoire silencieux en un crash bruyant. Cependant, ils ont découvert une lacune dans le système de signalement des crashes : il ne montrait pas clairement que le crash était le résultat d'un débordement, ce qui ralentissait le triage et la réponse. Ce problème a été corrigé et Google dispose désormais d'un signal clair lorsque des débordements se produisent dans les pages de garde Scudo.

Révision et formation sur les codes non sécurisés

Le développement de systèmes d'exploitation nécessite des codes non sécurisés, généralement en C, C++ ou Rust non sécurisé (par exemple, pour FFI et l'interaction avec le matériel), il n'est donc pas envisageable de simplement interdire les codes non sécurisés. Lorsque les développeurs doivent utiliser des codes non sécurisés, ils doivent comprendre comment le faire de manière sûre et responsable.

À cette fin, ils ajoutent une nouvelle formation approfondie sur le code non sécurisé à notre formation complète sur Rust. Ce nouveau module, actuellement en cours de développement, vise à enseigner aux développeurs comment raisonner sur le code Rust non sécurisé, la sécurité et les comportements indéfinis, ainsi que les meilleures pratiques telles que les commentaires de sécurité et l'encapsulation du code non sécurisé dans des abstractions sécurisées.

Une meilleure compréhension du code Rust non sécurisé permettra d'obtenir un code de meilleure qualité et plus sécurisé dans l'écosystème des logiciels open source et au sein d'Android.

[B]Comparaison des densités de...