SBOM : c'est quoi, quel format, un exemple CycloneDX

Un SBOM, pour « software bill of materials », est la liste des composants d'un logiciel, avec leurs versions et leurs liens. En français : nomenclature logicielle. Le Cyber Resilience Act en impose un à chaque fabricant pour les produits mis sur le marché à partir du 11 décembre 2027.

À quoi sert un SBOM

Quand une faille est publiée dans une bibliothèque, le SBOM dit tout de suite quels produits et quelles versions la contiennent. Il sert aussi à repérer les composants abandonnés et à suivre les licences. Peu d'entreprises en produisent : 35 % des PME de l'enquête de l'ENISA de juin 2026, et 32 % des fabricants interrogés par la Linux Foundation en janvier 2026.

Ce que le Cyber Resilience Act demande

• un format courant et lisible par machine (annexe I, partie II, point 1) ;
• au moins les dépendances de premier niveau, celles que le produit intègre directement ;
• une place dans la documentation technique (annexe VII) : le SBOM se remet à l'autorité sur demande, il n'a pas à être publié ;
• une diligence sur les composants tiers, libres compris (article 13, paragraphe 5), et le signalement d'une faille trouvée au mainteneur du composant (paragraphe 6).

La Commission peut imposer un format par un acte d'exécution (article 13, paragraphe 24). Aucun n'était publié au 30 octobre 2026.

Quel format de SBOM choisir

Deux formats ouverts dominent :

• CycloneDX, porté par l'OWASP et normalisé par Ecma International (ECMA-424), en version 1.7 ;
• SPDX, porté par la Linux Foundation, en version 3.0.1.

Faute de format européen, la directive technique allemande TR-03183-2 du BSI (version 2.1.0 du 20 août 2025) sert de repère : CycloneDX 1.6 ou plus, ou SPDX 3.0.1 ou plus, en JSON ou en XML. Elle n'est pas obligatoire au titre du règlement.

Un exemple CycloneDX

Voici un SBOM minimal pour une application qui utilise deux bibliothèques. Les noms et les versions sont fictifs.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "version": 1,
  "metadata": {
    "timestamp": "2026-10-30T09:00:00Z",
    "component": { "type": "application", "name": "gestion-stocks", "version": "4.2.0" }
  },
  "components": [
    {
      "type": "library", "name": "exemple-http", "version": "2.31.0",
      "purl": "pkg:pypi/exemple-http@2.31.0",
      "licenses": [{ "license": { "id": "Apache-2.0" } }]
    },
    {
      "type": "library", "name": "exemple-json", "version": "1.9.4",
      "purl": "pkg:npm/exemple-json@1.9.4",
      "licenses": [{ "license": { "id": "MIT" } }]
    }
  ]
}

Chaque composant porte un identifiant de paquet (purl), qui permet de le retrouver dans les bases de vulnérabilités.

Le produire avec des outils libres

Le plus simple : générer le SBOM à chaque construction du logiciel, dans l'intégration continue, et le garder avec la version qu'il décrit.

Ces cinq outils sont sous licence Apache 2.0.

Exploiter le SBOM, puis publier le VEX

Un SBOM que personne ne lit ne protège rien. Dans l'étude de l'ENISA publiée en 2026, 44 % des organisations décrivent un écart modéré entre produire et utiliser leurs SBOM, 23 % un écart important. Faites analyser chaque SBOM à chaque version, puis à intervalle fixe, et envoyez les alertes à une personne nommée.

Quand une faille d'un composant ne touche pas votre produit, un fichier VEX (« vulnerability exploitability exchange ») publie cette décision dans un format lisible par machine. Trois formats existent : le VEX de CycloneDX, le profil VEX de CSAF 2.0 et OpenVEX.