Discussion :

[Anthony]

La fondation Rust signale que 20 % des crates Rust utilisent le mot-clé "Unsafe", qui offre aux développeurs une certaine flexibilité dans les cas où les garanties du compilateur sont trop restrictives

La fondation Rust rapporte que près de 20 % des crates Rust utilisent le mot-clé « unsafe », ce qui met en évidence un aspect critique de la gestion de la mémoire dans la programmation Rust. Alors que Rust est réputé pour ses dispositifs de sécurité robustes, les blocs de code « unsafe » offrent aux développeurs une certaine flexibilité dans les situations où les garanties du compilateur sont trop restrictives. Malgré ces blocs, Rust maintient des protections strictes pour minimiser les vulnérabilités. La fondation Rust continue de mettre l'accent sur la sécurité, en développant des outils et des initiatives pour soutenir l'utilisation sécurisée de « unsafe » dans la programmation Rust.

Rust est un langage de programmation polyvalent multi-paradigme qui met l'accent sur les performances, la sécurité des types et la concurrence. Il assure la sécurité de la mémoire, c'est-à-dire que toutes les références pointent vers une mémoire valide, sans ramasse-miettes. Afin d'assurer simultanément la sécurité de la mémoire et d'éviter les courses aux données, son « vérificateur d'emprunts » suit la durée de vie de toutes les références d'un programme pendant la compilation.

Un billet de blog de la Fondation Rust commence par rappeler aux lecteurs que les programmes Rust « ne peuvent pas être compilés si les règles de gestion de la mémoire sont violées, ce qui élimine essentiellement la possibilité d'un problème de mémoire au moment de l'exécution ». Mais le billet poursuit en explorant « Unsafe Rust in the wild » (utilisé pour un petit ensemble d'actions telles que le déréférencement d'un pointeur brut, la modification d'une variable statique mutable ou l'appel à des fonctions non sûres).

« À première vue, il peut sembler que Unsafe Rust compromette les avantages de sécurité de la mémoire pour lesquels Rust est de plus en plus célébré. En réalité, le mot-clé unsafe est accompagné de garanties spéciales et peut être un moyen puissant de travailler avec moins de restrictions lorsqu'une fonction nécessite de la flexibilité, tant que les précautions standard sont utilisées. »

La Fondation énumère dans son billet les mesures de protection disponibles, qui « rendent les exploits rares, mais pas impossibles ». Mais elle analyse également la quantité de code Rust qui utilise réellement le mot-clé unsafe.

Le contenu du billet de blog de la Fondation Rust est présenté ci-dessous :

Les programmes accèdent à la mémoire - ce concept est fondamental en informatique. Selon le langage de programmation utilisé pour écrire le code, il existe différentes manières de gérer l'allocation et l'utilisation de cette mémoire. Chaque approche requiert prudence et précaution.

Un accès involontaire et hors de portée aux zones de mémoire d'un programme peut exposer des données sensibles ou servir de point d'entrée pour l'exploitation, ce qui représente un risque important et peut contribuer à des attaques de type « zero-day ». En résumé, qu'un programmeur gère et alloue la mémoire manuellement ou qu'il compte sur le langage et le compilateur pour le faire à sa place, des pratiques robustes de gestion de la mémoire sont une nécessité.

Les problèmes de sécurité de la mémoire représentent une part importante des vulnérabilités des logiciels. Les acteurs malveillants en sont bien conscients et utilisent un ensemble évolutif de tactiques pour exploiter le code non sécurisé en mémoire dans certaines des attaques logicielles les plus reconnaissables et les plus dommageables de ces dernières années, telles que Heartbleed.

Compte tenu du nombre d'exploits logiciels nuisibles qui hantent notre industrie et de l'importance des enjeux, les fondations de logiciels, les consortiums technologiques et les gouvernements du monde entier prennent conscience de la situation et plaident en faveur de l'amélioration des pratiques et des outils de programmation.

La puissance et la promesse de Rust

Le langage de programmation Rust est souvent cité par les défenseurs de la sécurité de la mémoire comme l'un des langages de programmation les plus sûrs sur le marché aujourd'hui. Langage à mémoire sécurisée par défaut grâce à un concept appelé ownership, Rust fournit des règles et des garanties pour la gestion de la mémoire et considère la sécurité comme un concept de premier ordre.

