SBOM pour les projets Rust et Cargo pour le CRA

Le Cyber Resilience Act demande à chaque fabricant de tenir une nomenclature des logiciels « dans un format couramment utilisé et lisible par machine couvrant au moins les dépendances de niveau supérieur des produits » (annexe I, partie II, point 1). Rust part sur de bonnes bases : Cargo.lock fixe chaque crate avec son empreinte, et la base d’avis RustSec nomme souvent les fonctions exactes qu’une vulnérabilité touche. Il faut surtout prêter attention à ce que le fichier de verrouillage liste sans le livrer, et à ce qui est livré sans être listé.

Pour le règlement lui-même, voir Le SBOM pour le Cyber Resilience Act.

Versionner Cargo.lock

Pour tout binaire que vous distribuez, versionnez Cargo.lock et construisez avec cargo build --locked. Le fichier de verrouillage enregistre alors les crates et versions exactes de la version livrée. Les dépendances directes sont celles déclarées dans chaque Cargo.toml de l’espace de travail.

Produire le SBOM

Le plugin Cargo du projet CycloneDX demande à Cargo le graphe des dépendances résolu :

cargo install cargo-cyclonedx
cargo cyclonedx --format json

Il écrit un fichier à côté de chaque Cargo.toml de l’espace de travail. Deux options comptent pour un SBOM exact :

--target : Cargo.lock liste les dépendances de toutes les plateformes, si bien que le fichier d’un build Linux contient encore windows-sys. Indiquez la cible que vous construisez (par défaut, celle de la machine) pour écarter ce qui n’est pas compilé.
Les fonctionnalités (features) : le plugin suit la sélection de Cargo. Reprenez les mêmes --features ou --all-features que pour votre build de publication.

Les dépendances de développement sont laissées de côté, puisqu’elles ne peuvent pas arriver dans le binaire.

Mettre la liste dans le binaire

cargo-auditable inscrit la liste des dépendances dans l’exécutable compilé, dans une petite section compressée :

cargo install cargo-auditable
cargo auditable build --release

Le binaire se décrit alors lui-même. cargo audit bin ./target/release/app le compare à RustSec, et Syft, Trivy et Grype le lisent aussi. C’est utile pour le CRA quand les binaires se retrouvent là où le SBOM d’origine se perd : images de micrologiciel, serveurs des clients, images de conteneur.

Cargo lui-même prépare une prise en charge native : une option instable -Z sbom écrit des fichiers « précurseurs de SBOM » à côté des résultats du build, et sa stabilisation fait partie des objectifs du projet Rust pour 2026.

Ce que le fichier de verrouillage ne montre pas

Le code C des crates -sys. openssl-sys avec la fonctionnalité vendored compile OpenSSL à partir de la crate openssl-src ; libsqlite3-sys avec bundled compile SQLite. Le SBOM liste la crate, alors que les avis de sécurité de la bibliothèque C sont publiés au nom d’OpenSSL ou de SQLite. openssl-src porte la version d’OpenSSL dans son propre numéro de version (300.x.y+3.x.y), qu’on peut donc y lire ; pour les autres crates, indiquez vous-même dans le SBOM la bibliothèque embarquée et sa version.
Les scripts de build et les macros procédurales. build.rs et les crates de macros s’exécutent à la compilation et ne sont pas dans le binaire en tant que tels, mais ils façonnent le code qui y est. Ils ont leur place dans l’inventaire comme composants de build.
La chaîne de compilation Rust. La bibliothèque standard est compilée dans votre binaire. Ses rares avis de sécurité sont corrigés dans les nouvelles versions de Rust : consignez la version du compilateur de chaque version livrée.

Du SBOM aux vulnérabilités

cargo audit compare Cargo.lock à la base d’avis RustSec, qu’OSV republie aussi. Les avis RustSec listent souvent les fonctions touchées (smallvec::SmallVec::insert_many), ce qui permet de vérifier si votre code les appelle avant de trancher. Regardez d’abord les vulnérabilités exploitées, qui peuvent déclencher le délai de signalement, et consignez dans une déclaration VEX pourquoi une fonction vulnérable que vous n’appelez jamais ne touche pas le produit.

Ce que fait Provetry

Provetry lit Cargo.lock, depuis votre CI ou dans les fichiers que vous envoyez, prend les dépendances directes dans les fichiers Cargo.toml, établit le SBOM de chaque version en CycloneDX, et en SPDX avec les offres payantes, et surveille chaque jour avec les offres payantes et chaque semaine avec l’offre gratuite chaque crate pour les vulnérabilités nouvelles et exploitées. Son étape de CI va un cran plus loin pour Rust : quand RustSec nomme les fonctions touchées, que seul votre propre code dépend de la crate, qu’aucune de ses macros n’est utilisée et qu’aucune de ces fonctions n’apparaît dans votre dépôt, il propose « non concerné » avec cette preuve. Il ne conclut rien quand Rust peut les appeler sans que leur nom figure dans le code : méthodes de traits, opérateurs, macros, dérivations, réexportations et code généré au build. Quand un fichier en mentionne une, il donne le fichier et la ligne à vérifier d’abord. Chaque résultat est une suggestion, que vous acceptez ou non.