CycloneDX

Identité

Format créé au sein de l’OWASP, normalisé sous la référence ECMA-424. Sérialisations JSON (recommandée), XML et Protobuf.

Conçu par une communauté sécurité, pour être produit et consommé par des machines dans des chaînes automatisées.

Structure du document

Section	Contenu
metadata	Horodatage, outil ayant produit le document, auteur, composant décrit (le produit lui-même), fournisseur, licences du produit
components	La liste des composants : type, nom, version, éditeur, identifiants (purl, cpe), empreintes, licences, description
dependencies	Le graphe : quel composant dépend de quel autre. C’est cette section qui distingue direct et transitif
services	Services externes appelés — utile pour les architectures distribuées
compositions	Déclaration de complétude : cet inventaire est-il complet, incomplet, ou de complétude inconnue
vulnerabilities	Vulnérabilités connues affectant les composants, avec source, score, état
annotations	Assertions signées portant sur tout ou partie du document
formulation	Comment l’artefact a été produit : chaîne de construction, étapes, environnement

La section compositions est sous-utilisée et pourtant décisive pour la conformité : elle permet de déclarer explicitement qu’un inventaire ne couvre que les dépendances de premier niveau, plutôt que de laisser croire à une complétude qui n’existe pas.

Les extensions

CycloneDX ne se limite pas au logiciel :

Extension	Objet
SaaSBOM	Services et interfaces d’une architecture distribuée
HBOM	Nomenclature matérielle
ML-BOM	Modèles d’apprentissage automatique, jeux de données, cartes de modèle
CBOM	Inventaire cryptographique — algorithmes, tailles de clés, protocoles
OBOM	Configuration d’exploitation
VDR / VEX	Rapport de vulnérabilités et assertions d’exploitabilité

Le CBOM mérite une attention particulière : il est l’outil naturel pour préparer la migration post-quantique, sujet qui rejoindra le CRA par la voie de l’état de l’art attendu par l’annexe I.

Exemple commenté

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
  "version": 1,
  "metadata": {
    "timestamp": "2026-08-19T09:12:04Z",
    "tools": { "components": [ { "type": "application", "name": "syft", "version": "1.x" } ] },
    "component": {
      "type": "application",
      "bom-ref": "pkg:generic/acme-gateway@4.2.1",
      "name": "acme-gateway",
      "version": "4.2.1",
      "licenses": [ { "license": { "id": "Apache-2.0" } } ]
    }
  },
  "components": [
    {
      "type": "library",
      "bom-ref": "pkg:maven/org.example/http-client@5.3.1",
      "name": "http-client",
      "group": "org.example",
      "version": "5.3.1",
      "purl": "pkg:maven/org.example/http-client@5.3.1",
      "licenses": [ { "license": { "id": "MIT" } } ],
      "hashes": [ { "alg": "SHA-256", "content": "9f2c…" } ]
    }
  ],
  "dependencies": [
    {
      "ref": "pkg:generic/acme-gateway@4.2.1",
      "dependsOn": [ "pkg:maven/org.example/http-client@5.3.1" ]
    }
  ],
  "compositions": [
    { "aggregate": "complete", "assemblies": [ "pkg:generic/acme-gateway@4.2.1" ] }
  ]
}

Points d’attention sur cet exemple :

• bom-ref est la clé interne qui permet de relier composants et dépendances ; elle doit être stable d’une construction à l’autre pour que les comparaisons soient utiles ;
• purl est l’identifiant qui rend la corrélation fiable — voir Identifiants ;
• hashes lie l’inventaire à l’artefact réel : sans empreinte, rien ne prouve que ce SBOM décrit bien le binaire livré ;
• compositions.aggregate déclare la complétude et engage le producteur.

Pourquoi vous en faites votre format pivot

Trois raisons : la prise en charge native du VEX, donc la capacité à documenter les décisions de ne pas corriger dans le même écosystème ; la richesse des métadonnées de construction, utile pour la traçabilité exigée par l’annexe VII ; et l’ampleur de l’outillage disponible en CI/CD.