Exemples de SBOM : fichiers CycloneDX et SPDX expliqués

L'application de ces exemples

Les deux fichiers décrivent example-api 2.4.0, un service Node.js fictif avec une seule dépendance directe, express. Express dépend à son tour de accepts : les exemples montrent donc aussi une dépendance transitive. Une vraie SBOM d'application Express liste bien plus de composants, mais la structure est la même.

Exemple de SBOM CycloneDX

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
  "version": 1,
  "metadata": {
    "timestamp": "2026-10-30T09:00:00Z",
    "lifecycles": [{ "phase": "build" }],
    "tools": {
      "components": [
        { "type": "application", "name": "example-sbom-tool", "version": "1.0.0" }
      ]
    },
    "component": {
      "type": "application",
      "bom-ref": "example-api",
      "name": "example-api",
      "version": "2.4.0"
    }
  },
  "components": [
    {
      "type": "library",
      "bom-ref": "pkg:npm/[email protected]",
      "name": "express",
      "version": "4.21.2",
      "purl": "pkg:npm/[email protected]",
      "licenses": [{ "license": { "id": "MIT" } }]
    },
    {
      "type": "library",
      "bom-ref": "pkg:npm/[email protected]",
      "name": "accepts",
      "version": "1.3.8",
      "purl": "pkg:npm/[email protected]",
      "licenses": [{ "license": { "id": "MIT" } }]
    }
  ],
  "dependencies": [
    { "ref": "example-api", "dependsOn": ["pkg:npm/[email protected]"] },
    { "ref": "pkg:npm/[email protected]", "dependsOn": ["pkg:npm/[email protected]"] }
  ]
}

Champ	Ce qu'il vous apprend
`specVersion`	La version du format utilisée par le fichier, pour que les outils puissent l'analyser.
`serialNumber`, `version`	De quelle SBOM il s'agit, et de quelle révision.
`metadata.lifecycles`	Quand la SBOM a été produite. Ici, pendant le build.
`metadata.tools`	L'outil qui l'a produite. Deux outils peuvent rendre compte différemment d'un même commit.
`metadata.component`	Le produit décrit par la SBOM.
`purl`	La package URL, l'identifiant qui permet à un outil de rapprocher le composant des avis de sécurité.
`licenses`	La licence déclarée du composant.
`dependencies`	Qui entraîne quoi. C'est ce qui rend `accepts` visible en tant que dépendance transitive.

Exemple de SBOM SPDX

{
  "spdxVersion": "SPDX-2.3",
  "dataLicense": "CC0-1.0",
  "SPDXID": "SPDXRef-DOCUMENT",
  "name": "example-api-2.4.0",
  "documentNamespace": "https://example.com/spdx/example-api-2.4.0",
  "creationInfo": {
    "created": "2026-10-30T09:00:00Z",
    "creators": ["Tool: example-sbom-tool-1.0.0"]
  },
  "packages": [
    {
      "name": "example-api",
      "SPDXID": "SPDXRef-Package-example-api",
      "versionInfo": "2.4.0",
      "downloadLocation": "NOASSERTION"
    },
    {
      "name": "express",
      "SPDXID": "SPDXRef-Package-express",
      "versionInfo": "4.21.2",
      "downloadLocation": "NOASSERTION",
      "licenseDeclared": "MIT",
      "externalRefs": [
        {
          "referenceCategory": "PACKAGE-MANAGER",
          "referenceType": "purl",
          "referenceLocator": "pkg:npm/[email protected]"
        }
      ]
    },
    {
      "name": "accepts",
      "SPDXID": "SPDXRef-Package-accepts",
      "versionInfo": "1.3.8",
      "downloadLocation": "NOASSERTION",
      "licenseDeclared": "MIT",
      "externalRefs": [
        {
          "referenceCategory": "PACKAGE-MANAGER",
          "referenceType": "purl",
          "referenceLocator": "pkg:npm/[email protected]"
        }
      ]
    }
  ],
  "relationships": [
    {
      "spdxElementId": "SPDXRef-DOCUMENT",
      "relationshipType": "DESCRIBES",
      "relatedSpdxElement": "SPDXRef-Package-example-api"
    },
    {
      "spdxElementId": "SPDXRef-Package-example-api",
      "relationshipType": "DEPENDS_ON",
      "relatedSpdxElement": "SPDXRef-Package-express"
    },
    {
      "spdxElementId": "SPDXRef-Package-express",
      "relationshipType": "DEPENDS_ON",
      "relatedSpdxElement": "SPDXRef-Package-accepts"
    }
  ]
}

