Demandes de SBOM des clients : comment y répondre

Vous fournissez des composants ou du logiciel embarqué à des fabricants ? Voir le guide SBOM pour les fournisseurs, qui couvre les contrats, VEX et une SBOM par version logicielle livrée.

Pourquoi les clients posent la question maintenant

• Le Cyber Resilience Act. Les fabricants qui vendent dans l'UE ont besoin d'une SBOM de leur propre produit et doivent faire preuve de diligence pour les composants qu'ils intègrent : la question descend donc la chaîne d'approvisionnement.
• NIS2. Les entités essentielles et importantes doivent traiter la sécurité de la chaîne d'approvisionnement. La directive ne cite pas les SBOM, mais une SBOM est un moyen pour un acheteur de voir ce que livre un fournisseur. Voir les SBOM comme preuves NIS2, ISO 27001 et SOC 2.
• Les règles sectorielles. La section 524B de la FDA exige une SBOM pour les cyber devices, et d'autres secteurs ont leurs propres règles.
• Leur propre travail sur les vulnérabilités. Un client qui sait ce que contient votre produit peut déterminer si une nouvelle CVE le touche sans ouvrir de ticket de support.

Ce qu'il faut convenir avant d'envoyer quoi que ce soit

Question	Pourquoi c'est important
Quel produit et quelle version ?	Une SBOM décrit une seule release. Envoyez celle que le client utilise, pas le dernier build.
Quel format ?	La plupart des demandes acceptent CycloneDX ou SPDX. Demandez s'il leur faut une version précise.
Quelle profondeur ?	Les dépendances de premier niveau peuvent ne pas suffire. Attendez-vous à ce qu'on vous demande les transitives.
Une fois, ou à chaque release ?	Un contrat peut prévoir une nouvelle SBOM à chaque release, ce qui exclut tout travail manuel.
À quelles conditions ?	Une SBOM montre comment votre produit est construit. Convenez des conditions de confidentialité et du mode de transmission du fichier.

Ce que contient une bonne réponse

• Une SBOM au format convenu, pour la release exacte que le client utilise.
• Chaque composant avec son nom, sa version, son fournisseur, sa licence et un identifiant de paquet.
• Les relations entre dépendances, pour qu'un paquet transitif puisse être rattaché à ce qui l'a apporté.
• La date, l'outil qui l'a produite et le build dont elle provient.
• Une note honnête sur tout ce que la SBOM ne couvre pas (voir complétude de la SBOM).

Pour voir à quoi ressemblent les fichiers, consultez les exemples de SBOM. Sur les deux formats, voir CycloneDX vs SPDX. Pour ce que le client contrôlera probablement à réception, voir la checklist qualité SBOM.

Les erreurs qui reviennent plus tard

• Envoyer le dernier build au lieu de celui qui a été livré. Les builds ne sont pas reproductibles par défaut : reconstruire le même commit ne garantit donc pas la même SBOM. Seule la SBOM du build qui a produit la release montre ce que le client a reçu.
• L'assembler à la main pour l'occasion. Cela répond à la demande une fois, et il faudra recommencer pour le client suivant et la release suivante. Voir l'automatisation des SBOM.
• Promettre plus que ce que vous pouvez répéter. « Nous en enverrons une à chaque release » est une ligne facile à écrire dans un contrat, et difficile à tenir sans automatisation.
• Considérer que la SBOM clôt le sujet. La question suivante est « êtes-vous touché par cette CVE ? », et elle arrive avec la prochaine grande vulnérabilité.

Comment être prêt pour la prochaine demande

Les demandes deviennent simples quand la SBOM existe déjà. Produisez-en une pour chaque release dans le pipeline qui la construit, conservez-la avec la release et surveillez-la pour détecter les nouvelles vulnérabilités. Une demande se résume alors à un téléchargement et une courte note, et vous pouvez répondre à la question suivante à partir du même enregistrement.

Comment CRACI s'en charge

CRACI enregistre une SBOM à partir de chaque build GitHub Actions exécuté sur ses runners : chaque release en a donc déjà une au moment où quelqu'un la demande.

• Export en CycloneDX ou SPDX, y compris les dépendances transitives et les vulnérabilités trouvées dans les composants.
• Des preuves issues du build lui-même. Chaque composant de la SBOM était dans le build, et les dépendances cachées que les outils basés sur les lockfiles manquent sont enregistrées.
• Un état de complétude pour chaque job, pour que vous sachiez ce que vous envoyez avant de l'envoyer.
• Historique des builds. Vous pouvez consulter les builds passés et leurs SBOM, ainsi que les builds qui contenaient une dépendance vulnérable, pendant votre période de conservation.
• Des réponses à la question suivante. CRACI réévalue en continu les SBOM surveillées, prend en charge VEX et montre quels produits utilisent quelles versions dans la vue d'inventaire.

Demandes de SBOM des clients : questions fréquentes

Sommes-nous tenus de fournir notre SBOM à nos clients ?

Cela dépend de votre marché et de vos contrats. Le Cyber Resilience Act fait de la SBOM une partie de la documentation technique, transmise à une autorité de surveillance du marché sur demande, et il n'impose pas de la publier. Le droit d'un client à l'obtenir vient généralement du contrat : vérifiez donc ce que vous avez convenu.

Quel format de SBOM devons-nous envoyer ?

CycloneDX ou SPDX, selon ce que demande le client. S'il n'a pas de préférence, l'un comme l'autre convient. Demandez si ses outils ont besoin d'une version précise.

Devons-nous inclure les dépendances transitives ?

Le Cyber Resilience Act demande au minimum les dépendances de premier niveau, mais de nombreux acheteurs attendent l'arbre complet, et les vulnérabilités se trouvent souvent dans des paquets transitifs. Une SBOM complète est la réponse la plus sûre.

La SBOM doit-elle être transmise au client sous NDA ?

C'est à vous et à votre client d'en décider. Une SBOM montre de quoi est fait votre produit : de nombreux éditeurs la partagent donc dans le cadre de leur contrat existant ou d'un NDA plutôt que de la publier.

À quelle fréquence devons-nous envoyer une SBOM à jour ?

Aussi souvent que vous en êtes convenus. Les dépendances changent à chaque release : une nouvelle SBOM par release est donc la règle honnête, et ce n'est praticable que si la SBOM sort du build.

Et si le client pose une question sur une release plus ancienne ?

Il vous faut la SBOM du build qui a produit cette release. CRACI conserve l'historique des builds pendant votre période de conservation, 180 jours par défaut avec une durée personnalisée sur Enterprise : exportez donc tout ce que vous devez garder plus longtemps.

Nous n'avons jamais fait de SBOM. Par où commencer ?

Commencez par la release que votre client utilise et un outil qui travaille à partir de votre build réel. Si vous êtes sur GitHub Actions, passer le build sur des runners CRACI vous donne une SBOM enregistrée dès la première exécution.