Le SBOM, en clair

Ce que c'est, pourquoi c'est devenu une exigence réglementaire, et à quoi ressemble vraiment le fichier. Aucun prérequis technique.

C'est quoi un SBOM, en clair ?

Pensez à l'étiquette d'ingrédients sur une boîte de raviolis : tout ce qu'il y a dedans, dans l'ordre, avec les quantités. Un SBOM (Software Bill of Materials), c'est exactement ça, mais pour un logiciel.

étiquette

Raviolis bœuf · 400 g

Farine de blé38 %
Bœuf21 %
Œufs8 %
Sel1,2 %
Conservateur E2500,01 %

Si demain le E250 est interdit, on retire toutes les boîtes qui en contiennent.

↔

même principe

SBOM

checkout-service@2.4.1

express4.18.2
lodash4.17.21
react18.2.0
axios1.6.7
log4js6.4.0

Si une CVE tombe sur log4js 6.4.0, on liste toutes les applis qui en dépendent.

Un logiciel moderne, c'est une poignée de fichiers écrits chez vous et des centaines de librairies open source écrites par des inconnus. Sans SBOM, quand une faille tombe sur l'une d'elles, personne ne sait quelles applications sont touchées.

Pourquoi tout le monde s'y met maintenant

Décembre 2021. Une mini-librairie de logs appelée log4j se révèle vulnérable. Elle est utilisée (sans que personne le sache précisément) par des millions d'applications dans le monde : banques, hôpitaux, Apple, Tesla, Minecraft. La panique n'a pas duré à cause de la faille en elle-même, mais parce que personne ne savait où elle se cachait.

Cet incident (Log4Shell) a mis le SBOM à l'agenda réglementaire. Depuis :

Executive Order 14028 (US, 2021) : SBOM obligatoire pour les fournisseurs fédéraux.
Cyber Resilience Act (UE, 2024) : SBOM exigé pour tout produit avec du logiciel vendu en Europe, applicable au 11.12.2027.
Amendes jusqu'à 15 M€ ou 2,5 % du chiffre d'affaires mondial pour non-conformité.

La confusion la plus répandue

Le 11 septembre 2026 revient partout comme « l'échéance SBOM ». C'est faux : cette date est celle du signalement des vulnérabilités activement exploitées (art. 14). L'exigence de documentation technique, SBOM compris, est applicable au 11 décembre 2027, annexe I, partie II, point 1. Deux obligations distinctes, deux dates distinctes.

À quoi ressemble un SBOM, vraiment

Un fichier JSON au format standard CycloneDX 1.5 (porté par OWASP). C'est conçu pour être lu par les machines : les outils de scan CVE, les auditeurs CRA, votre futur acquéreur.

sbom.cdx.json

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "serialNumber": "urn:uuid:3e8a7c4f-9b1d-4e2a-...",
  "metadata": {
    "timestamp": "2026-05-28T14:32:00Z",
    "component": {
      "name": "checkout-service",
      "version": "2.4.1"
    }
  },
  "components": [
    {
      "bom-ref": "pkg:npm/express@4.18.2",
      "type": "library",
      "name": "express",
      "version": "4.18.2",
      "purl": "pkg:npm/express@4.18.2",
      "licenses": [{ "license": { "id": "MIT" } }],
      "hashes": [{ "alg": "SHA-512", "content": "wYn7g5Y3..." }]
    }
  ]
}

Pour chaque dépendance :

Nom + version exacte
Pas une plage. La version résolue, celle qui tourne vraiment.
Package URL (purl)
Identifiant universel : c'est lui qui permet le croisement avec les bases de vulnérabilités.
Licence déclarée
MIT, Apache-2.0, GPL… ce qu'un acquéreur regarde en premier.
Hash d'intégrité
Pour prouver que la dépendance livrée est bien celle déclarée.

Le vôtre, en trente secondes

Déposez un lockfile (npm, pnpm, yarn) ou un SBOM CycloneDX existant. Un compte gratuit suffit, et le fichier n'est pas conservé.

Générer un SBOM Ce qu'euvex fournit