- Depuis l’adoption de Rust sur la plateforme Android, la part des vulnérabilités liées à la sécurité mémoire est tombée à moins de 20 % du total, améliorant à la fois la sécurité et l’efficacité du développement
- Par rapport à C/C++, le code Rust présente une densité de vulnérabilités de sécurité mémoire 1 000 fois plus faible, un taux de rollback 4 fois inférieur et un temps de revue de code réduit de 25 %
- L’extension de l’usage de Rust au noyau, au firmware et aux applications 1st-party contribue à relever le niveau de sécurité par défaut de l’ensemble du système
- Le cas du premier “quasi-incident” de vulnérabilité de sécurité mémoire en Rust, découvert dans CrabbyAVIF, a confirmé l’importance de l’allocateur Scudo et de la formation à l’écriture sûre de code unsafe
- La transition vers Rust est considérée comme un nouveau paradigme de développement logiciel permettant d’améliorer simultanément la sécurité et la vitesse de développement
Effets de l’adoption de Rust et données 2025
- En 2025, la part des vulnérabilités de sécurité mémoire sur Android est tombée sous les 20 %, ce qui confirme l’efficacité d’une stratégie de sécurité centrée sur Rust
- Par rapport à C/C++, Rust affiche une densité de vulnérabilités de sécurité mémoire divisée par 1 000, un taux de rollback 4 fois plus faible et un temps de revue de code réduit de 25 %
- L’adoption de Rust ne se limite pas à améliorer la sécurité : elle accélère aussi la livraison logicielle
- Les données couvrent les modifications de code 1st-party et 3rd-party sur la plateforme Android en C, C++, Java, Kotlin et Rust
Changement de langage système et productivité de développement
- Android a adopté Rust comme alternative à C/C++ pour la programmation système, avec un niveau de contrôle comparable mais moins de risques
- En code 1st-party, la croissance du code Rust a dépassé celle du C++, ce qui permet désormais de comparer les indicateurs de développement entre les deux langages
- Le framework DORA a été utilisé pour mesurer le Throughput et la Stability
- La comparaison a été réalisée en contrôlant la taille du code, le vivier de développeurs et les tendances temporelles entre Rust et C++
Throughput : une meilleure efficacité en revue de code
- Le code Rust nécessite 20 % de révisions en moins que le C++, et le temps de revue de code diminue de 25 %
- Entre 2023 et 2024, l’amélioration de l’expertise Rust a fortement accru l’efficacité des revues
- La réduction des revues et des retouches améliore la productivité, la hausse de la stabilité étant le principal facteur d’impact
Stability : moins de rollbacks et meilleure qualité
- Selon les critères DORA, le taux de rollback de Rust est environ 4 fois inférieur à celui du C++, en particulier sur les changements de taille moyenne à grande
- Un faible taux de rollback contribue directement à la productivité en réduisant les coûts annexes comme les reconstructions, les post-mortems et le blocage des équipes
- Une enquête menée en 2022 auprès des ingénieurs Google concluait déjà que Rust était plus facile à relire et plus précis
- Les données confirment empiriquement cette perception
Amélioration simultanée de la sécurité et de la productivité
- Par le passé, renforcer la sécurité entraînait souvent une baisse de performance ou des retards de développement, mais la transition vers Rust améliore à la fois la sécurité et l’efficacité
- L’adoption de Rust met en place une dynamique où sécurité, efficacité de développement et stabilité produit progressent ensemble
Domaines d’expansion de Rust
- Noyau : prise en charge de Rust dans le noyau Linux 6.12 d’Android et introduction du premier pilote Rust
- En coopération avec Arm et Collabora, le développement d’un pilote GPU basé sur Rust est en cours
- Firmware : l’adoption de Rust renforce la sécurité dans des environnements contraints et hautement privilégiés, avec publication de tutoriels, formations et code
- Le projet Rusted Firmware-A, mené avec Arm, est en cours
- Applications 1st-party :
- Nearby Presence : protocole de découverte d’appareils basé sur Bluetooth, implémenté en Rust et exécuté dans Google Play Services
- MLS : protocole de sécurité pour la messagerie RCS, implémenté en Rust et prévu dans une future version de l’application Google Messages
- Chromium : remplacement des parseurs PNG, JSON et polices web par des versions Rust, ce qui facilite le respect de la Rule of 2
Premier “quasi-incident” de vulnérabilité de sécurité mémoire en Rust
- Dans CrabbyAVIF, une vulnérabilité de buffer overflow (CVE-2025-48530) a été découverte juste avant la livraison et corrigée avant toute publication
- Le Scudo hardened allocator a rendu la vulnérabilité non exploitable grâce à ses pages de garde
- Scudo est déjà utilisé par défaut sur Pixel et d’autres appareils, et son obligation chez les partenaires est en cours de déploiement
- L’amélioration du crash reporting a permis de mieux signaler la détection des dépassements
Renforcement de la gestion du code unsafe et de la formation
- Le développement d’OS nécessite inévitablement du code unsafe (C/C++ ou Rust unsafe)
- Google a ajouté un module avancé sur le code unsafe au cursus Comprehensive Rust
- Il traite de la soundness du code unsafe, du comportement indéfini, des annotations de sécurité et des techniques d’abstraction sûre
- Une meilleure compréhension de Rust unsafe conduit à une amélioration de la qualité du code sur Android et dans l’ensemble de l’écosystème open source
Comparaison de densité de vulnérabilités
- Environ 5 millions de lignes de code Rust sur Android pour 1 vulnérabilité potentielle détectée → densité de vulnérabilités Rust : 0,2/MLOC
- La moyenne historique du C/C++ est de 1 000/MLOC, soit une baisse de plus de 1 000 fois
- La baisse de la densité des vulnérabilités de sécurité mémoire renforce l’efficacité de l’architecture de sécurité globale
- Environ 4 % du code Rust contient des blocs
unsafe{}, mais les données montrent une probabilité de bug plus faible qu’en C/C++
- Cela s’explique notamment par le maintien des vérifications de sécurité, l’encapsulation et un examen supplémentaire
Conclusion
- Par le passé, garantir la sécurité imposait des réponses coûteuses comme l’analyse statique, le sandboxing et les correctifs
- La transition vers Rust constitue une nouvelle approche qui assure simultanément sécurité et efficacité
- On n’est plus dans une logique de « développer vite et corriger plus tard », mais dans une phase où l’on développe vite tout en corrigeant en même temps
- Plus la sécurité se renforce, plus les gains potentiels en performance et en productivité augmentent
Remerciements
- De nombreux contributeurs sont mentionnés pour l’analyse de CVE-2025-48530, l’amélioration de Scudo, le développement de la formation à Rust unsafe et le partage d’informations sur l’usage de Rust
- Des remerciements sont adressés à l’équipe Android Rust et à l’ensemble de l’organisation Android pour leurs efforts continus d’amélioration de la qualité
3 commentaires
Vive Rust !
Après avoir un peu touché au développement de firmware avec Embassy,
la stabilité du langage est appréciable, mais surtout... l’outillage est tellement bon que, par rapport à l’époque où j’utilisais du C/C++, la productivité est écrasante.
Commentaires sur Hacker News
Sur 5 millions de lignes de code Rust, une seule vulnérabilité de sûreté mémoire a été détectée
Autrement dit, Rust affiche un taux de 0,2 vulnérabilité par million de lignes
À l’inverse, le C/C++ tourne autour de 1 000 par million de lignes, l’écart est donc écrasant
Mais face à des données aussi claires, il est difficile de comprendre pourquoi elles sont encore ignorées
Je n’ai moi-même jamais utilisé Rust, mais j’ai bien l’intention de l’apprendre un jour
La sécurité compte, bien sûr, mais des déploiements sans rollback, c’est vraiment ce que veulent les développeurs
Rust donne ce sentiment de stabilité
Des innovations de ce niveau sont vraiment rares en informatique
En 2025, il n’y a presque plus de raison d’utiliser le C++ en dehors de la maintenance de bases de code existantes
Tout nouveau développement devrait passer à Rust
Les nouveaux projets démarrent avec des systèmes de test modernes et des objectifs clairs
Malgré cela, il est difficile de nier que Rust est un langage plus sain mentalement que le C++
Apprendre Rust a été vraiment douloureux, bien plus complexe que d’autres langages
Mais après s’être battu quelques fois avec le compilateur, on finit par avoir la quasi-certitude que si le code tourne, il y aura très peu de problèmes
Après Ruby, JS/TS et Python, passer à Rust donne l’impression que « si ça compile, c’est fait à 80–90 % »
Et en plus, c’est rapide
Le combat avec le compilateur est en réalité un processus de correction anticipée des bugs cachés
La manière de penser de Rust finit par s’imposer dans l’esprit
C’est une blague pour dire que c’est un langage qu’on oublie facilement et qu’on réapprend facilement
Pour Ruby, JS et Python, je suis d’accord, mais TS me semble un peu différent
Google ne prend toujours pas officiellement en charge Rust dans le userspace d’Android
Le NDK et Android Studio ne prennent encore en charge que le C/C++
Pour utiliser Rust, la communauté doit créer elle-même les outils
Il devient difficile de créer une application sans code côté JVM
.soen Rust et de l’intégrer au NDKL’ABI d’Android ne dépend pas du langage, tant qu’on respecte les règles
C’est un événement qui ressemble à une bombe ayant coulé le C++
Désormais, il devient difficile de se réfugier derrière des excuses comme « Rust a aussi de l’unsafe » ou « le C++ est sûr quand il est bien utilisé »
Écrire du code sûr est contraignant, mais une fois cette étape passée, on gagne en confiance même dans des environnements multithread
J’aimerais aussi développer des applications Android en Rust
Je suis simplement heureux qu’il existe davantage d’options pour créer des outils système sûrs
Les standards industriels restent encore centrés sur le C/C++, ce qui rend un remplacement total par Rust difficile
Un taux de rollback 4 fois supérieur, c’est frappant
La plupart des autres chiffres correspondaient déjà à ce qu’on imaginait, mais celui-ci est nouveau
Cela ne signifie pas tant que Rust est parfait, mais plutôt qu’il y a énormément de bugs dans le code existant
Le fait d’obtenir ce type de données sur une base de code de grande taille est impressionnant
Si l’on construisait dès le départ un système de tests d’acceptation au niveau des modules, on pourrait remplacer par des tests une partie des vérifications que Rust impose
On pourrait surveiller non seulement les fuites mémoire, mais aussi les régressions de performance
il est possible que cela reflète simplement la différence de risque liée à l’ancienneté du code
Un ami s’est retrouvé à la tête d’un projet de réécriture en Rust,
et il a plaisanté en disant que « ça lui garantissait trois ans de salaire »
Une stratégie humoristique du type réécriture → sûreté mémoire → salaire stable
Pendant que le compilateur Rust compile lentement, on peut lire tranquillement l’ancien code et travailler sans stress
Ces données ne contrôlent pas les variables de confusion
En général, le code réécrit est déjà bien compris, donc les revues vont plus vite et les rollbacks sont moins nombreux
À l’inverse, le code legacy complexe demande des revues plus longues et entraîne davantage de rollbacks
Si seuls les morceaux de code faciles avaient été réécrits, le taux de vulnérabilités de sûreté mémoire aurait été différent
En pratique, on a plutôt tendance à réécrire en Rust le code le plus problématique
Ce n’est pas une expérience parfaite, mais il est plus raisonnable d’y voir un effet réel
Il serait encore plus intéressant d’analyser l’ampleur des réécritures à partir du nombre de lignes supprimées
plus il devient au contraire facile à réécrire
Je crois aux avantages de Rust, mais j’y vois davantage un fort argument empirique qu’une preuve scientifique
Je me demande quel impact l’adoption de Rust aura à l’avenir sur les bugs non liés à la sûreté mémoire
J’utilise Rust pour le développement de jeux (pas Bevy)
Grâce à sa stabilité et à son débit de traitement, je n’ai aucune envie de revenir à un autre langage
Je serais curieux de connaître la combinaison de crates et l’architecture utilisée
Je fais aussi des jeux en amateur, et j’ai trouvé Bevy un peu excessif
J’ai le sentiment que Rust a désormais pleinement trouvé sa place même dans le code système critique
Ce n’est plus un uphill battle
« Réécris-le en Rust » n’est plus un mème, il y a désormais de vrais éléments concrets derrière
80 % des commentaires viennent encore de détracteurs de Rust
On y retrouve toujours les mêmes arguments : « le C++ est sûr s’il est bien utilisé », « Rust a aussi des bugs »
Ce sont des critiques mal informées, et maintenant elles inspirent moins le rire que la tristesse
Mais vouloir l’appliquer partout serait exagéré
Le modèle de propriété de Rust ralentit le développement, et le langage lui-même continue encore d’évoluer
Pour des services à forte latence réseau, Python ou Node peuvent être plus efficaces
Autrement dit, Rust est excellent, mais ce n’est pas la réponse à tous les problèmes