Import SBOM

Du SBOM ou du lockfile à une page de conformité

Si vous générez déjà des exports CycloneDX, des lockfiles npm ou des entrées similaires, voici comment les transformer en un dossier de divulgation révisé.

Dernière mise à jour : 2 juillet 2026

Si vous générez déjà des SBOM CycloneDX, des fichiers SPDX, ou des exports depuis FOSSA, Snyk, Mend ou Syft, vous disposez déjà de la matière première pour la conformité des licences. Une nomenclature logicielle liste des composants : noms, versions, fournisseurs, empreintes. Une page de conformité des licences y ajoute des identifiants de licence révisés, le texte intégral, l'attribution, et une URL stable pour la divulgation de licences tierces.

Le travail sur les SBOM soutient les programmes de sécurité et de réglementation (y compris la documentation des composants pour le CRA). Les pages de conformité des licences répondent aux questions des achats et du juridique sur les obligations de licences open source. Le pipeline du SBOM à la page de conformité, c'est import, enrichissement, révision, publication. Pas un simple export-et-téléversement inchangé.

Quelle est la différence entre un SBOM et une page de conformité des licences ?

Un SBOM est un inventaire lisible par machine, optimisé pour la mise en correspondance de vulnérabilités et l'outillage de chaîne d'approvisionnement ; une page de conformité des licences est une divulgation de licences tierces lisible par un humain, optimisée pour un réviseur achats qui ouvre un onglet de navigateur pendant une diligence fournisseur. Ils répondent à des questions différentes et se substituent rarement l'un à l'autre.

Les acheteurs demandent les deux dans des sections différentes du questionnaire. Ne soumettre qu'un SBOM quand ils demandent une page de licences open source les oblige à courir après le texte intégral manuellement, ou à vous pénaliser pour divulgation incomplète.

	SBOM	Page de conformité
Contenu	Identité des composants, versions, empreintes, fournisseurs	Licences révisées, texte intégral, attribution, périmètre du produit
Format	JSON ou XML, mis à jour par la CI	URL publique avec verrous de publication, plus des exports par version
Public visé	Outillage de sécurité et programmes CRA	Réviseurs achats et juridique

Étape 1 : importer le SBOM ou le lockfile

Intégrez vos fichiers CycloneDX, SPDX ou vos lockfiles de paquets dans votre flux de divulgation. Faites correspondre les composants du SBOM à des lignes dans votre file de révision. Chaque ligne démarre en attente de révision. Les champs de licence du SBOM sont des indices, pas des approbations.

Un SBOM par produit et par version. Ne fusionnez pas des produits sans rapport dans une seule page de conformité des licences, sauf si votre modèle de divulgation délimite explicitement des sections. Les achats attendent de la clarté.

Importez depuis un artefact CI, un tag de version, ou un export d'outil SBOM.
Conservez le nom du composant, la version, et le PURL ou un identifiant équivalent.
Considérez le champ de licence du SBOM comme un point de départ, pas une réponse finale.
Signalez les composants avec des données de licence manquantes, contradictoires, ou marquées NOASSERTION.
Réimportez à chaque version. Ne rafistolez pas indéfiniment un JSON obsolète à la main.

Étape 2 : enrichir et réviser

Les SBOM incluent souvent des identifiants de licence SPDX sans le texte intégral. La divulgation de licences tierces exige un texte que les achats puissent lire. Enrichissez chaque composant approuvé avec le contenu intégral de la licence, les mentions d'attribution, et les signalements de copyleft de votre politique de révision.

Résolvez les conflits entre la licence du registre et celle du dépôt. Faites remonter les licences personnalisées et copyleft. La conformité échoue quand les métadonnées du SBOM sont recopiées sur une page publique sans vérification humaine.

Joignez le texte intégral de la licence pour chaque composant approuvé.
Confirmez la licence par rapport au fichier LICENSE du dépôt, au PDF du fournisseur, ou aux directives juridiques.
Appliquez les règles de révision du copyleft et de la distribution avant d'approuver.
Ajoutez les blocs de mention et d'attribution là où requis.
Documentez les exclusions : dépendances de développement non livrées, paquets réservés aux tests, etc.
Bloquez la publication tant qu'il reste des lignes non révisées dans le périmètre.

Étape 3 : publier la page de conformité des licences et les exports

À partir du même inventaire approuvé, publiez une divulgation maintenue et générez des exports. Partagez le format que la diligence demande : URL, PDF, ou lot. Les exports se joignent aux tickets, aux notes de version, ou aux portails fournisseurs.

Quand le SBOM change à la version suivante (nouveaux paquets, montées de version, changements de licence), réimportez, révisez à nouveau, republiez. Les contrôles de dérive automatisent la comparaison pour que vous ne soyez pas surpris lors d'un audit client.

Publiez une preuve partageable par produit (page hébergée et/ou exports).
Vérifiez que la divulgation se charge, que le texte intégral s'affiche, et que le périmètre du produit est clair.
Exportez les fichiers JSON, d'attribution et les lots de divulgation à partir du même instantané.
Configurez la CI pour signaler quand le SBOM dérive de votre dernière publication approuvée.
Partagez la divulgation révisée avec les achats, pas le SBOM brut, quand ils demandent une documentation de conformité des licences.

Les outils que vous utilisez déjà

FOSSA, Snyk, Mend, Syft, le graphe de dépendances GitHub, et vos pipelines CI internes produisent des SBOM et des indices de licence. SourceTrust et les flux de divulgation similaires se situent en aval : un dossier de publication révisé, une URL de page de conformité, des exports alignés sur ce qui est livré.

Vous ne remplacez pas votre outil SBOM. Vous transformez sa sortie en une divulgation de licences tierces que vos clients et vos auditeurs peuvent utiliser. La conformité des licences comme un artefact produit maintenu, pas un simple dépôt de fichier ponctuel.