Un SBOM équivaut-il à une page de conformité des licences ?

Un SBOM est un inventaire de composants lisible par machine, construit pour l'outillage de sécurité et de chaîne d'approvisionnement, pas pour la divulgation de licences. Les éléments minimaux de la NTIA le définissent comme fournisseur, nom du composant, version, identifiants uniques, relations de dépendance et auteur : des données d'identité pour la mise en correspondance de vulnérabilités, pas un texte de licence révisé.

L'outillage de sécurité met en correspondance les CVE avec l'identité des composants. La documentation de l'Annexe I du CRA attend des listes de composants dans des formats couramment utilisés. Les équipes de réponse aux vulnérabilités retracent le rayon d'impact à travers les graphes de dépendances.

Les champs de licence d'un SBOM sont des points de départ, pas des approbations. Les identifiants SPDX dans CycloneDX proviennent souvent des métadonnées du registre npm, qui sont fréquemment incorrectes, incomplètes, ou marquées NOASSERTION. Les équipes AppSec joignent rarement le texte intégral d'une licence GPL ou d'un SDK propriétaire à un export SBOM.

• Identité des composants (nom, version, PURL, empreinte) pour la mise en correspondance de vulnérabilités.
• Métadonnées de fournisseur et d'auteur pour la traçabilité de la chaîne d'approvisionnement.
• Format lisible par machine (CycloneDX, SPDX) pour l'outillage et la documentation réglementaire.
• Une entrée pour la documentation des composants du CRA et les programmes de sécurité produit.
• Détection de dérive quand la CI génère un nouveau SBOM à chaque build.
• Pas : une divulgation de licences tierces lisible par un humain pour la revue juridique.
• Pas : le texte intégral, la mention ou les blocs d'attribution par composant.
• Pas : des verrous de publication confirmant qu'un humain a révisé chaque obligation.

La divulgation de licences fournit un texte de licence révisé et lisible par un humain, une attribution et des mentions rattachées à une version livrée précise, ce qu'un SBOM n'apporte pas. Un SBOM répond à « quels composants sont présents » pour l'outillage de sécurité ; la divulgation répond à « qu'avons-nous l'obligation légale de reproduire quand nous livrons cela » pour les achats et le juridique.

La divulgation de licences tierces répond aux questions des achats et du juridique : quel logiciel open source et tiers se trouve dans ce produit, sous quelles licences, avec quelle mention et quelle attribution, à quelle version révisée.

Dans les équipes d'ingénierie de plusieurs personnes, les dépendances changent constamment. Un ingénieur fusionne un patch ; un autre ajoute un SDK ; des paquets transitifs évoluent. Un dossier de divulgation ne fonctionne que s'il est réimporté, révisé à nouveau et republié quand la base de code change, que vous l'hébergiez sur une URL ou que vous joigniez un export à un questionnaire.

• Inventaire révisé par produit livré, pas de simples métadonnées brutes du registre.
• Texte intégral pour chaque composant du périmètre, pas seulement l'identifiant SPDX.
• Attribution et mention de copyright là où MIT, Apache, BSD, GPL les exigent.
• Lignes copyleft et licences personnalisées bloquées jusqu'à révision explicite.
• Un périmètre de produit clair : quel SKU ou quelle version couvre le dossier.
• Une approbation de publication : quelqu'un de responsable avant tout partage externe.
• Un processus de maintenance : mise à jour quand les lockfiles ou les SBOM changent.

Gardez ce tableau à portée de main quand un questionnaire demande à la fois un « SBOM » et une « conformité des licences open source ». Ils se recoupent sur l'inventaire, mais pas sur le livrable.

Non. Vous pouvez générer des fichiers CycloneDX parfaits à chaque version et échouer quand même à une revue achats qui demande la conformité des licences, parce qu'un SBOM liste des composants mais ne reproduit pas le texte de licence, les mentions et l'attribution qu'exigent les obligations de distribution.

L'acheteur ouvre votre pièce jointe, voit des noms de composants et des chaînes « MIT », et demande où se trouve le texte de la licence.

Le CRA pousse les organisations à documenter leurs composants, ce qui accélère l'adoption du SBOM. Cela ne remplace pas des décennies d'attente des acheteurs voyant les fournisseurs maintenir une divulgation de licences tierces. La documentation de sécurité produit de l'UE et les sections de licence des appels d'offres grand compte sont des pistes parallèles.

Les équipes sécurité portent la gravité des vulnérabilités, les correctifs, le signalement des incidents. Les obligations de licence (mention, attribution, conditions de copyleft) ont besoin d'un responsable qui révise avant tout partage externe. Ce responsable est rarement la même personne qui fusionne les PR de Dependabot.

Le modèle efficace importe le même SBOM ou lockfile dans les deux pipelines. La sécurité consomme le SBOM pour les CVE et la documentation CRA. La conformité importe le même fichier dans une file de révision : chaque composant a besoin d'une révision, d'un texte intégral, d'une approbation, puis d'une publication dans un dossier de divulgation.

Quand le SBOM change à la version suivante, les deux équipes réagissent. La sécurité relance une analyse de vulnérabilités. La conformité révise à nouveau les lignes de licence nouvelles ou modifiées. Une seule source d'inventaire, deux sorties. Aucune des deux sorties ne remplace l'autre.

• Importez CycloneDX, SPDX, ou des lockfiles une fois par candidat à la version.
• Sécurité : analyse de vulnérabilités, documentation CRA, traçabilité des incidents.
• Conformité : correspondance de licence, ajout du texte intégral, remontée du copyleft, verrou de publication.
• Publiez le dossier de divulgation à partir de l'instantané approuvé (page ou export selon ce que demande l'acheteur).
• Contrôle de dérive : signalez les changements de SBOM qui manquent d'une nouvelle approbation de conformité.

Téléverser un JSON de SBOM sur un portail fournisseur et appeler cela conformité des licences. Coller des identifiants SPDX dans un tableur sans le texte. Présumer qu'une analyse de licence FOSSA ou Snyk équivaut à une divulgation révisée sans verrous de publication.

Générer un PDF depuis l'outillage SBOM une fois et le réutiliser à chaque version pendant que les ingénieurs continuent de fusionner des dépendances. Le même problème d'instantané obsolète que n'importe quel export statique, quel que soit le format.