Générer un CBOM CycloneDX en CI

Un CBOM CycloneDX (cryptographic bill of materials, ou nomenclature cryptographique) est un document CycloneDX dont les composants décrivent des actifs cryptographiques : algorithmes, protocoles, certificats et matériel de clés. En produire un en intégration continue relève surtout de la plomberie : exécuter des détecteurs sur le code source, les dépendances, les images de conteneurs et les endpoints de test, fusionner les résultats en un seul document CycloneDX 1.6, le valider par rapport au schéma, puis le stocker et le comparer avec celui du build précédent. La difficulté consiste à rester honnête sur ce qu’un pipeline de build peut réellement voir. Pour le concept lui-même, commencez par notre introduction au CBOM.

Où se trouvent les actifs cryptographiques dans le modèle CycloneDX 1.6

CycloneDX 1.6 a introduit le type de composant cryptographic-asset. Chacun de ces composants porte un objet cryptoProperties, dont le champ assetType détermine le groupe de propriétés applicable. Il existe quatre types d’actifs.

Deux autres champs font le véritable travail d’inventaire. Le champ oid rattache un algorithme à son identifiant d’objet lorsque vous le connaissez. Et dans le tableau dependencies, le champ provides indique qu’un composant logiciel implémente un actif cryptographique. C’est ainsi qu’un CBOM répond à la question que pose réellement un auditeur : quelle application utilise cet algorithme, et où ?

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "serialNumber": "urn:uuid:4e1e1f2a-0000-0000-0000-000000000000",
  "version": 1,
  "metadata": {
    "timestamp": "2026-10-19T06:12:00Z",
    "component": {
      "type": "application",
      "bom-ref": "payments-api@1.42.0",
      "name": "payments-api",
      "version": "1.42.0"
    }
  },
  "components": [
    {
      "type": "cryptographic-asset",
      "bom-ref": "crypto/algorithm/ml-kem-768",
      "name": "ML-KEM-768",
      "cryptoProperties": {
        "assetType": "algorithm",
        "algorithmProperties": {
          "primitive": "kem",
          "parameterSetIdentifier": "768",
          "cryptoFunctions": ["keygen", "encapsulate", "decapsulate"],
          "nistQuantumSecurityLevel": 3
        }
      }
    },
    {
      "type": "cryptographic-asset",
      "bom-ref": "crypto/protocol/tls-1.3",
      "name": "TLS 1.3",
      "cryptoProperties": {
        "assetType": "protocol",
        "protocolProperties": {
          "type": "tls",
          "version": "1.3",
          "cipherSuites": [
            { "name": "TLS_AES_256_GCM_SHA384", "identifiers": ["0x13", "0x02"] }
          ],
          "cryptoRefArray": ["crypto/algorithm/ml-kem-768"]
        }
      }
    }
  ],
  "dependencies": [
    { "ref": "payments-api@1.42.0", "provides": ["crypto/protocol/tls-1.3"] }
  ]
}

ML-KEM est le mécanisme d’encapsulation de clé normalisé dans NIST FIPS 203 ; son jeu de paramètres 768 correspond à la catégorie de sécurité quantique NIST 3. C’est dans les composants de protocole qu’apparaissent les groupes d’échange de clés hybrides, par exemple X25519MLKEM768, dont le codepoint 0x11EC figure dans le registre IANA des paramètres TLS.

Détection statique ou comportement observé

Un job de CI voit un dépôt, un fichier de verrouillage et une image. Il ne voit pas un handshake négocié. Confondre les deux est la manière la plus courante de rendre un CBOM trompeur.

Consignez cette différence dans le document. Conservez les faits obtenus statiquement dans le composant lui-même, avec le chemin du fichier dans les occurrences de la section evidence du composant, et conservez les faits mesurés dans les protocolProperties et certificateProperties produits par un job de sondage. Renseignez toujours metadata.tools afin que le lecteur sache quel détecteur a produit quelle affirmation.

Les grandes lignes d’un pipeline

1. Déclarer le périmètre

Avant d’exécuter le moindre outil, décidez de ce que couvre un CBOM : un composant déployable, une version, un environnement. Un fichier unique décrivant douze services vieillit mal et ne se compare pas utilement.

2. Collecter en parallèle

1. Analyse du code source et des dépendances : un analyseur statique parcourt le dépôt et les fichiers de verrouillage, et émet des actifs de type algorithme avec leurs emplacements.
2. Analyse de l’image ou du système de fichiers : inspectez l’artefact construit à la recherche de bibliothèques cryptographiques, de bundles de certificats, de keystores et de fichiers de configuration.
3. Sondage des endpoints observés : sur l’environnement de préproduction uniquement, confirmez ce qui est réellement négocié.

# TLS: does the staging endpoint negotiate a hybrid group?
# requires OpenSSL 3.5 or later for the ML-KEM groups
openssl s_client -connect staging.example.com:443 \
  -groups X25519MLKEM768 </dev/null | grep "Negotiated TLS1.3 group"

# SSH: which key agreement algorithms does this client build support?
ssh -Q kex

# SSH: confirm the server accepts the post-quantum hybrid key agreement
ssh -o KexAlgorithms=mlkem768x25519-sha256 -o BatchMode=yes \
  git@staging.example.com true

L’algorithme mlkem768x25519-sha256 a été ajouté dans OpenSSH 9.9 et est devenu l’accord de clés par défaut dans OpenSSH 10.0, selon les notes de version d’OpenSSH. Sondez la préproduction, jamais la production, et conservez un repli classique tel que X25519 après le groupe hybride dans chaque configuration serveur que vous modifiez.