L'information est la même, organisée différemment. SPDX tient une liste packages et énonce chaque lien entre les éléments dans relationships. licenseDeclared correspond à ce que le paquet dit de lui-même, et downloadLocation peut valoir NOASSERTION lorsque l'outil ne la connaît pas. Pour savoir en quoi les deux formats diffèrent au-delà de la présentation, consultez CycloneDX vs SPDX.

À quoi ressemble une SBOM faible

Un fichier peut être valide et pourtant presque inutile. Surveillez ces signes :

Pas de relations de dépendance. Une liste à plat vous dit qu'un paquet est présent, pas ce qui l'a entraîné, alors que c'est ce qu'il vous faut pour corriger une dépendance transitive.
Pas de package URL. Sans identifiant tel qu'un purl, le rapprochement d'un composant avec les avis de sécurité se réduit à deviner à partir des noms.
Des licences manquantes. De nombreux champs laissés à NOASSERTION signifient que la SBOM ne peut pas répondre aux questions de licence.
Un nombre de composants étonnamment faible. Une poignée de composants pour une grande application signifie généralement que seules les dépendances directes y figurent, ou seulement ce qu'un lockfile a déclaré.
Rien sur le quand ni le comment. Sans outil ni contexte de génération, vous ne pouvez pas savoir ce que la SBOM couvre de manière fiable.
Le silence sur les lacunes. Une bonne SBOM dit ce qu'elle n'a pas pu voir. La plupart des fichiers s'arrêtent simplement, et le lecteur les suppose complets.

Comment vérifier votre propre SBOM

Validez le format. Passez-la dans un validateur de schéma pour son format et sa version, car un outil qui ne peut pas analyser le fichier ne peut pas l'utiliser.
Vérifiez les champs. Comparez-la aux 2026 Minimum Elements ou à la liste demandée par votre client.
Cherchez quelque chose que vous connaissez. Choisissez une dépendance transitive, un paquet de votre image de base et un outil de build, et regardez lesquels apparaissent.
Comparez deux sources. Générez une seconde SBOM avec une autre méthode et examinez la différence. Chaque composant supplémentaire dans un fichier est une question posée à l'autre.

Une SBOM générée au build par CRACI

CRACI exporte les mêmes formats. La différence tient à l'origine du contenu : CRACI enregistre ce que chaque job GitHub Actions a récupéré, si bien que chaque composant de la SBOM a réellement été récupéré par le build, et que les paquets restaurés depuis les caches CI sont signalés comme tels. Les GitHub Actions exécutées par le workflow apparaissent aussi comme composants, épinglées au commit utilisé. La SBOM de chaque job porte également un état de complétude : les lacunes sont indiquées au lieu de rester à découvrir. Consultez la génération de SBOM au build, ou le comparatif des outils SBOM.

Exemples de SBOM : questions fréquentes

À quoi ressemble une SBOM ?

C'est généralement un fichier JSON, parfois XML. Il commence par des données sur la SBOM elle-même, comme l'outil et l'horodatage, puis liste chaque composant avec son nom, sa version, son identifiant et sa licence, et décrit enfin comment les composants dépendent les uns des autres.

Une SBOM est-elle un fichier JSON ?

Généralement, car JSON est l'encodage le plus utilisé de CycloneDX comme de SPDX. Les deux formats ont aussi d'autres encodages, et SPDX dispose en plus d'une forme texte tag-value.

Qu'est-ce qu'un purl dans une SBOM ?

Un purl, ou package URL, est un identifiant standard de paquet, comme pkg:npm/[email protected]. Il nomme l'écosystème, le paquet et la version en une seule chaîne, ce qui permet aux outils de rapprocher le composant des données de vulnérabilité de manière fiable.

Combien de composants une SBOM doit-elle contenir ?

Il n'y a pas de nombre idéal, mais elle doit inclure les dépendances transitives, généralement bien plus nombreuses que les directes. Très peu de composants pour une grande application signifie généralement que l'outil n'en a vu qu'une partie.

Peut-on voir la SBOM d'un projet open source ?

Parfois. Certains projets publient des SBOM avec leurs releases, et GitHub peut en exporter une à partir du graphe de dépendances d'un dépôt. Cet export reflète ce que le dépôt déclare plutôt que ce qu'un build précis a utilisé.