Les outils de sécurité natifs de Rust présentent des failles que les pirates connaissent déjà

Principaux enseignements

• Cargo Audit ne prend en compte que les avis déjà déposés par d'autres utilisateurs.
• Les scripts de compilation et les macros « proc » exécutent du code arbitraire au moment de la compilation, et la version stable de Cargo ne permet pas de désactiver cette fonctionnalité.
• Une caisse abandonnée n'a pas de date d'expiration ; par conséquent, rien n'expire et vous ne recevez un avertissement que si quelqu'un la signale.
• Lorsqu'une alerte est publiée sans version corrigée, c'est à vous qu'il revient de mettre en œuvre le correctif.

Une équipe Rust qui prend au sérieux la sécurité des dépendances commence presque toujours par la même démarche : installer Cargo Audit, l'intégrer à la chaîne d'intégration continue (CI), vérifier que tout se passe bien, et se sentir rassurée.

C'est une bonne initiative. Mais l'audit des cargaisons répond à une question plus précise que ne le pensent la plupart des équipes. On peut y lire : Cargo.lock et vous indique quelles bibliothèques font l'objet d'avis de sécurité. Cela ne revient pas à savoir si le code que vous vous apprêtez à compiler peut l'être en toute sécurité.

Les outils de Rust mettent l’accent sur ce à quoi la communauté du langage a donné la priorité : des builds reproductibles, des versions immuables, des fichiers de verrouillage avec somme de contrôle. Les lacunes ne sont pas le fruit de la négligence. Elles résultent du fait qu’une chaîne d’outils est conçue pour des dépendances « honnêtes » plutôt que « hostiles ».

Ce que l'audit de fret vérifie réellement

Trois choses, même si on lui en attribue davantage.

Il compare les paquets figurant dans votre fichier de gestion des paquets à la base de données des avis de sécurité de RustSec. Il signale les versions retirées. Et il met en avant les avis d'information, ce qui constitue une fonctionnalité que la plupart des gestionnaires de paquets négligent complètement.

cargo install cargo-audit --locked
cargo audit

RustSec classe ses conclusions par catégories, et les trois types de problèmes qui ne constituent pas des vulnérabilités revêtent une importance pratique plus grande que ne le pensent la plupart des équipes.

Aucune des catégories d’informations ne fait échouer l’exécution à elle seule ; ainsi, une tâche CI exécutant simplement un audit Cargo affiche un résultat « vert » alors même que des crates non maintenues se trouvent dans l’arborescence. C’est généralement exactement ce que les équipes pensent détecter.

cargo audit --deny warnings

Cela change la donne. Vous pouvez également exclure des catégories plus spécifiques, telles que « non maintenu », « défaillant » ou « supprimé », si vous souhaitez mettre en avant une catégorie de résultats sans inclure les autres. Attendez-vous à ce que la première analyse d'un projet abouti suscite beaucoup de réactions.

La balise « non maintenue » n'existe que si quelqu'un l'attribue. Une crate dont le responsable a discrètement cessé de publier des commits en 2023 sans jamais rien annoncer ne génère aucune alerte. Une exécution normale de « cargo audit » ne vous permet pas de savoir si vos dépendances sont encore prises en charge par quelqu'un.

Ce que couvre chaque outil de sécurité Rust

Les outils se distinguent selon deux critères qui priment sur le nombre de fonctionnalités : la nécessité ou non d'une vérification humaine du code, et la capacité ou non à interrompre une compilation.

Cargo Deny est l’outil le plus sous-utilisé par rapport à ce qu’il est réellement capable de faire. Il couvre les mêmes conseils de sécurité que Cargo Audit, ajoute des politiques relatives aux licences et aux interdictions, et vous permet de définir une liste blanche de sources afin qu’un crate provenant d’un registre que vous n’avez jamais approuvé ne puisse pas s’infiltrer discrètement. Les versions actuelles échouent au contrôle des avis de vulnérabilité et de notification ; par défaut, elles signalent un échec pour les crates non maintenues n’importe où dans l’arborescence, et échouent également face à des avis non valides dans vos dépendances directes, ce qui correspond au comportement souhaité par la plupart des équipes dès le départ.