Les programmes utilisant Rust ne peuvent pas être compilés si les règles de gestion de la mémoire sont violées, ce qui élimine essentiellement la possibilité d'un problème de mémoire au moment de l'exécution. Les développeurs Rust et les utilisateurs d'applications écrites en Rust ont ainsi la certitude que les vulnérabilités de la mémoire ne doivent pas être un sujet de préoccupation.

Safe Rust et « Unsafe Rust »

Bien que Rust soit un outil puissant pour la sûreté de la mémoire et la sécurité, la puissance de ses contrôles de sécurité peut devenir limitante lorsque le programme ne peut pas réellement se tromper mais que le compilateur est incapable de le garantir lui-même ; le programmeur peut prouver l'impossibilité d'un comportement indéfini par des moyens qui ne sont pas à la disposition du compilateur. Dans ces cas, les programmeurs Rust utiliseront le mot-clé unsafe pour indiquer une fonction ou un segment de code ayant a) des considérations de sécurité supplémentaires ou b) des invariants qu'un programmeur doit suivre manuellement pour garantir la sécurité et qui ne sont pas nécessairement exprimés par Rust ou la fonction elle-même. Le mot-clé unsafe permet aux développeurs de déréférencer un pointeur brut, de modifier une variable statique mutable et, surtout, d'appeler des fonctions unsafe.

Bien que l'utilisation de Unsafe Rust puisse théoriquement produire des vulnérabilités similaires à celles des langages non sûrs pour la mémoire, il existe quatre mesures de protection principales pour réduire ces risques à près de zéro :

1. L'utilisation du mot-clé unsafe en Rust est un acte explicite, exigeant du développeur qu'il choisisse de le faire. Cela signifie que vous ne pourrez jamais entrer dans un contexte unsafe au sein de votre code Rust sans faire l'effort conscient de le faire ; d'autres langages peuvent vous permettre d'appeler directement du code unsafe ou non géré.
2. Le code unsafe doit être isolé dans ses propres blocs de code. Si un problème survient lors de l'utilisation de Unsafe Rust, le code à l'origine du problème est clairement identifié.
3. Il y a un nombre limité de façons d'utiliser unsafe et tout le code safe Rust continue à avoir ses contrôles de sécurité normaux même à l'intérieur d'un bloc unsafe.
4. Le système de types de Rust fournit toujours des contraintes de sécurité pour les types sûrs de Rust, même à l'intérieur d'un bloc unsafe.

Ces mesures supplémentaires renforçant Unsafe Rust rendent les exploits rares, mais pas impossibles. Pour déterminer le risque posé par Unsafe Rust, il faut examiner combien de code Rust utilise le mot-clé unsafe.

Unsafe Rust en milieu naturel

La façon canonique de distribuer du code Rust est par le biais d'un paquetage appelé crate. En mai 2024, il existe environ 145 000 crates, dont environ 127 000 contiennent du code significatif. Sur ces 127 000 crates, 24 362 font usage du mot-clé unsafe, soit 19,11 % de tous les crates. Et 34,35 % font un appel direct à une fonction dans une autre crate qui utilise le mot-clé unsafe. Près de 20 % de tous les crates ont au moins une instance du mot-clé unsafe, ce qui n'est pas négligeable.

