Le plan de sécurité de la mémoire de Google inclut une rééducation pour les langages non sécurisés.

Google a révélé que son approche pour rendre le code de programmation plus sécuritaire en termes de mémoire implique à la fois l’adoption de langages sécuritaires pour la mémoire et la sécurisation des langages non sécuritaires, dans la mesure du possible. La Chocolate Factory a été un ardent défenseur de la sécurité de la mémoire au cours des dernières années – célébrant les avantages en termes de sécurité qui découlent de l’écriture ou de la réécriture du code dans un langage qui, comme Rust, offre des garanties de sécurité de la mémoire. Cependant, l’entreprise reconnaît également que le code hérité en C et C++ ne peut pas tous être révisé ou abandonné. Elle s’efforce donc de concilier son évangélisme quant à la sécurité de la mémoire avec la réalité selon laquelle les bases de code en C et C++ existeront pendant des décennies et qu’elles doivent être renforcées. Cette approche à deux volets est discutée depuis un certain temps, mais la partie sur l’apprentissage à vivre avec du code non sécuritaire est souvent étouffée par les odes appréciatifs adressées à Rust et à d’autres langages sécuritaires en termes de mémoire (MSLs) comme Java, Kotlin, Go, et Python. « Notre objectif à long terme est d’intégrer progressivement et de manière cohérente des langages sécuritaires pour la mémoire dans les bases de code de Google tout en éliminant progressivement le code non sécuritaire en mémoire dans les nouveaux développements, » ont expliqué les Googlers Alex Rebert, Chandler Carruth, Jen Engel, et Andy Qin dans un billet de blog. « Compte tenu de la quantité de code C++ que nous utilisons, nous prévoyons qu’une certaine quantité de code mature et stable, mais non sécuritaire en mémoire, subsistera pour un avenir prévisible. »