Bjarne Stroustrup répond à la recommandation de la NSA et contredit la classification C++
Bjarne Stroustrup, le créateur du langage C++, a publié des objections aux conclusions du rapport de la NSA, qui recommandait aux organisations d'abandonner l'utilisation de langages de programmation tels que C et C++, qui laissent la gestion de la mémoire au développeur, au profit de langages tels que C#, Go, Java, Ruby, Rust et Swift qui assurent une gestion automatique de la mémoire ou effectuent des contrôles de sécurité de la mémoire au moment de la compilation.
Selon Stroustrup, les langages sécurisés mentionnés dans le rapport de la NSA ne sont pas réellement supérieurs au C++ dans les applications importantes, de son point de vue.
La NSA conseille aux organisations d'envisager d'apporter un changement stratégique aux langages de programmation qu'elles utilisent. fournir peu ou pas de protection mémoire inhérente, comme C/C++, à un langage sécurisé en mémoire
quand c'est possible
Plus particulièrement, les directives de base du C++ , élaborées ces dernières années, couvrent les méthodes de programmation sécurisée et préconisent l'utilisation d'outils garantissant la manipulation sûre des types et des ressources. Toutefois, les développeurs qui n'ont pas besoin de telles garanties de sécurité peuvent continuer à utiliser des méthodes de développement plus anciennes.
Stroustrup estime qu'un bon analyseur statique conforme aux directives de base du C++ peut fournir les garanties de sécurité nécessaires au code C++ à un coût bien inférieur à celui du passage à de nouveaux langages de programmation sécurisés.
Par exemple, la plupart des directives de base sont déjà implémentées dans Microsoft Visual Studio Static Analyzer et Memory Safe Profile. Certaines des recommandations sont également prises en compte dans l'analyseur statique Clang tidy.
Le rapport de la NSA a également été critiqué pour s'être concentré uniquement sur les problèmes de mémoire , laissant de côté de nombreux autres problèmes liés aux langages de programmation qui affectent la sécurité et la fiabilité.
Malheureusement, une grande partie de l'utilisation de C++ est également bloquée dans un passé lointain, ignorant les améliorations, y compris les moyens d'améliorer considérablement la sécurité. Maintenant, si je devais considérer l'un de ces langages "sûrs" supérieurs à C++ pour la gamme d'utilisations qui m'intéresse, je ne considérerais pas la disparition de C/C++ comme une mauvaise chose, mais ce n'est pas le cas .
Bjarne Stroustrup n'est pas d'accord avec le fait que la publication de la NSA limite la notion de protection des logiciels à celle de protection de la mémoire. En fait, cet aspect est un dénominateur commun à toutes les publications qui conseillent d'abandonner le C ou le C++ au profit du langage Rust pour les garanties de sécurité du logiciel que plusieurs grandes entreprises (Microsoft, Amazon, etc.) lui reconnaissent.
« Il n'y a pas de définition unique de la 'sécurité', et nous pouvons atteindre une variété de types de sécurité grâce à une combinaison de styles de programmation, de bibliothèques de support et d'analyse statique », dit-il. Bjarne Stroustrup suggère ainsi que ce que l'on peut obtenir du C++ en termes de sécurité logicielle dépend, entre autres, du développeur et, notamment, de la connaissance des outils que propose le langage, de sa maîtrise du compilateur, etc.
Stroustrup considère la sécurité comme un concept plus large, dont les différentes facettes peuvent être réalisées grâce à une combinaison de style de codage, de bibliothèques et d'analyseurs statiques. Pour contrôler l'inclusion de règles garantissant la sécurité du travail avec les types et les ressources, il est proposé d'utiliser des annotations de code et des options de compilateur.
Dans les applications où les performances sont plus importantes que la sécurité, cette approche permet une utilisation sélective d'outils qui assurent la sécurité uniquement là où elle est nécessaire. Des outils d'amélioration de la sécurité peuvent également être partiellement appliqués, comme limiter d'abord les règles de contrôle de plage et d'initialisation, puis adapter progressivement le code à des exigences plus strictes.
Enfin, si vous souhaitez en savoir plus sur la publication du créateur de C++, vous trouverez les détails en suivant ce lien.