La plupart de ces utilisations Unsafe Rust sont des appels à du code ou à des bibliothèques de langages tiers non Rust, tels que C ou C++. En fait, la crate qui utilise le plus le mot-clé unsafe est la crate Windows, qui permet aux développeurs Rust de faire appel à diverses API Windows. Cela ne signifie pas que le code de ces blocs Unsafe Rust est exploitable en soi (la majorité ou la totalité de ce code ne l'est probablement pas), mais qu'une attention particulière doit être portée à l'utilisation de Unsafe Rust afin d'éviter les vulnérabilités potentielles.

À première vue, il peut sembler que Unsafe Rust réduit les avantages de sécurité de la mémoire pour lesquels Rust est de plus en plus célébré. En réalité, le mot-clé unsafe est assorti de garanties spéciales et peut être un moyen puissant de travailler avec moins de restrictions lorsqu'une fonction nécessite de la flexibilité, tant que les précautions standard sont utilisées.

Sûreté et sécurité : une responsabilité partagée

Comme cela a été dit, Rust est à la hauteur de sa réputation d'outil excellent et transformateur pour une programmation sûre et sécurisée, même dans un contexte Unsafe. Mais cette réputation nécessite des ressources, une collaboration et un examen constant pour être maintenue correctement. Par exemple, le projet Rust continue de développer des outils comme Miri pour permettre la vérification du code Rust non sécurisé. La Rust Foundation s'est engagée dans ce travail par le biais de son initiative de sécurité : un programme visant à soutenir et à faire progresser l'état de la sécurité au sein de l'écosystème et de la communauté du langage de programmation Rust. Dans le cadre de l'initiative de sécurité, l'équipe technologique de la Fondation Rust a développé de nouveaux outils tels que Painter, TypoMania et Sandpit pour détecter les vulnérabilités dans le code Rust, donnant aux utilisateurs un aperçu des vulnérabilités avant qu'elles ne se produisent et permettant une réponse rapide en cas d'exploitation.

La sûreté est une responsabilité partagée - ce concept est fondamental pour des communautés saines. Entre les développeurs qui utilisent Unsafe Rust, les groupes qui préconisent l'utilisation d'outils d'amélioration de la sécurité comme Rust, et les responsables du langage comme la Fondation Rust, nous avons tous un rôle à jouer dans les pratiques de programmation sécurisée. La collaboration et l'attention constante portée à la sécurité permettront au langage de rester aussi résistant que possible aux vulnérabilités à l'avenir.

Source : "Unsafe Rust in the Wild: Notes on the Current State of Unsafe Rust" (Fondation Rust)

Et vous ?

Quel est votre avis sur le sujet ?

Voir aussi :

Comment Rust améliore la sécurité de son écosystème : la Rust Foundation publie un rapport sur ce que leur initiative de sécurité a accompli au cours des six derniers mois de 2023

Consumer Reports publie un rapport détaillé encourageant l'adoption généralisée de langages sûrs pour la mémoire tels que Rust, et sensibilise sur les risques liés à la sécurité de la mémoire

[Uther]

La plupart de ces utilisations Unsafe Rust sont des appels à du code ou à des bibliothèques de langages tiers non Rust, tels que C ou C++.

C'est dommage qu'il n'y ait pas de chiffre précis là dessus, car pour le coup ça fausse complètement la perception des autres chiffres.
C'est difficile de reprocher a Rust de ne pas assurer la sécurité du code écrit dans d'autre langages.

[Padget]

c'est pour ce mot clé que je considère que rust n'est pas plus sécurisé que le cpp. au final les gens qui font du code sécurisé en rust utilisent juste des sections unsafe bien faites (espérons le) de la std. en gros c'est pareil que les constructeurs/destructeurs en cpp

[Uther]

C'est différent de C++ dans le sens où la quantité de code à risque dont il faut particulièrement surveiller la validité de la mémoire est réduite à de petites sections clairement identifiées. En Rust, on ne peut pas introduire un risque d'insécurité mémoire sans s'en rendre compte.

Les problèmes de sécurité mémoire de C++ ne sont malheureusement pas limités aux constructeurs et même si c'était le cas, ça resterait une quantité de code exposée plus élevée que ce qu'il est normalement nécessaire de mettre en unsafe.

[RenarddeFeu]

Un programme ne peut pas être plus sécurisé que son maillon le plus faible. Il faudra un certain temps avant que Rust ne devienne hégémonique et qu'on puisse se passer totalement des briques tierces en C/C++/Fortran.

[Uther]

Oui le pirate visera toujours le maillon le plus faible, mais la sécurité ne fonctionne clairement pas en mode tout ou rien. En réduisant la quantité de code à risque, on diminue le risque de laisser une erreur exploitable.

Bien sur que Rust ne pourra jamais tout remplacer, et certainement pas du jour au lendemain. D'ailleurs même un code écrit 100% en Rust, sans aucun bloc unsafe ni composants externes, ne garantit pas une absence de failles de sécurité. Cependant, plus Rust permettra de diminuer la surface d'attaque, plus on gagnera en sécurité.

[Patrick Ruiz]

La communauté Rust reconnaît que le langage n’est pas sécurisé au travers d’une récente annonce
De lancement d’une initiative de vérification de 7500 fonctions non sûres de la bibliothèque standard Rust

Amazon Web Services va, dans un effort conjoint avec la Fondation Rust, payer des développeurs pour vérifier 7500 fonctions non sécurisées de la bibliothèque Rust. C’est ce qui ressort d’une récente annonce qui ravive le débat sur la question de savoir si le Rust, initialement présenté comme un meilleur gage de sécurité pour les logiciels que C et C++, est en réalité plus sécurisé.

Rust propose des moyens de contourner ses garanties de sécurité en utilisant le mot-clé "unsafe". La documentation précise à ce propos que « si Rust ne vous permettait pas d'effectuer des opérations non sécurisées, vous ne pourriez pas accomplir certaines tâches, comme interagir directement avec le système d'exploitation, bien qu'elle ajoute que vous utilisez cette possibilité à vos propres risques ». Les risques dont il est question comprennent le déréférencement de pointeurs nuls qui est une source courante de problèmes de sécurité.

C’est aussi ce que rapporte la fondation Rust lorsqu’elle souligne que 20 % des unités de compilation Rust s’appuient sur le mot-clé "unsafe" :

« Bien que Rust soit un outil puissant pour la sûreté de la mémoire et la sécurité, la puissance de ses contrôles de sécurité peut devenir limitante lorsque le programme ne peut pas réellement se tromper mais que le compilateur est incapable de le garantir lui-même ; le programmeur peut prouver l'impossibilité d'un comportement indéfini par des moyens qui ne sont pas à la disposition du compilateur. Dans ces cas, les programmeurs Rust utiliseront le mot-clé unsafe pour indiquer une fonction ou un segment de code ayant a) des considérations de sécurité supplémentaires ou b) des invariants qu'un programmeur doit suivre manuellement pour garantir la sécurité et qui ne sont pas nécessairement exprimés par Rust ou la fonction elle-même. Le mot-clé unsafe permet aux développeurs de déréférencer un pointeur brut, de modifier une variable statique mutable et, surtout, d'appeler des fonctions unsafe. »

