La sécurité mémoire est désormais une question de sécurité nationale — pourquoi les États-Unis et l'UE veulent que les développeurs arrêtent d'écrire en C

En février 2024, l'Agence de cybersécurité et de sécurité des infrastructures des États-Unis (CISA) a publié un rapport de 19 pages intitulé « The Case for Memory Safe Roadmaps ». Le Bureau du directeur cybernétique national de la Maison Blanche a suivi avec un rapport technique exhortant les fabricants de logiciels à éliminer les vulnérabilités de sécurité mémoire. Le Centre national de cybersécurité du Royaume-Uni, le BSI allemand et la Direction des signaux australienne l'ont cosigné. Le message des cinq agences était identique : arrêtez d'écrire des logiciels critiques pour la sécurité en C et C++.

Ce n'est pas une position marginale parmi les universitaires qui préfèrent Haskell. C'est la politique de sécurité coordonnée des principales agences de renseignement et de cybersécurité du monde, soutenue par deux décennies de données de vulnérabilités, et elle commence à changer ce que les logiciels livrent réellement.

Ce que signifie la sécurité mémoire

La sécurité mémoire est la propriété qu'un programme ne peut pas lire ou écrire de la mémoire en dehors des limites prévues, accéder à de la mémoire libérée ou utiliser des valeurs non initialisées. Les langages imposent la sécurité mémoire soit par le garbage collection (Java, Python, Go), soit par des règles de propriété statique appliquées à la compilation (Rust). C et C++ ne fournissent ni l'un ni l'autre : le programmeur est responsable de la gestion correcte de la mémoire, et le compilateur ne vérifie pas la justesse.

La conséquence est une classe de bugs qui persiste depuis la création de C en 1972 : débordements de tampon, vulnérabilités use-after-free, déréférencements de pointeur nul, corruption de tas et confusion de types. Ce ne sont pas des cas marginaux exotiques — ils sont la classe de vulnérabilité la plus exploitée dans la nature, représentant constamment 60 à 70 % des CVEs critiques dans les grands projets logiciels.

Le Centre de réponse de sécurité de Microsoft a rapporté en 2019 qu'environ 70 % de tous les CVEs dans les produits Microsoft au cours des 12 années précédentes étaient des problèmes de sécurité mémoire. Le Project Zero de Google a rapporté en 2020 que 67 % des bugs de haute sévérité de Chrome étaient liés à la sécurité mémoire. Les deux chiffres sont restés obstinément constants jusqu'en 2026 malgré des investissements significatifs dans les outils (fuzzing, sanitizers, analyse statique) — parce que le problème sous-jacent est le modèle de langage lui-même, pas la qualité insuffisante des programmeurs qui l'utilisent.

L'échelle du problème hérité

La gravité de la situation actuelle est fonction de la quantité d'infrastructures critiques qui reposent sur du code C. Le noyau Linux — le fondement de la plupart des serveurs, des appareils Android, du matériel IoT et des systèmes embarqués — est composé d'environ 97 % de C. La bibliothèque OpenSSL qui sécurise la plupart du trafic HTTPS est en C. SQLite, la base de données la plus déployée au monde, est en C. Le moteur JavaScript V8 qui fait fonctionner la moitié de la navigation Web mondiale est en C++. Les noyaux Windows, macOS et iOS contiennent des dizaines de millions de lignes de C et C++.

Réécrire l'un d'eux n'est pas un projet de plusieurs mois. Le noyau Linux compte environ 30 millions de lignes de code, avec des contributeurs de milliers d'organisations et un processus de changement qui avance à une vitesse géologique par conception. La base de code de Google Chrome fait 40 millions de lignes. Demander « pourquoi ne pas simplement le réécrire en Rust ? » méconnaît l'échelle : à un rythme de réécriture d'un million de lignes par an par équipe, une réécriture complète de la base de code prend des décennies et introduit de nouveaux bugs à chaque étape.

L'approche pratique est le remplacement incrémental : réécrire d'abord les composants les plus risqués (analyse syntaxique, gestion des entrées réseau, cryptographie), utiliser l'interopérabilité des langages pour exécuter des modules Rust aux côtés de C, et accepter que le substrat C hérité existera pendant 20 à 30 ans tout en étant progressivement isolé.

La trajectoire de Rust

Rust, publié pour la première fois en 2015 par Mozilla, est le principal langage système à mémoire sécurisée adopté pour cette transition. Son système de types basé sur la propriété et l'emprunt empêche toute la classe des bugs de sécurité mémoire à la compilation, sans surcoût de garbage collection et avec des performances proches de C. Le compromis est une courbe d'apprentissage abrupte : le compilateur Rust rejette du code qu'un compilateur C accepterait, car le compilateur Rust prouve une correction que C laisse au programmeur.