« cargo auditable » résout un problème différent. Une fois qu’un binaire Rust est compilé, il est difficile de récupérer avec certitude la liste exacte de ses dépendances. La commande « cargo audit bin » permet de la reconstituer partiellement en analysant les messages de panique, et sa documentation est d’une franchise rafraîchissante quant à ses limites. Le code C intégré lui est invisible, et environ la moitié des dépendances Rust sont perdues, car le compilateur est très efficace pour supprimer les panics qui ne peuvent jamais se déclencher. L'intégration de la liste réelle au moment de la compilation résout ce problème, et cela ne vous coûte qu’un mot dans votre commande de compilation.

Exécuter cargo tree --duplicates en parallèle de l'audit que vous menez. La présence de plusieurs versions d'une même bibliothèque dans une même arborescence complique davantage la correction que cela n'y paraît, car la mise à jour d'un chemin de dépendance peut tout de même laisser une ancienne version intégrée à votre binaire.

Le premier écart réside dans le timing

Chaque outil figurant dans ce tableau fonctionne à partir d'un graphe de dépendances que Cargo a déjà résolu. Ils peuvent entraîner l'échec d'une compilation ou bloquer une mise en production. Ce qu'aucun d'entre eux ne fait, c'est d'empêcher dès le départ qu'un crate ne figure dans le graphe résolu.

Pour la plupart des problèmes liés aux dépendances, cela suffit. Une crate dont la vulnérabilité est connue reste vulnérable dix minutes plus tard, et la détecter lors de l'intégration continue (CI) est suffisamment précoce.

Pour le code malveillant, ce n’est pas le bon moment dans le cycle d’exécution, car Rust exécute le code non fiable lors de la compilation. Les scripts de compilation s’exécutent dans le cadre de cargo build. Les macros procédurales s'exécutent au sein du compilateur. Aucune des deux ne bénéficie d'un environnement isolé fourni par Cargo ; elles s'exécutent donc toutes deux avec les droits de l'utilisateur ayant lancé la compilation, ce qui leur permet d'accéder au système de fichiers, au réseau et à toutes les informations d'identification dont dispose l'environnement de compilation.

Stable Cargo ne dispose d'aucun indicateur permettant de désactiver l'un ou l'autre.

cargo vendor vendored/
find vendored/ -name build.rs | wc -l

Essayez ça sur un vrai projet. Un service de taille moyenne comportant quelques centaines de crates dans l’arborescence peut facilement générer des dizaines de scripts de compilation, et chacun d’entre eux, appartenant à une crate qui est effectivement compilée pour votre cible, s’exécute lors d’une compilation « propre ». Il y a fort à parier que personne dans l’équipe n’en ait lu un seul.

Ce n'est pas une hypothèse. En mai 2026, des chercheurs qui étudiaient le Campagne « TrapDoor » des caisses telles que sui-framework-helpers et move-compiler-tools destiné aux développeurs Sui et Move. Leur build.rs Les scripts recherchaient les fichiers de stockage de clés de portefeuille locaux dès qu'un projet était compilé, puis envoyaient ce qu'ils trouvaient vers GitHub Gists. Pas de hook d'installation, pas d'importation, juste cargo build il fonctionne exactement comme prévu.

Rust n'a rien de comparable à npm install --ignore-scripts. Vous pouvez consulter le code source d’une crate avant de la compiler, et vous devriez le faire pour tout élément sensible. Ce que la version stable de Cargo ne fait pas, c’est d’exécuter une compilation normale tout en ignorant les scripts de compilation des dépendances et les macros proc ; ainsi, la démarche « auditer, puis compiler » reste une opération manuelle plutôt qu’une option de ligne de commande.

La vérification d'une crate avant qu'elle ne parvienne à un développeur et sa compilation à partir d'un code source vérifié dans un environnement contrôlé font partie des rares contrôles qui interviennent avant l'exécution au moment de la compilation. C'est précisément ce problème de timing qui est au cœur de SecureChain pour Rust, plutôt que d'ajouter un passage supplémentaire sur un arbre déjà récupéré.

La deuxième lacune, c'est que personne n'applique de correctifs

RustSec recense les failles de sécurité. Il ne les corrige pas.

Cette distinction reste purement théorique jusqu'à ce que l'avis de sécurité qui se trouve devant vous ne dispose d'aucune version corrigée. À ce moment-là, le problème prend toute son ampleur, et les solutions possibles se réduisent rapidement.