La récente publication d’AWS va plus loin en soulignant que même si les développeurs n'utilisent que du code sûr, la plupart des applications dépendent toujours de la bibliothèque standard Rust dans laquelle on retrouve environ 7500 fonctions non sécurisées. Grosso modo, la publication d’Amazon suggère qu’une mauvaise utilisation de Rust peut conduire aux mêmes problèmes en matière de sécurisation de la mémoire des logiciels rencontrés avec des langages concurrents comme le C et le C++. En d’autres termes, la faille ultime se trouverait entre la chaise et le clavier et c’est le programmeur.

Verify the Safety of the Rust Standard Library https://t.co/d61FSp6EjR #rustlang #devops #programming

— Dinko Korunic (@dkorunic) November 22, 2024

Des initiatives comme Fil-C et Safe C++ ont vu le jour pour apporter une meilleure réponse aux problèmes de sécurisation de la mémoire des logiciels en C et 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++.

« Les langages de programmation C et C++ sont merveilleux. Il existe une tonne de codes écrits dans ces deux langages. Mais le C et le C++ sont des langages peu sûrs. De simples erreurs de logique peuvent amener un attaquant à contrôler la zone mémoire un pointeur et ce qui y est écrit, ce qui ouvre la voie à une exploitation facile. Beaucoup d'autres langages (Rust, Java, etc.) n'ont pas ce problème ! Mais j'aime le C. Et j'aime presque autant le C++. J'ai grandi avec eux. C'est une telle joie pour moi de d'utiliser les deux ! C'est pourquoi, pendant mon temps libre, j'ai décidé de créer mes propres langages C et C++ à mémoire sécurisée. Il s'agit d'un projet personnel et d'une expression de mon amour pour le C. Fil-C introduit la sécurité de la mémoire au cœur du C et du C++ », souligne Filip Pizlo de Epic Games à propos de Fil-C.

« Le projet vise une compatibilité à 100 % avec C et C++. Il suffit de compiler son code avec le compilateur pour obtenir du code sécurisé », d’après Pizlo. Ce dernier reconnaît néanmoins que « le principal obstacle à l'utilisation de Fil-C en production est la vitesse. Fil-C est actuellement environ 1,5 à 5 fois plus lent que le C traditionnel. »

Ces initiatives font surface dans un contexte de multiplications des appels au passage à des langages de programmation dits sécurisés et Rust s’impose au point d’être adopté pour lé développement du noyau Linux

