IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Vers un C++ plus sûr ? Avec les extensions Safe C++, la communauté veut répondre aux défis modernes de la sécurité des logiciels
Dans un contexte où plusieurs recommandent de le remplacer par des alternatives

Le , par Stéphane le calme

108PARTAGES

10  0 
Depuis plusieurs années, le langage de programmation C++ est critiqué pour ses failles de sécurité, notamment les erreurs de gestion de mémoire comme les débordements de tampon et les utilisations après libération. Face à ces défis, la communauté C++ a décidé de réagir avec une proposition : les extensions Safe C++.

Un besoin pressant de sécurité

La sécurité des logiciels est devenue une priorité pour les développeurs et les organisations du secteur public et privé. Des langages comme Rust, C#, et Go ont gagné en popularité grâce à leurs caractéristiques de sécurité mémoire intégrées. Cependant, le C++ reste un pilier dans le développement de systèmes performants et bas niveau. Pour répondre à cette demande croissante de sécurité, la communauté C++ a élaboré les extensions Safe C++.

Qu’est-ce que les extensions Safe C++ ?

Les extensions Safe C++ visent à introduire des fonctionnalités de sécurité mémoire dans le langage C++. Ces extensions incluent des mécanismes comme le vérificateur d’emprunt (borrow checker) pour prévenir les erreurs d’utilisation après libération et des analyses d’initialisation pour garantir la sécurité des types. Ces outils permettent aux développeurs d’écrire du code plus sûr sans sacrifier les performances et la flexibilité du C++.

Une collaboration significative

Le projet Safe C++ est le fruit d’une collaboration entre la C++ Alliance et des ingénieurs renommés comme Sean Baxter. Cette initiative marque une étape importante dans l’écosystème C++, en répondant aux critiques et en s’adaptant aux exigences de sécurité actuelles.

Vinnie Falco, président et directeur exécutif de l'Alliance C++, a déclaré :

« Je suis heureux d'annoncer que l'Alliance C++ a formé un partenariat avec Sean Baxter, un ingénieur de renom, pour développer la proposition Safe C++ Extensions.

« Il s'agit d'une proposition révolutionnaire qui ajoute des fonctionnalités de sécurité de la mémoire au langage de programmation C++.

« Cette collaboration marque une étape importante dans l'écosystème C++, car le besoin d'un code sûr n'a jamais été aussi pressant. Compte tenu de l'importance croissante de la sécurité et de la fiabilité des logiciels, les développeurs sont soumis à une pression de plus en plus forte pour adopter des pratiques de codage plus sûres. Les extensions Safe C++ visent à répondre à ce besoin critique en introduisant de nouvelles fonctionnalités qui empêchent les erreurs courantes liées à la mémoire.

« Nous sommes ravis de travailler avec Sean Baxter sur cette initiative cruciale. Les Safe C++ Extensions représentent une avancée majeure pour rendre le C++ plus sûr et plus efficace, tout en préservant les performances et la flexibilité du langage.

« La bibliothèque standard sécurisée est un élément clé de la proposition d'extensions C++ sécurisées. Cet ajout important à la bibliothèque fournira aux développeurs des implémentations robustes et sans danger pour la mémoire de structures de données et d'algorithmes essentiels. En intégrant ces composants dans la bibliothèque standard C++, nous pouvons nous assurer que le nouveau code est écrit en gardant à l'esprit la sécurité dès le départ.

« L'Alliance C++ et Sean Baxter sollicitent les réactions des développeurs, des chercheurs et des autres parties prenantes sur la proposition d'extensions C++ sûres. Ce processus de collaboration permettra d'affiner la portée du projet et de s'assurer qu'il répond aux besoins les plus urgents de l'écosystème C++ ».


S'assurer que le code est exempt de bogues liés à la sécurité de la mémoire

Cette collaboration arrive à point nommé car, depuis deux ans, les organisations des secteurs privé et public poussent les programmeurs à écrire de nouvelles applications et à réécrire les anciennes dans des langages à mémoire sûre tels que C#, Go, Java, Python et Swift, mais surtout Rust parce que c'est un langage de systèmes de bas niveau performant.

Après deux ans de coups de bâton sur la sécurité de la mémoire, la communauté C++ a publié une proposition visant à aider les développeurs à écrire un code moins vulnérable.