Le volume ne cesse de croître lui aussi. RustSec recense 170 avis dont la date de publication est en 2025, et les avis datés de 2026 ont dépassé ce total dès le mois de mai, pour atteindre 257 à la mi-août. C’est la quatrième année consécutive que ce chiffre augmente, environ 160 des entrées de cette année étant classées comme vulnérabilités, le reste se répartissant entre des découvertes non prises en charge et des découvertes non valides. Ces chiffres continuent d’ailleurs d’augmenter a posteriori, puisque les avis relatifs à des divulgations plus anciennes continuent d’arriver des mois plus tard. C’est un signe de bonne santé pour le projet. Mais cela représente également une charge opérationnelle croissante pour quiconque exploite ces données, car davantage de découvertes concernant une arborescence que personne ne corrige en amont signifie simplement qu’il y a davantage de problèmes que l’on ne peut pas résoudre en augmentant simplement la version.

Rust continue également de satisfaire ses utilisateurs actuels. Les développeurs l’ont une nouvelle fois classé comme le langage le plus « admiré » dans l’enquête 2025 menée par Stack Overflow auprès des développeurs, avec 72 %, même si ce critère mesure davantage le nombre d’utilisateurs actuels souhaitant continuer à l’utiliser plutôt que la vitesse à laquelle son adoption progresse. Quoi qu’il en soit, de nombreuses entreprises utilisent désormais Rust en production sans qu’il existe de pratique établie sur la manière de gérer un crate faisant l’objet d’un avis de sécurité et pour lequel aucun correctif n’est disponible.

Lorsque la version corrigée n'existe pas, toutes les options sont peu pratiques. Vous pouvez créer un fork du crate, appliquer le correctif et le maintenir sous votre propre nom. Vous pouvez remplacer la dépendance, ce qui implique généralement de réécrire tout ce qui l'utilisait. Vous pouvez l'appliquer localement via [patch.crates-io] et en rester propriétaire indéfiniment. Vous pouvez documenter une mesure corrective et accepter le risque. Ou bien vous pouvez faire appel à quelqu’un dont le métier consiste justement à réintégrer les correctifs dans le code en amont qui ont été laissés de côté.

Le portage d'un correctif de sécurité vers une version dont le responsable a cessé de s'occuper relève d'une discipline différente de celle de la conception de nouvelles fonctionnalités. Cela nécessite des tests de régression, une validation de la compatibilité et un engagement délibéré à ne pas modifier le comportement, ce qui est à peu près le contraire de ce à quoi sert le développement en amont.

Le troisième écart concerne les caisses qui ne sont jamais officiellement retirées de la circulation

PHP publie les dates de fin de vie (EOL). Il en va de même pour Node, selon son propre calendrier. En revanche, une crate publiée par une seule personne en 2019 ne publie rien, car il n'y a jamais eu d'engagement de prise en charge devant prendre fin.

Le registre à l'adresse crates.io ce qui complique les choses d’une manière bien précise. Les versions publiées sont en effet immuables. La suppression n’est possible que dans un cadre très restreint, à savoir pour les crates qui n’ont pratiquement pas été téléchargées et dont aucun autre composant ne dépend ; c’est donc la suppression manuelle qui constitue le véritable levier. Cette immuabilité est un véritable atout en matière de sécurité par rapport aux registres qui autorisent les balises modifiables. Cela signifie également qu’une crate abandonnée reste installable, se résout normalement et ne laisse aucune trace dans Cargo.lock ce qui laisse penser que son responsable a abandonné le projet il y a trois ans.

Aucun outil ne regroupe les signaux qui vous permettraient de le savoir ; cette étape reste donc manuelle. Comparez la date de la dernière publication au nombre de tickets ouverts. Vérifiez si le dépôt GitHub est archivé, ce que Cargo ne mentionnera jamais. Comptez le nombre de propriétaires répertoriés sur la page crates.io, car un seul propriétaire correspond à un « facteur bus » égal à un. Et notez si la crate est une dépendance de compilation ou une macro proc, car celles-ci s’exécutent au moment de la compilation, quel que soit leur niveau de maintenance.

Exécuter cargo owner --list <crate> contre tout élément lié à la sécurité dans votre arborescence. Le fait qu’un seul propriétaire soit associé à un crate qui est compilé dans votre binaire de production constitue un risque lié à la chaîne d’approvisionnement que la simple mise en correspondance des avis de sécurité ne permettra pas de détecter.