Linus Torvalds lui-même est pourtant d’avis que le langage Rust est une solution d’avenir pour le développement du noyau. Il considère la prise en charge de Rust pour le développement du noyau Linux comme une « une étape importante vers la capacité d'écrire les pilotes dans un langage plus sûr. » Rust de Mozilla Research est le type de langage de programmation auquel ceux qui écrivent du code pour des systèmes d’entrée/sortie de base (BIOS), des chargeurs d’amorce, des systèmes d’exploitation, etc. portent un intérêt. D’avis d’observateurs avertis, c’est le futur de la programmation système en lieu et place du langage C. En effet, des experts sont d’avis qu’il offre de meilleures garanties de sécurisation des logiciels que le couple C/C++. Chez AWS on précise que choisir Rust pour ses projets de développement c’est ajouter l’efficacité énergétique et la performance d’exécution du C à l’atout sécurité.

En effet, il y a une liste de griefs qui reviennent à l’encontre du langage C : les problèmes liés à la gestion de la mémoire – dépassements de mémoire tampon, allocations non libérées, accès à des zones mémoire invalides ou libérées, etc. D’après les chiffres du dictionnaire Common Vulnerabilities and Exposure (CVE), 15,9 % des 2288 vulnérabilités qui ont affecté le noyau Linux en 20 ans sont liées à des dépassements de mémoire tampon.

De plus, certains benchmarks suggèrent que les applications Rust sont plus rapides que leurs équivalents en langage C. Et c’est justement pour ces atouts que sont la parité en termes de vitesse d’exécution en comparaison avec le C, mais surtout pour la sécurisation et la fiabilité que de plus en plus d’acteurs de la filière du développement informatique recommandent le Rust plutôt que le C ou le C++.

Ainsi, en adoptant Rust, la communauté autour du noyau Linux devrait mettre à profit ces atouts du langage sur le C. Et elle devrait faire d’une pierre deux coups étant donné que Rust peut faciliter l’arrivée de nouveaux contributeurs. C’est en tout cas ce que laisse entrevoir une étude de l’université de Waterloo.

Source : AWS

Et vous ?

Quel est votre expérience avec Rust en tant que langage de programmation et en particuluer avec les cas d'utilisation du mot-clé "unsafe" ? Les garanties de sécurisation de la mémoire qui sont attribuées à ce langage en comparaison au C et au C++ sont elles exagérées ?
Le potentiel problème avec Rust n’est-il pas le même qu’avec C et C++ : la qualité des programmeurs ?

Voir aussi :

Programmation : une étude révèle les langages les plus voraces en énergie, Perl, Python et Ruby en tête, C, Rust et C++, les langages les plus verts

Linus Torvalds souligne une bonne avancée du langage Rust dans le développement du noyau Linux, et aurait qualifié le C++ de « langage de m... », après le message de Google

Microsoft, Google, AWS, Huawei et Mozilla s'associent pour créer la Fondation Rust, une organisation à but non lucratif chargée de gérer le langage de programmation

Facebook rejoint AWS, Huawei, Google, Microsoft et Mozilla dans la Fondation Rust, et renforce son équipe Rust par des nouveaux talents

[denisys]

En d’autres termes, la faille ultime se trouverait entre la chaise et le clavier et c’est le programmeur.

Sans compter le porte monnaie du Manageur.
Hélas, hélas, hélas !!!!!

[prisme60]

Il n'y a pas photo. La sécurité du code Rust dépasse largement ce que l'on trouve en C et C++. Comme toute chose, il y a des marges d'amélioration, Rust reste un langage jeune, et il ne possède pas encore d'historique lourd à porter.

Le C est trop laxiste sur les appels de fonctions, gestion totalement manuelle des allocations dynamique sur le tas (malloc/free).

Le C++ a comblé quelques manques avec les différentes évolutions (regex, jthread, lambda, async/future, ranges/views), et au passage à rajouter une complexité supplémentaire (opérateur move, démultiplication des constructeurs, constraints/concepts, modules).

[d_d_v]