La proposition Safe C++ Extensions vise à résoudre le talon d'Achille du langage de programmation vulnérable, à savoir la difficulté de s'assurer que le code est exempt de bogues liés à la sécurité de la mémoire. « Il s'agit d'une proposition révolutionnaire qui ajoute des fonctions de sécurité de la mémoire au langage de programmation C++ », a déclaré jeudi Vinnie Falco, président et directeur exécutif de l'Alliance C++. « Cette collaboration marque une étape importante dans l'écosystème C++, car le besoin d'un code sûr n'a jamais été aussi pressant ».

L'ingénieur logiciel Alex Gaynor a soulevé la question en 2019, notant que la majorité des vulnérabilités graves dans les grandes bases de code proviennent de failles de sécurité de la mémoire telles que les débordements de mémoire tampon et l'utilisation après la libération. « Les données confirment, encore et encore, que lorsque les projets utilisent des langages peu sûrs pour la mémoire comme le C et le C++, ils sont accablés par une avalanche de vulnérabilités de sécurité qui en résultent », a-t-il écrit.

La sécurité de la mémoire est ensuite devenue un sujet de discussion courant dans les articles universitaires et les conférences techniques. En septembre 2022, Mark Russinovich, directeur technique de Microsoft Azure, a appelé à l'abandon de C et C++ et à l'adoption de Rust.

Quelques mois plus tard, la NSA a adopté une position similaire. En 2023, la sécurité de la mémoire est devenue un sujet courant, couvert par Consumer Reports.

Les personnes impliquées dans le C++ se sont mises sur la défensive

Il y a deux ans, en réponse à l'appel de M. Russinovich à se débarrasser de C/C++, le créateur de C++, Bjarne Stroustrup, a déclaré : « Nous pouvons désormais garantir une sécurité parfaite des types et de la mémoire dans ISO C++ ».

Cette déclaration a toutefois été accueillie avec un certain scepticisme. Josh Aas, cofondateur et directeur exécutif de l'Internet Security Research Group (ISRG), qui supervise une initiative de sécurité de la mémoire appelée Prossimo, a déclaré l'année dernière que s'il est théoriquement possible d'écrire du C++ sûr pour la mémoire, cela ne se produit pas dans le monde réel parce que le C++ n'a pas été conçu dès le départ pour la sécurité de la mémoire.

La proposition Safe C++ Extensions vise à répondre à cette critique et à satisfaire la demande du secteur public en matière de sécurité de la mémoire émanant de la NSA et des autres agences de renseignement « Five Eyes », de l'Agence américaine pour la cybersécurité et les infrastructures (CISA), de la Maison Blanche et de la DARPA.

En août, Gaynor est revenu sur le sujet de la sécurité des mémoires en soulignant que, s'il est logique d'essayer de rendre le C++ plus sûr, il doute de la mesure dans laquelle cela est possible.

« Il est clair, je pense, que des améliorations substantielles de la sécurité sont possibles pour le C++ », écrit-il. « En particulier, la résolution complète de la sécurité spatiale semble être à portée de main. Hélas, je pense qu'il est tout aussi clair que rendre le C++ aussi sûr que Swift, Go ou Rust n'est pas quelque chose que nous savons faire, et il ne semble pas probable que nous soyons capables de trouver une solution simple. »

Néanmoins, la proposition Safe C++ Extensions vise à essayer. Reconnaissant le chœur désormais assourdissant des appels à l'adoption de langages de programmation à mémoire sécurisée, les développeurs Sean Baxter, créateur du compilateur Circle, et Christian Mazakas, de l'Alliance C++, affirment que si Rust est le seul langage de programmation de niveau système populaire sans garbage collection qui offre une sécurité mémoire rigoureuse, la migration du code C++ vers Rust pose...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de NotABread
Membre actif https://www.developpez.com
Le 18/09/2024 à 10:57
Je trouve l'initiative intéressant surtout si on peut garder l'héritage du C++ et une compatibilité avec le C.