Pour déterminer quels résultats sont réellement pertinents, il faut disposer de ce type de contexte : l’état de maintenance, l’existence ou non d’un correctif, la présence de la bibliothèque dans votre chemin de compilation ou uniquement dans les dépendances de développement. La correspondance des avis de sécurité ne fournit aucune de ces informations ; les équipes finissent donc par classer les problèmes en fonction de l’identifiant RUSTSEC plutôt qu’en fonction de l’exposition réelle.

Les avantages et les limites de « Cargo Vet »

Cargo Vet adopte une approche différente, et mérite d'être davantage adopté qu'il ne l'a été jusqu'à présent. Au lieu de faire correspondre les avis de sécurité, il applique des critères d'audit à l'ensemble de votre graphe de dépendances, en s'appuyant à la fois sur les audits réalisés par votre propre équipe et sur ceux que vous importez depuis des organisations qui publient les leurs.

cargo vet init
cargo vet suggest

Ce qu'il faut savoir avant de commencer : cargo vet init exclut délibérément tout ce qui se trouve déjà dans votre arborescence, afin que l’adoption ne fasse pas capoter l’intégration continue dès le premier jour. Le backlog apparaît via cargo vet suggest, et vous remplacez les dérogations par de véritables audits, au rythme que votre équipe est en mesure de soutenir. L'importation d'audits provenant de grandes organisations permet de résorber une partie non négligeable du retard accumulé sans que personne de votre équipe n'ait à examiner ce code lui-même.

Ces limites sont d’ordre structurel. La couverture dépend du fait qu’une version dont vous dépendez réellement ait été auditée, et une nouvelle version nécessite de nouvelles preuves, à moins qu’un audit importé ou une exemption ne la couvre déjà. Les audits « delta » permettent de gérer cela, puisque vous examinez généralement les différences par rapport à une version déjà validée plutôt que de repartir de zéro. Un audit humain relève également d’un jugement subjectif sur la qualité et l’intention du code, et non d’une garantie. Les réviseurs peuvent passer à côté de certaines choses, en particulier dans les scripts de compilation obscurcis.

La confiance déléguée reste préférable à l'absence totale de confiance. Elle présente simplement une courbe de couverture, et cette courbe est la plus étroite précisément là où se trouvent les crates nouvelles ou peu connues, c'est-à-dire là où les paquets malveillants ont tendance à se manifester.

Ce qu'il faut réellement exécuter en CI

Faites votre choix en fonction de l'état d'avancement de votre projet plutôt que d'installer tout d'un coup.

Comme rien n'est encore en place aujourd'hui, commencez par cargo deny check advisories sources. Il couvre les recommandations de RustSec, ajoute la liste blanche des sources en une seule étape et considère par défaut les catégories principales de recommandations comme des erreurs empêchant la compilation.

Si l'audit du fret est déjà en cours, ajoutez --deny warnings pour que les problèmes non corrigés et les bogues ne passent plus inaperçus, puis triez la liste obtenue en fonction de la présence ou non de la crate dans votre chemin de compilation.

Si vous expédiez des binaires à des clients ou vers des environnements réglementés, activez l'option « cargo auditable » afin que l'artefact que vous avez expédié comporte sa propre liste de dépendances. Reconstituer cette liste a posteriori est à la fois fastidieux et incomplet.

Si vos agents de compilation détiennent des identifiants de connexion au cloud ou des clés de signature, considérez l'exécution lors de la compilation comme le principal risque et réduisez la durée de validité de ces identifiants, car une fois qu'une compilation est lancée, les scripts de compilation des dépendances peuvent s'exécuter avant même que votre propre code ne soit exécuté.

Et si l'exécution à la compilation est inacceptable dans votre modèle de menace, Cargo ne peut à lui seul faire respecter cette limite. Le contrôle doit intervenir en amont de la résolution, lors du filtrage et de la recompilation des crates avant qu’elles n’atteignent la phase de construction, ou dans un environnement de construction isolé qui part du principe que le code est malveillant.

Vos résultats varieront en fonction de la structure de l’arborescence. Un projet comportant 40 dépendances directes et ne faisant appel à aucun framework faisant un usage intensif de proc-macros constitue un audit gérable. En revanche, un service utilisant des environnements d’exécution asynchrones, la sérialisation et un framework web peut facilement atteindre plusieurs centaines de crates transitifs, avec de nombreux points d’exécution à la compilation. Or, un conseil qui traiterait ces deux cas de la même manière proviendrait de quelqu’un qui n’a pas exécuté la commande `cargo tree` sur le second projet.