La courbe d'adoption est maintenant suffisamment prononcée pour représenter un changement structurel. Google a réécrit des parties significatives des piles Bluetooth et WiFi d'Android en Rust ; l'équipe Android a rapporté en 2024 que le nouveau code dans des langages à mémoire sécurisée a fait chuter le taux de CVE de sécurité mémoire pour ces composants à presque zéro, tandis que les composants C hérités ont maintenu leur taux de vulnérabilité historique. Le noyau Linux a officiellement accepté Rust comme deuxième langage d'implémentation en 2022, et les premiers pilotes Rust ont été fusionnés dans le noyau principal.

L'équipe Windows de Microsoft réécrit des composants du noyau Windows en Rust, avec un objectif à long terme d'empêcher de nouveaux bugs de sécurité mémoire d'entrer dans la base de code du noyau. Les directives de la NSA de 2022 ont spécifiquement nommé Rust, Swift, Go, Kotlin et Java comme langages préférés pour les nouveaux développements dans des contextes de sécurité nationale. La loi sur la cyber-résilience de l'UE, entrée en vigueur en 2025, exige que les fabricants de produits avec des éléments numériques démontrent des pratiques « sécurisées par conception » — un langage juridique qui pénalise implicitement les langages non sécurisés en mémoire dans des contextes critiques de sécurité.

Ce que « memory safe » ne résout pas

La poussée politique en faveur des langages à mémoire sécurisée est bien documentée mais parfois survendue. La sécurité mémoire prévient une classe spécifique de bugs — mais elle ne prévient pas les erreurs logiques, les échecs d'authentification, les vulnérabilités d'injection ou les erreurs d'implémentation cryptographique. Un programme Rust peut avoir une vulnérabilité d'injection SQL aussi facilement qu'un programme C. Un programme Go peut avoir une erreur de logique métier permettant une escalade de privilèges. La sécurité mémoire est une condition nécessaire pour la sécurité, pas suffisante.

Il y a aussi une distinction significative entre Rust « safe » et « unsafe ». La bibliothèque standard de Rust contient des blocs unsafe — des sections où le programmeur désactive explicitement les vérifications de propriété pour du code critique en performances. Ces zones unsafe doivent être vérifiées manuellement, et des vulnérabilités y sont possibles. Par exemple, la condition de course CVE-2022-21658 dans la bibliothèque standard de Rust existait dans une implémentation std::fs soigneusement révisée. Rust rend le code unsafe rare et très visible, mais ne l'élimine pas.

L'argument de performance contre les langages à mémoire sécurisée a été largement résolu empiriquement. Dans la plupart des charges de travail, Rust se situe dans une fourchette de 5 à 15 % du code C équivalent, et dans certains benchmarks surpasse C parce que le compilateur peut effectuer des optimisations plus agressives lorsqu'il a prouvé des garanties d'aliasing et de durée de vie. La surcharge restante se produit principalement dans des cas pathologiques, pas dans le type de code système qui gère les paquets réseau, les opérations du système de fichiers ou l'analyse de protocoles.

Les dix prochaines années

La pression gouvernementale a des effets mesurables. L'initiative Secure by Design de la CISA, lancée en 2023, a recueilli les engagements de plus de 200 grands éditeurs de logiciels pour créer des feuilles de route de sécurité mémoire — des plans concrets pour migrer des bases de code spécifiques hors de C et C++ selon un calendrier publié. Les premiers rapports d'avancement annuels de ces éditeurs ont montré un mouvement modeste mais réel : nouveaux modules en Rust, APIs non sécurisées dépréciées, migration des composants d'analyse à haut risque.

Le calendrier réaliste pour réduire significativement les vulnérabilités de sécurité mémoire dans les infrastructures critiques est de 15 à 20 ans. Le code écrit aujourd'hui en Rust sera en production pendant des décennies ; le C hérité encore en cours d'exécution sera la source de vulnérabilités critiques pendant une période équivalente. La question politique n'est pas de savoir s'il faut faire cette transition – les preuves sont accablantes que C et C++ créent un risque de sécurité inacceptable à grande échelle – mais avec quelle agressivité pousser la vitesse de transition compte tenu des coûts techniques et des risques d'introduction de nouveaux défauts lors de la migration.

Ce qui a changé, c'est que c'est désormais une question politique, non académique. Quand la CISA qualifie quelque chose de problème de sécurité nationale et que la Maison Blanche signe un rapport technique, les exigences d'approvisionnement et les réglementations suivent. L'élan derrière l'adoption des langages à mémoire sécurisée n'est plus seulement motivé par la préférence des développeurs – il est codifié dans les contrats gouvernementaux, les règles de responsabilité des produits de l'UE et les exigences d'assurance. C et C++ resteront en usage pendant des décennies, mais leur position en tant que choix par défaut pour les nouveaux systèmes critiques de sécurité est terminée.