Après, peut-on encore dire qu'il s'agit de C++ ? Cela ajoute une syntaxe et des notions ne faisant pas partie de C++. De plus, si par défaut toute fonction C++ sont marquées unsafe à moins de spécifier le contraire, est-ce que l'on ne se retrouverait pas avec de grosse lourdeur à exposer l'existant au safe C++ ? Il faudrait que j'en lise plus sur ce projet
3  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 23/09/2025 à 5:26
Le problème c'est que plus un langage possèdes de fonctionnalités complexes, notamment celles qui affectent son API, plus c'est difficile d'être interopérable avec eux sans reprendre toute leur mécanique internes.
Le C++ est particulièrement problématique sur se point là, le D est le seul langage a ma connaissance qui s'interface directement avec, et encore, avec des limitations.
Au contraire le C avec son ABI standard et ses mécaniques simples est la référence de l'interopérabilité que quasiment tous les langages supportent.
3  0 
Avatar de freesket
Membre du Club https://www.developpez.com
Le 23/09/2025 à 9:25
Safe C++ de Sean Baxter est basée sur le modèle de Rust, ce qui implique en soit d'obtenir un code parfaitement sécurisé car il y a une séparation pure des méthodes "safe" et "unsafe". Et donc, pour passer à un mode "sécurisé" il faut refaire le code complètement...