Je vois que tous les fanatiques pro-rust sont de sortie ici à ce que je vois. A chaque sortie ou mise en avant d'un "nouveau" langage, on a droit toujours aux mêmes promesses. J'ai vu la même chose avec DotNet, Java (qui a aussi son mode unsafe si je me souviens bien), pour d'autres promesses mais aussi celle de la gestion mémoire.
La première sécurité, c'est d'embaucher des gens compétents, c'est pareil dans tous les domaines. Vous n'avez pas besoin de fournir un couteau avec une lame en plastique à un pâtissier de peur qu'il se blesse, vous ne placez pas trois contremaîtres pour chaque garagiste de peur qu'il fasse n'importe quoi dans le moteur, etc.
Avec c++26, les contrats logiciels vont (enfin) arriver, c'est ça la vraie sécurité: pouvoir assurer les préconditions/postconditions de chaque fonction, c'est à dire, une partie de son contrat. Il y a trop de code dans tous les langages ou les "ingénieurs" mélangent les erreurs exceptionnelles, les erreurs réelles et les erreurs de programmation (contrat logiciel), avec des if x != null au début de chaque fonction (alors que c'est l'appelant qui doit s'assurer de vérifier les paramètres avant d'appeler la fonction). Mais bon, trop de "codeurs" ici et pas assez d'ingénieurs, je vais encore me prendre une volée de votes négatifs

[fdecode]

Je vois que tous les fanatiques pro-rust sont de sortie ici à ce que je vois.

Je pensais que cette discussion concernait Rust. Serions-nous par mégarde intervenus fanatiquement dans une discussion concernant C++26?

Avec c++26, les contrats logiciels vont (enfin) arriver, c'est ça la vraie sécurité: pouvoir assurer les préconditions/postconditions de chaque fonction, c'est à dire, une partie de son contrat.

Je suis preneur de références à ce sujet. Quelles fonctionnalités de c++26, plus précisément?

À vrai dire, mais on ne parle sans doute pas de la même chose, j'utilise beaucoup les conditionnements de type en Rust (s'assurer qu'un type implémente effectivement un certain nombre de traits et donc de fonctionnalités) pour contrôler l'utilisation de mes fonctions ou de mes librairies.

[Uther]

Je vois que tous les fanatiques pro-rust sont de sortie ici à ce que je vois.