3. Fusionner, horodater et valider

Fusionnez les documents partiels en un seul, puis faites échouer le job si le résultat n’est pas conforme au schéma. La CLI CycloneDX fait les deux.

cyclonedx merge \
  --input-files static.cbom.json image.cbom.json observed.cbom.json \
  --output-file cbom.json

cyclonedx validate --input-file cbom.json --fail-on-errors

Renseignez metadata.timestamp, la version du composant et le SHA du commit. Un CBOM sans provenance n’est qu’une opinion.

Stocker et comparer le CBOM

Publiez le fichier comme artefact de build pour la traçabilité, et conservez une copie normalisée par composant dans un dépôt dédié ou un serveur de BOM, afin que l’historique puisse être interrogé. La normalisation compte davantage que le stockage : triez les composants, utilisez des valeurs bom-ref stables qui ne contiennent pas le numéro de build, et excluez l’horodatage de la comparaison. Sinon, chaque build ressemble à un changement.

# extract a stable, sorted view of the cryptographic assets
jq -S '[.components[]
       | select(.type == "cryptographic-asset")
       | {name, assetType: .cryptoProperties.assetType,
          primitive: .cryptoProperties.algorithmProperties.primitive}]
       | sort_by(.name)' cbom.json > current.view.json

diff -u previous.view.json current.view.json

Décidez ensuite de ce que signifie une différence. Voici des contrôles utiles, par gravité croissante : apparition d’un nouvel actif qu’aucun build précédent ne déclarait ; apparition d’un algorithme à clé publique vulnérable au quantique dans un composant qui n’en avait aucun ; apparition, où que ce soit, d’un groupe obsolète antérieur à la norme, tel qu’un groupe TLS Kyber en version brouillon ; disparition d’un groupe hybride d’un service qui en disposait. Commencez par avertir plutôt que par faire échouer le build, tant que le bruit des détecteurs n’est pas compris. Cette comparaison constitue la partie mesurable de l’agilité cryptographique : elle montre si votre surface cryptographique évolue volontairement ou par accident.

Des limites à consigner par écrit

• La couverture varie selon le langage et l’écosystème. Un détecteur qui lit bien un langage peut être aveugle dans un autre. Consignez ce qui n’a pas été analysé.
• Les résultats statiques sont des possibilités, pas des usages. Qu’une bibliothèque prenne en charge RSA ne signifie pas que RSA est utilisé. Ajoutez une note de confiance dans les propriétés du composant plutôt que de suggérer une certitude.
• La configuration résolue à l’exécution est invisible. Variables d’environnement, gestionnaires de secrets, service meshes et reverse proxies peuvent outrepasser tout ce que dit le dépôt.
• Les identifiants d’objet sont incomplets. Pour les algorithmes récents, le champ oid peut tout simplement ne pas être disponible ; laissez-le vide plutôt que de deviner.
• Doublons à la fusion. Deux détecteurs qui nomment différemment le même algorithme produisent deux composants, sauf si votre schéma de bom-ref est déterministe.
• Aucun modèle de gravité n’est intégré. CycloneDX décrit des actifs ; le jugement sur ce qui est vulnérable au quantique vous revient, ou provient d’une référence telle que nos pages d’algorithmes.

Ce qu’atteste un CBOM généré en CI

Plusieurs textes exigent un inventaire de la cryptographie utilisée. L’exigence 12.3.3 de PCI DSS v4.0.1 demande que les suites de chiffrement et les protocoles utilisés soient documentés et revus au moins tous les 12 mois, y compris leurs lieux d’utilisation et une stratégie documentée face à l’évolution anticipée des vulnérabilités cryptographiques ; elle est obligatoire depuis le 31 mars 2025 (bibliothèque documentaire du PCI SSC). DORA, via le règlement délégué (UE) 2024/1774 de la Commission, exige à l’article 6 une politique de chiffrement prévoyant la mise à jour ou le changement de la technologie cryptographique en fonction de l’évolution de la cryptanalyse, et à l’article 7 une gestion des clés sur tout leur cycle de vie ainsi qu’un registre des certificats pour les actifs TIC soutenant des fonctions critiques ou importantes (EUR-Lex). Pour les agences fédérales américaines, l’OMB M-26-15 demande un inventaire cryptographique automatisé et mis à jour en continu (M-26-15). La feuille de route de mise en œuvre coordonnée de l’UE (Coordinated Implementation Roadmap) v1.1 place un inventaire cryptographique parmi les premières étapes d’ici fin 2026, en tant qu’orientation coordonnée destinée aux États membres et non comme une réglementation contraignante pour les entreprises.

Notre interprétation, clairement présentée comme telle : aucun de ces textes ne cite CycloneDX, et un CBOM est un moyen pratique, parmi d’autres, de produire et de tenir un tel inventaire, pas un format imposé. Construisez ce fichier parce qu’il rend la prochaine décision de migration moins coûteuse, puis rattachez-le à l’obligation qui s’applique. Ceci est une information, pas un conseil juridique.

Étape suivante : confronter le CBOM à la réalité

Un CBOM généré en CI vous indique ce que contient votre build. Il ne peut pas vous dire ce que négocient vos serveurs. Comblez cet écart en testant les endpoints eux-mêmes : analysez votre domaine avec PQC Status pour voir les groupes hybrides ML-KEM, les versions de TLS et la chaîne de certificats réellement proposés à un client, puis réinjectez ces valeurs observées dans les protocolProperties et certificateProperties de votre prochain CBOM, afin que le document reflète à la fois le code et le comportement.