Les profils sont plus basés sur l'implémentation directe dans le compilateur des outils d'analyses statique (basés eux-même sur le CppCoreGuidelines) déjà existants (contrairement à ce que dit Baxter d'ailleurs) que l'on trouve dans MSVC, Clang (et autres) et certains ajouts au runtime.
Note this good summary by David Chisnall (ancien de chez Microsoft Research, chercheur à l'University de Cambridge et architecte système chez SCI Semiconductor) in a January 2024 FreeBSD mailing list post:
"Between modern C++ with static analysers and Rust, there was a small safety delta. The recommendation [to prefer Rust for new projects] was primarily based on a human- factors decision: it’s far easier to prevent people from committing code that doesn’t compile than it is to prevent them from committing code that raises static analysis warnings. If a project isn’t doing pre-merge static analysis, it’s basically impossible."

Pour vous faire une idée des profils initiaux lisez le papier blanc P3081R2.
Le but du comité est de réduire drastiquement (mais pas complétement au début tout du moins) les plus gros problèmes de sécurités sans avoir à modifier (peu ou pas beaucoup) le code existant... Pour ce qui est du "type", "init", "bound" safety il y a beaucoup d'efforts de faits.

Reste le "lifetime safety" qui pour le coup n'est pas au niveau.
D'ailleurs Baxter le souligne bien et montre bien que ce "profil" n'est pas suffisant... Et il a raison. L'implémentation la plus avancée est celle fournie dans MSVC et elle n'est pas parfaite. D'ailleurs le "lifetime safety complet" (P1179R1) doit faire l'objet d'une TS pour avoir le retour des différentes implémentations.

Enfin le modèle de Baxter apporte, comme pour Rust, le "thread safety" qui... Pour le moment n'est pas traité par les profils.

Bref, les profils sont là pour une adoption rapide et une sécurisation (imparfaite mais significative) du code existant ou nouveau. J'espère que le comité va voter pour son adoption dans C++26 sans passer par une TS... Cela serait déjà un très bel ajout pour la sécurisation du code C++.
3  0 
Avatar de OuftiBoy
Membre éprouvé https://www.developpez.com
Le 23/09/2025 à 10:01


Citation Envoyé par Uther Voir le message
Le problème c'est que plus un langage possèdes de fonctionnalités complexes, notamment celles qui affectent son API, plus c'est difficile d'être interopérable avec eux sans reprendre toute leur mécanique internes.
C'est particulièrement vrai dans le cas du C++. On y a ajouté des "tonnes" de fonctionnalités, utilisées par une élite parfaitement informé de ces fonctionnalités. On a parfois l'impression que ce comité fait intégrer au C++ des "fonctionnalités" non pas parce qu'elles sont nécessaires, mais simplement parce qu'un des membre de ce comité a jugé "utile" cette fonctionnalité, inutile au plus grand nombres, mais satisfaisant l"égo de certains. Un langage devrait être "abordable" par un développeur "moyen", sinon il n'a pas de sens. On se retrouve dans la situation du "droit", où il faut un avocat (un spécialiste), rien que pour comprendre les méandres des lois et jurisprudence qui s'entassent depuis des décennies. Ce n'est pas normal, un citoyen "lambda" devrait pouvoir se défendre sans devoir avoir recours à un avocat...

Citation Envoyé par JPBruneau Voir le message
Le C++ est particulièrement problématique sur se point là, le D est le seul langage a ma connaissance qui s'interface directement avec, et encore, avec des limitations. Au contraire le C avec son ABI standard et ses mécaniques simples est la référence de l'interopérabilité que quasiment tous les langages supportent.
Il est souvent plus difficile de "s'interfacer" avec d'autres langages. Il faudrait pouvoir "reproduire" dans un langage, une librairie dont on veut ajouter les fonctionnalité. En bref, remplacer les "Wrapper" par des "Traducteurs". Un outils devrait pouvoir être "intégré" au nouveau langage, et si la librairie est correctement écrite, bien documentée (ainsi que les autres librairies qu'elle utilise elle-même). Si l'outil en question (le "Traducteur") ne sait pas faire son travail, soit on l'améliore, soit on refuse d'utilisé cette "librairie", car elle repose pas sur une définition suffisamment clair, et ne devrait même pas être utilisée par le langage dans laquelle elle a été écrite.

Ce n'est que mon avis, avec lequel je suis d'accord

BàV et Peace & Love.
2  0 
Avatar de OuftiBoy
Membre éprouvé https://www.developpez.com
Le 22/09/2025 à 21:19
Citation Envoyé par Mathis Lucas Voir le message
Le projet Safe C++, visant à doter le langage d'un modèle de sécurité inspiré de Rust, est mis de côté pour donner la priorité aux « Profils », une alternative controversée proposée par le créateur du langage.

Le comité du langage C++ travaille depuis plusieurs années sur des moyens d’améliorer la sécurité mémoire du langage, souvent critiqué pour ses vulnérabilités. En parallèle, Rust est devenu un modèle en matière de sûreté grâce à ses propriétés et son système de vérification stricte des accès mémoire. Le projet Safe C++ visait à créer un sous-ensemble du langage garantissant « une sécurité mémoire comparable à celle de Rust ». Mais la proposition vient d'être mise de côté, car elle n'est pas populaire auprès du comité. La priorité est donnée aux « Profils », un projet qui vise aussi à améliorer la sécurité du langage C++, mais sans s'inspirer du modèle de Rust.
Et si le problème de C++, c'était ce comité en lui-même. Il est certes composés de personnes ayant un talent exceptionnel, mais aussi un égo qui me semble surdimensionné. Ils sont de plus beaucoup trop nombreux que pour s'accorder. Un modèle de "gérance" à la "Python", où bien que s'appuyant sur des propositions venant d'autres personnes, le développeur initial du projet "tranche" pour une solution où une autre. Le problème avec un comité trop grand, c'est que chacun "pousse" son "avis", et des avis "différents" sont acceptés, même si le lien entre ces derniers n'est pas forcément fluide.

Cela étant dit, le modèle de Rust, bien que "satisfaisant" et "fait le taf", n'est pas la meilleur réponse. Le code Rust + ces mécanismes de protections mémoire, rendent (selon moi), la lisibilité du code "difficile". J'ai déjà expliqué pourquoi je pense cela auparavant ou dans une autre discussion. Je développe actuellement un langage et son compilateur, et la manière dont la "mémoire" est sécurisée est "naturelle". Je ne prétend pas que je ne devrais pas faire "marche arrière", mais pour le moment, ma solution est simple et "non-intrusive", car ma priorité numéro 1 reste la "lisibilité du code". Ni le langage, ni le compilateur ne sont terminés, mais plus j'avance, plus j'ai "confiance" en cette solution... L'avenir me contredira peut-être. Je reste très humble face à cette problématique. Et je n'ai pas la prétention que mon petit langage entre dans la "cours des grands", il restera "confidentiel" et aura (éventuellement) une audience réduite, car il fait partie d'un projet plus large, que je pourrais (ou pas) mener à son terme.

Citation Envoyé par Mathis Lucas Voir le message
Cela dit, les Profils sont également controversés, certains se plaignant, par exemple, que « les Profils ne ressemblent à aucune solution établie qui fonctionne, n'ont pas d'implémentation et n'ont pas été intégrés à la norme C++ 26 au début de l'année, le comité ayant préféré demander un autre livre blanc à ce sujet ». Sean Baxter ne pense pas que les Profils permettront d'atteindre cet objectif. « J'aurais mis en place des Profils s'ils avaient une chance de fonctionner », a-t-il déclaré. Il a ajouté que « toute la bibliothèque standard est dangereuse ». « J'ai proposé une std2 rigoureusement sécurisée, mais elle a été rejetée ». La controverse autour de la manière de rendre le C++ plus sûr pourrait signifier qu'il vaut mieux se tourner vers un autre langage, qu'il s'agisse de Rust ou d'un autre langage.
Oui, le C++ se tire une "nouvelle" balle dans le pied. A force, c'est normal qu'il perde pied...

Citation Envoyé par Mathis Lucas Voir le message
Les Profils semblent moins radicaux et plus faciles à adopter, un C++ plus sûr par défaut sans imposer le modèle Rust qui vise à s'attaquer aux pièges les plus courants du C++. La principale objection est évidente : on pourrait dire que les Profils imposent moins de restrictions que ce que Safe C++ visait à fournir.

Quel est votre avis sur le sujet ?
Perso, je pense que le C++ ne devra sa survie que grâce à sa base de code immense. Sa syntaxe est déjà devenue imbuvable (c'est mon avis), alors ajouter encore quoique ce soit ne le rendra pas plus "lisible". Pour la même raison, je pense que Rust prendra le même chemin, malheureusement.

Peut-être qu'une "troisième" voix s'imposera, qui sait...

BàV et Peace & Love.
3  2 
Avatar de RenarddeFeu
Membre averti https://www.developpez.com
Le 23/09/2025 à 2:03
Même remarque que sous l'article Rust. Au final les utilisateurs seront le juge de paix. Ils choisiront leur langage ainsi que les fonctionnalités qu'ils utilisent ou non.

À mon avis, un nouveau langage totalement interopérable avec le C++ sans passer par les appels en C, et avec une syntaxe similaire, me semble plus prometteur qu'un Safe C++ ou des Profils.
0  0 
Avatar de Axel Mattauch
Membre averti https://www.developpez.com
Le 25/09/2025 à 12:12
Je pense que Safe C++ était plus ambitieux : introduction d'une nouvelle syntaxe, de qualificatifs de type, de contextes sûrs ou non sûrs, etc. Certains membres du comité ont estimé que c'était trop lourd, et les Profils sont considérés comme une voie plus pragmatique.
.. stratégie consiste à définir différents Profils de garanties (sécurité, performance, contraintes de compilation) que les développeurs pourraient appliquer selon leurs besoins
J'ai proposé une std2 rigoureusement sécurisée, mais elle a été rejetée
Les Profils semblent moins radicaux et plus faciles à adopter, un C++ plus sûr par défaut sans imposer le modèle Rust qui vise à s'attaquer aux pièges les plus courants du C++.
Je code en C++ en amateur, et n'ai pas tâté du Rust. Je vais donner mon sentiment de non-expert.

La base de code existant en C++ et son age canonique sont à la fois la force et la faiblesse des C++. Le pluriel est volontaire: il y a plusieurs générations de C, plusieurs générations de C++, et la stratégie d'évolution était jusqu'à présent le changement dans la continuité pour paraphraser certains (anciens) politiciens. Ce qui est une gageure, alors que les évolutions sont radicales: le C canal historique était un langage gorgé d'astuces pour que le programmeur puisse manipuler directement et facilement à sa convenance des structures de données, les évolutions de ces langages et notamment du C++ poussent vers des abstractions, du code plus compact, l'amélioration de la sécurité (mémoire, threads..).

Cela paraît impossible, mais de fait C++ semble s'être dépêtré tant bien que mal de ces exigences antinomiques de modernisation et de compatibilité.

En tant que programmeur, les améliorations sont évidentes et mes questions fondamentales (ayant appris sur le tas et sur le tard) est de savoir ce dont je peux me passer, pour du nouveau code, des reliquats du C/C++ des origines. Et pas seulement les syntaxes deprecated.

De ce point de vue, les "conseils de programmation" peuvent être pertinents, utiles parfois, mais les avis divergent.

Il me semble que l'approche des profils, pour ce que j'en comprends, permettraient de systématiser certaines règles de codage et vérifier leur respect à la compilation. De même la refonte de code existant est susceptible de se faire à partir de l'existant en montrant où ça fait mal.

En somme, la philosophie de l'approche continue à ce modèle d'évolution, par réforme plutôt que par révolution.
Et contrairement à ce qui est allégué, il me semble que l'approche par profils est plus ambitieuse que celle consistant à créer de simples choix binaires code non sécurisé/code sécurisé.

Et si certaines technologies dérivant de Rust entre autres peuvent être utilisées ou adaptées à des profils particuliers de C++, alors c'est tant mieux. Mais ce n'est pas le débat.

Quant à la refonte de la STL avec profil sécurisé, c'est vraisemblablement une bonne idée.
0  0