La plupart des gens que vous appelez fanatiques pro-Rust ne prennent la peine de défendre le Rust que parce des gens (que l'ont pourrait tout autant qualifier de "fanatiques du C++") crachent dessus, généralement sans trop savoir de quoi il parlent. Je ne parle normalement pas de Rust dans les news qui ne parlent que de C++ si ce n'est pour rectifier quelqu'un qui dirait des erreur sur Rust.

A chaque sortie ou mise en avant d'un "nouveau" langage, on a droit toujours aux mêmes promesses. J'ai vu la même chose avec DotNet, Java (qui a aussi son mode unsafe si je me souviens bien), pour d'autres promesses mais aussi celle de la gestion mémoire.

Le unsafe en DotNet et Java n'est pas forcément comparable car ces langage n'ont pas la prétention d'être des langages systèmes. Je n'ai jamais eu besoin de me pencher sur le unsafe en C#, mais au moins, en ce qui concerne en Java, la notion de unsafe ne fait pas officiellement partie du langage. La plupart des JRE embarquent bien une classe Unsafe, mais elle ne fait pas partie de la bibliothèque standard et elle n'est pas officiellement supportée. En général quand on veut faire proprement en Java ce que l'on ferait avec du unsafe en Rust, on passe par des bibliothèque natives en C/C++/ou maintenant Rust.

La première sécurité, c'est d'embaucher des gens compétents, c'est pareil dans tous les domaines. Vous n'avez pas besoin de fournir un couteau avec une lame en plastique à un pâtissier de peur qu'il se blesse

Ces comparaisons sont simplistes notamment car elles impliquent que les problèmes de sécurité ont un impact immédiatement visible chez le producteur. Mais ce qui fait la particularité des failles de sécurité, c'est qu'elle ne sont pas forcément évidents à éviter et à identifier et elles auront un impact bien plus tard sur l'utilisateur du logiciel.
Pour reprendre la cas du pâtissier : il a bien fait son boulot s'il livre un bon gâteau. Il n'a pas a craindre que parce qu'il n'a pas tenu le couteau parfaitement à la verticale quand il a découpé les fraises, le gâteau devienne toxique quand on le mange la tête en bas un Mardi de pleine lune.

S'il suffisait d'avoir à disposition des développeurs chevronnés pour éviter les problèmes on aurait pas tant de failles, y compris dans les logiciels les plus surveillés au monde comme les navigateurs, OS, base de données ...

Il y a plusieurs décennies, j'ai souvenir d'un langage merveilleux, censé résoudre tous les soucis de sécurité... Java, on connait l'histoire depuis.

Java ne résout clairement pas tous les problèmes possible (Rust non plus d'ailleurs), mais c’était clairement une amélioration comparé au C et C++ au niveau de la sécurité, même si (contrairement au Rust) il implique des concessions sur l'accès au bas niveau et la maitrise des performances.

Ne jamais oublier que la première cause de défaillance de sécurité, se situe toujours entre la chaise et le clavier, croire qu'avec un langage, on va tout faire disparaître comme par magie, me fait beaucoup rire, surtout quand c'est des personnes gouvernantes qui disent cela en interview, ces mêmes personnes qui n'ont jamais écrit aucune ligne de code de leur vie.

On peut même aller au delà : le programmeur est la seule et unique cause des problèmes de sécurité. Le souci, c'est que quand on a dit ça, on a rien dit parce que malgré l'IA générative(qui est elle aussi faillible), on ne sait toujours pas faire de programmes un minimum complexe sans programmeurs.
Donc si on veut améliorer la sécurité, il faut améliorer le programmeur, et comme malgré toutes les formations et l'expérience accumulée, ça restera toujours un humain faillible, un compilateur qui permettent d’éviter les pratiques de codage problématiques, c'est un gros avantage. Et comme Rust ne résout pas directement les problèmes (comme Java ou C#) ou les ignore (comme parfois en C et C++), mais les explique, c'est également un très bon moyen de formation.

[fdecode]

La plupart des gens que vous appelez fanatiques pro-Rust ne prennent la peine de défendre le Rust que parce des gens que l'ont pourrait tout autant qualifier de "fanatiques du C++" crachent dessus, généralement sans trop savoir de quoi il parlent.
[...]
Java ne résout clairement pas tous les problèmes possible (Rust non plus d'ailleurs), mais c’était clairement une amélioration comparé au C et C++ au niveau de la sécurité, même si (contrairement au Rust) il implique des concessions sur l'accès au bas niveau et la maitrise des performances.

D'autant plus qu'une bonne part d'entre nous, j'en ai l'impression, a un parcours dans les langages de programmation et connaissent les langages plus anciens. Ce n'est pas un comportement de fanatique que de s'intéresser à ce qui est nouveau...
Et oui, je me souviens du progrès que java représentait par rapport à C++, dès lors que le JIT a permis une monté en performance raisonnable. Et ce n'était pas qu'une question de sécurité, mais aussi une certaine amélioration de la portabilité, des génériques que j'avais trouvées plus maîtrisables que les template du C++ d'alors. Par la suite ma préférence est allée à C# et Scala, puis à Rust. Ces langages ont apporté chacun leurs améliorations.

A chaque sortie ou mise en avant d'un "nouveau" langage, on a droit toujours aux mêmes promesses.

Il y a plusieurs décennies, j'ai souvenir d'un langage merveilleux, censé résoudre tous les soucis de sécurité.

Il n'y a pas de langage terminal qu'il suffira de maîtriser pépère jusqu'à la retraite. Ces nouveaux langages apportent des progrès mais ce ne seront pas les derniers. Quant au C++, la maîtrise des nouveaux paradigmes apportés par les nouveaux standards nécessite aussi une actualisation de ses connaissances.
Explorer les nouveautés ou pas, c'est au choix de chacun.

[remi_inconnu]

Il y a plusieurs décennies, j'ai souvenir d'un langage merveilleux, censé résoudre tous les soucis de sécurité... Java, on connait l'histoire depuis.
Rust ne m'a pas l'air fini et n'est pas évident à prendre en main, et quand on a baigné dans un univers orienté objet, il ne donne pas vraiment envie de devoir s'en passer.
A notre époque on est noyé par des nouveaux langages, tous plus merveilleux que les précédents, et souvent bien éphémère, je ne dis pas que pour Rust sera pareil, mais avant de miser tout sur ce langage, il faut bien réfléchir aux conséquences, et peut être il ne sera qu'une mode passagère, comme beaucoup d'autre avant lui et après lui.
Ne jamais oublier que la première cause de défaillance de sécurité, se situe toujours entre la chaise et le clavier, croire qu'avec un langage, on va tout faire disparaître comme par magie, me fait beaucoup rire, surtout quand c'est des personnes gouvernantes qui disent cela en interview, ces mêmes personnes qui n'ont jamais écrit aucune ligne de code de leur vie.