Le rôle de SecureChain pour Rust

Tout ce qui précède vise à identifier les failles, et non à les corriger. La commande `cargo audit` vous indique ce qui a déjà été signalé. La commande `cargo vet` vous indique ce qui a déjà été vérifié. Aucune de ces deux commandes n'intervient sur une « crate » qui exécute du code malveillant avant qu'elles n'aient pu l'examiner, et aucune ne propose de correctif pour un avis de sécurité pour lequel il n'existe pas de correctif en amont.

C’est précisément à cela que sert SecureChain pour Rust. Il recompile les crates à partir du code source dans des environnements isolés, les analyse à la recherche de logiciels malveillants et de comportements suspects lors de l’installation, et continue d’appliquer des correctifs dans le cadre d’un SLA à mesure que de nouvelles vulnérabilités (CVE) sont identifiées. Lorsque la maintenance en amont prend fin, le service « Endless Lifecycle Support » prend le relais et continue de fournir des correctifs tant que la crate reste dans votre pile. Ainsi, une dépendance abandonnée ne devient jamais, sans que vous vous en rendiez compte, une dépendance non corrigée dans votre arborescence.

Si vous cherchez à prendre de l'avance sur ce qui se cache dans vos dépendances transitives, le webinaire de TuxCare consacré à « l'iceberg des dépendances » explore en détail la manière dont les CVE se propagent à travers les chaînes de dépendances, qui restent invisibles même lorsque votre tableau de bord semble impeccable.

FAQ

En quoi consiste l'audit de fret ?

Il compare les caisses présentes dans votre Cargo.lock en se référant à la base de données d’avis de sécurité RustSec et signale les vulnérabilités, les versions retirées et les avis d’information concernant les crates non maintenues ou non fiables. Il ne lit pas le code source des crates et n’intercepte pas les installations, mais son code de sortie en fait un excellent filtre pour les environnements de CI. Une fonctionnalité expérimentale cargo audit fix La sous-commande peut mettre à jour certaines dépendances vulnérables, mais vous devez installer « cargo audit » avec la fonctionnalité de correction activée pour en bénéficier.

L'audit du fret échoue-t-il en cas de caisses non entretenues ?

Ce n'est pas le cas par défaut. Les avis d'information, y compris ceux qui ne sont plus mis à jour, s'affichent sous forme d'avertissements, sauf si vous configurez le système autrement. Exécutez la commande cargo audit --deny warnings de ne pas les respecter, ou de rejeter une seule catégorie, comme celle des projets non maintenus, tout en s'attendant à ce que la première exécution d'un projet bien établi prenne beaucoup de temps.

Quelle est la différence entre un « cargo audit » et un « cargo vet » ?

« cargo audit » vérifie si une caisse fait l’objet d’un avis, ce qui ne vous demande aucune intervention. « cargo vet » vérifie si votre graphe de dépendances répond aux critères d’audit que vous avez configurés, en utilisant vos propres audits, les audits importés, les audits delta et les éventuelles exemptions que vous avez conservées. Une nouvelle version nécessite de nouvelles preuves, sauf si elle est déjà couverte par un audit existant ; un audit delta consiste généralement à examiner uniquement les différences par rapport à une version déjà auditée.

Cargo peut-il empêcher l'exécution des scripts de build ?

Non. Stable Cargo ne dispose d'aucun indicateur permettant de désactiver les scripts de compilation ou les macros procédurales, qui exécutent tous deux du code arbitraire lors de la compilation et ont accès à tout ce que contient l'environnement de compilation.

Comment puis-je repérer les caisses abandonnées dans mon arbre de dépendances ?

Il n'y a pas de commande spécifique pour cela. Exécutez cargo audit --deny warnings pour repérer les avis déposés mais non mis à jour, puis vérifier les dates de dernière publication, si le dépôt est archivé et le nombre de propriétaires via cargo owner --list pour tout ce qui touche à la sécurité.

Que se passe-t-il lorsqu'un avis de sécurité de RustSec ne mentionne aucune version corrigée ?

Rien ne le résout automatiquement. Il faut créer une branche, corriger le crate, remplacer la dépendance, puis appliquer un correctif local via [patch.crates-io] et d'en assurer la maintenance, de documenter un contrôle compensatoire, ou de faire appel à un fournisseur qui intègre rétrospectivement des correctifs dans les crates dont les responsables en amont ont cessé d'assurer la maintenance.