SBOM : ce qu'il faut demander à un fournisseur

Depuis quelques années, la demande d'une nomenclature logicielle (SBOM, Software Bill of Materials) apparaît dans les appels d'offres et les questionnaires de sécurité. Beaucoup d'acheteurs l'exigent sans savoir ce qu'ils feront du fichier ; beaucoup de fournisseurs la produisent sans savoir ce qu'elle doit contenir. Les deux camps ont maintenant un texte de référence commun.

Ce que disent les sources

En juillet 2021, la NTIA (National Telecommunications and Information Administration, États-Unis) a publié les éléments minimaux d'une SBOM, en réponse au décret 14028. Le document définit la SBOM comme un enregistrement formel des composants utilisés pour construire un logiciel et de leurs relations, et fixe trois familles d'éléments : les champs de données (fournisseur, nom du composant, version, autres identifiants uniques, relation de dépendance, auteur de la SBOM, horodatage), le soutien à l'automatisation (formats SPDX, CycloneDX et étiquettes SWID) et les pratiques (fréquence, profondeur, inconnues connues, distribution, contrôle d'accès, tolérance aux erreurs).

Le 29 juillet 2026, la CISA, la NSA, le FBI et des partenaires internationaux, dont le Centre canadien pour la cybersécurité, ont publié les éléments minimaux 2026, qui remplacent le texte de 2021 après une consultation publique ayant reçu plus de 90 commentaires. Les champs sont désormais séparés en deux catégories : les métadonnées de la SBOM (auteur, signature, horodatage, outil de génération, contexte de génération, version du document) et les données de composant (producteur, nom, version, identifiants, relation de dépendance, valeur et algorithme de hachage, licence). La profondeur devient la couverture : la SBOM doit inclure tous les composants, y compris les dépendances transitives, sans profondeur minimale. Les formats reconnus restent SPDX (ISO/IEC 5962:2021) et CycloneDX (ECMA-424). Le texte s'applique à tout logiciel, y compris le logiciel libre, l'IA et le SaaS, tout en reconnaissant que ces deux derniers peuvent exiger des éléments supplémentaires.

Un passage du texte de 2026 mérite d'être retenu : le destinataire d'une SBOM devrait pouvoir conclure qu'une vulnérabilité nouvellement publiée ne le concerne pas si le composant visé n'apparaît pas dans la SBOM. C'est exactement l'usage qu'un acheteur devrait en faire.

Pourquoi ça compte

Une SBOM n'est pas un rapport de vulnérabilités. Elle ne dit pas si le logiciel est sûr ; elle dit de quoi il est fait. La valeur apparaît le jour où une vulnérabilité touche une bibliothèque largement diffusée : l'organisation qui possède les SBOM de ses logiciels critiques répond en une requête, celle qui ne les a pas écrit à ses fournisseurs et attend.

C'est aussi le seul document qui rende vérifiable une réponse de questionnaire. « Nous gérons nos dépendances tierces » se lit sur une page ; une SBOM complète, signée, livrée avec chaque version, se vérifie.

Les erreurs d'acheteur que nous voyons le plus : exiger une SBOM sans préciser le format ni la couverture, recevoir un PDF que personne ne peut charger dans un outil, accepter la SBOM d'une version dépassée, et ne jamais l'ouvrir.

Les erreurs de fournisseur sont symétriques : produire une SBOM à la main, la livrer une fois, ne pas distinguer « aucune dépendance » de « dépendances inconnues », et refuser toute SBOM par crainte de révéler des secrets, alors qu'elle liste des composants, pas des configurations.

Ce que nous en pensons chez Sentrix

Une clause SBOM raisonnable tient en cinq exigences, toutes appuyées sur les éléments minimaux de 2026 :

1. Un format lisible par machine, SPDX ou CycloneDX, avec la version du format précisée. Refusez le PDF et le tableur.
2. Une SBOM par version livrée, générée par un outil dont le nom figure dans les métadonnées, horodatée, et régénérée à chaque nouvelle version. C'est l'élément Fréquence.
3. La couverture complète, dépendances transitives incluses, et une mention explicite de ce qui est inconnu ou volontairement retenu. Une SBOM qui ne déclare pas ses inconnues est incomplète.
4. Les identifiants et les hachages pour chaque composant, afin que votre outil de gestion des vulnérabilités puisse faire la corrélation sans intervention humaine.
5. Un canal de livraison convenu, URL propre à la version, API ou dépôt, avec un contrôle d'accès qui n'empêche pas l'intégration dans vos outils.

N'exigez pas l'impossible : la SBOM d'un service SaaS change au rythme du service, et le texte de 2026 reconnaît que la fréquence de livraison doit s'y adapter. Demandez plutôt la SBOM du dernier déploiement et, quand une vulnérabilité fait la manchette, un avis VEX (Vulnerability Exploitability eXchange), l'attestation qui indique si un produit est touché par une vulnérabilité connue.

Pour ISO 27001:2022, ces exigences alimentent les contrôles 5.19 à 5.21 (relations avec les fournisseurs et chaîne d'approvisionnement TIC) et 8.8 (gestion des vulnérabilités techniques). Pour NIS2, elles documentent la sécurité de la chaîne d'approvisionnement que la directive exige des entités concernées. La fiche ISO 27001 et la fiche NIS2 situent ces contrôles ; le module de risques tiers de la plateforme Sentrix conserve la SBOM avec le dossier du fournisseur.

La prochaine étape

Prenez vos cinq logiciels les plus critiques et demandez leur SBOM cette semaine, sans clause contractuelle, juste par courriel. La réponse (le fichier, le format, la date, ou le silence) vous dira où en est chaque fournisseur, et par où commencer.