SBOM pour les projets .NET et NuGet pour le CRA
Sur cette page
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). En .NET, les paquets NuGet ne sont qu’une partie de la réponse. Le runtime sur lequel tourne votre application est aussi un composant, et quand vous le livrez avec le produit, ses dates de support deviennent les vôtres.
Pour le règlement lui-même, voir Le SBOM pour le Cyber Resilience Act.
Activer le fichier de verrouillage NuGet
Les projets en PackageReference n’écrivent pas de fichier de verrouillage si on ne le demande pas. Ajoutez ceci à chaque projet, ou à Directory.Build.props pour toute la solution :
<PropertyGroup>
<RestorePackagesWithLockFile>true</RestorePackagesWithLockFile>
</PropertyGroup>
dotnet restore écrit alors un packages.lock.json à côté de chaque projet, avec chaque paquet direct et transitif à sa version résolue et son empreinte. Versionnez-le, et restaurez avec dotnet restore --locked-mode en CI : le build échoue au lieu de résoudre d’autres versions en silence. Les projets plus anciens qui utilisent encore packages.config y listent leurs paquets.
Produire le SBOM
Le module CycloneDX pour .NET lit une solution ou un projet et écrit du CycloneDX :
dotnet tool install --global CycloneDX
dotnet-CycloneDX MySolution.sln -o sbom -F Json
Pour une solution, il rassemble tous les projets ; -rs suit plutôt les références de projet à partir d’un seul projet. Les projets de test font partie de la solution : excluez-les (--exclude-test-projects), ou pointez l’outil sur le projet que vous livrez vraiment.
L’outil sbom-tool de Microsoft procède autrement. Il analyse ensemble le résultat du build et le dossier source, et écrit du SPDX :
sbom-tool generate -b ./publish -bc ./src -pn MyProduct -pv 2.4.0 -ps "Acme SAS" -nsb https://acme.example/sbom -mi SPDX:3.0
Il écrit du SPDX 2.2 par défaut ; -mi SPDX:3.0 choisit SPDX 3.0. Comme il part du dossier que vous publiez, il décrit les fichiers réellement livrés, avec leurs empreintes.
Le runtime fait partie du produit
Votre mode de publication décide de ce que contient le produit :
- Dépendant du framework : l’application suppose un runtime .NET déjà installé chez le client. Votre SBOM couvre vos paquets ; votre documentation doit dire quelle version du runtime est requise, et qu’elle doit être tenue à jour.
- Autonome (
--self-contained), et tout build Native AOT : le runtime, ou les parties que vous en utilisez, est livré dans votre produit. Sa version est un composant, et les mises à jour de sécurité mensuelles de Microsoft deviennent des mises à jour de votre produit.
Les dates de support suivent la même logique. Le support de .NET 8 et de .NET 9 s’arrête le 10 novembre 2026 ; .NET 10, version à support long, est maintenu jusqu’en novembre 2028. Un produit livré en autonome sur .NET 8 ne reçoit plus de correctifs de sécurité du runtime à partir de cette date, alors que le CRA vous demande de traiter les vulnérabilités pendant toute la période d’assistance que vous avez annoncée (article 13, paragraphe 8). Comparez la fin de support du runtime à la vôtre avant de l’annoncer.
Du SBOM aux vulnérabilités
NuGet compare les paquets à la base d’avis de GitHub pendant dotnet restore (NuGet Audit, actif par défaut depuis le SDK .NET 8), et dotnet list package --vulnerable --include-transitive liste ce qu’il trouve. 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 les autres ne touchent pas votre produit, quand c’est le cas.
Ce que fait Provetry
Provetry lit packages.lock.json, depuis votre CI ou dans les fichiers que vous envoyez, avec les dépendances directes qu’il enregistre, é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 paquet pour les vulnérabilités nouvelles et exploitées. Vous pouvez aussi envoyer le SBOM écrit par CycloneDX pour .NET ou par sbom-tool. Son étape de CI montre où votre code importe un paquet vulnérable, avec le fichier et la ligne. Pour les paquets NuGet, il ne conclut jamais qu’un paquet est inutilisé, car les espaces de noms ne disent pas de façon sûre de quel paquet ils viennent. Pour le runtime, indiquez la fin de votre période d’assistance dans la fiche du produit, et comparez-la aux dates de Microsoft.