Générer un SBOM conforme au CRA : outils, formats, CI/CD

Le CRA exige un SBOM. Tous les articles concurrents vous le disent. Aucun ne vous montre comment en générer un.

Ce guide couvre les outils open source, la sélection des formats et l'intégration CI/CD, sans verrouillage fournisseur.

Résumé

• Le CRA exige des SBOM lisibles par machine couvrant « au moins les dépendances de niveau supérieur »
• Formats recommandés : CycloneDX 1.4+ ou SPDX 2.3+ (selon BSI TR-03183)
• Outils open source : Syft (images/systèmes de fichiers), Trivy (conteneurs), cdxgen (code source)
• Intégrez la génération SBOM dans CI/CD pour des mises à jour automatiques
• La qualité compte : les champs minimum incluent nom du package, version, fournisseur, hash, licence

Ce que le CRA exige réellement

Commençons par ce que dit le règlement. L'Annexe I, partie II du CRA exige des fabricants de :

« recensent et documentent les vulnérabilités et les composants des produits, notamment par l'établissement d'une nomenclature des logiciels dans un format couramment utilisé et lisible par machine couvrant au moins les dépendances de niveau supérieur des produits »

Points clés :

• Format lisible par machine : pas un PDF, pas un tableur, des données structurées
• Au moins les dépendances de niveau supérieur : le périmètre minimum, bien que plus soit mieux
• Pas obligatoirement public : fourni aux autorités sur demande
• Doit être mis à jour : à chaque version, correctif ou changement de composant

Le CRA n'impose pas de format spécifique, mais les efforts de normalisation pointent clairement vers CycloneDX et SPDX.

Le SBOM fait partie de la documentation technique CRA au titre de l'Annexe VII. Les fabricants doivent établir cette documentation avant la mise sur le marché du produit et la tenir à la disposition des autorités de surveillance du marché pendant au moins 10 ans après cette date, ou pendant la durée d'assistance, la période la plus longue étant retenue (article 13(13)). Un SBOM stocké localement sans lien avec une version de produit spécifique ne satisfait pas à cette exigence. Il doit être accessible, versionné et lié à la version du produit qu'il décrit.

Sélection du format : CycloneDX vs SPDX

Deux formats dominent le paysage SBOM. Les deux sont acceptables pour la conformité CRA.

CycloneDX

Origine : projet OWASP, orienté sécurité Version actuelle : 1.6 (1.4+ recommandé pour le CRA) Idéal pour : sécurité et gestion des vulnérabilités

Points forts :

• Support natif VEX (Vulnerability Exploitability eXchange)
• Conçu pour les cas d'usage sécurité
• Spécification plus légère, plus facile à implémenter
• Fort écosystème d'outils
• Liaison directe CVE/vulnérabilités

Exemple JSON :

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "version": 1,
  "components": [
    {
      "type": "library",
      "name": "lodash",
      "version": "4.17.21",
      "purl": "pkg:npm/lodash@4.17.21",
      "hashes": [
        {
          "alg": "SHA-256",
          "content": "cc6d..."
        }
      ],
      "licenses": [
        {
          "license": {
            "id": "MIT"
          }
        }
      ]
    }
  ]
}

SPDX

Origine : Linux Foundation, orienté conformité des licences Version actuelle : 2.3. ISO/IEC 5962:2021 a normalisé SPDX 2.2.1 Idéal pour : conformité des licences et revue juridique

Points forts :

• Norme internationale ISO
• Syntaxe complète d'expression de licence
• Solide dans les contextes de conformité open source
• Plus long historique
• Meilleur pour les scénarios de licence complexes

Exemple JSON :

{
  "spdxVersion": "SPDX-2.3",
  "dataLicense": "CC0-1.0",
  "SPDXID": "SPDXRef-DOCUMENT",
  "name": "my-application",
  "packages": [
    {
      "SPDXID": "SPDXRef-Package-lodash",
      "name": "lodash",
      "versionInfo": "4.17.21",
      "downloadLocation": "https://registry.npmjs.org/lodash/-/lodash-4.17.21.tgz",
      "licenseConcluded": "MIT",
      "checksums": [
        {
          "algorithm": "SHA256",
          "checksumValue": "cc6d..."
        }
      ]
    }
  ]
}

Lequel choisir ?

Pour la conformité CRA, les deux formats fonctionnent. Choisissez-en un et soyez cohérent.

Outils open source de génération SBOM

Pas de verrouillage fournisseur nécessaire. Ces outils sont gratuits, open source et prêts pour la production.

Syft (Anchore)

Idéal pour : images de conteneurs, systèmes de fichiers, archives Licence : Apache 2.0 Formats de sortie : CycloneDX, SPDX, Syft JSON

Installation :

# Linux/macOS
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin

# Homebrew
brew install syft

# Docker
docker pull anchore/syft

Exemples d'utilisation :

# Scanner une image de conteneur
syft alpine:latest -o cyclonedx-json > sbom.cdx.json

# Scanner un répertoire
syft dir:/chemin/vers/projet -o cyclonedx-json > sbom.cdx.json

# Scanner une archive
syft /chemin/vers/archive.tar.gz -o spdx-json > sbom.spdx.json

# Scanner avec catalogueurs spécifiques (ex. Python uniquement)
syft dir:. -o cyclonedx-json --select-catalogers python

Écosystèmes supportés : Python, Node.js, Ruby, Java, Go, Rust, PHP, .NET, et plus.

Trivy (Aqua Security)

Idéal pour : images de conteneurs avec contexte de vulnérabilité intégré Licence : Apache 2.0 Formats de sortie : CycloneDX, SPDX, plus rapports de vulnérabilités

Installation :

# Linux (Debian/Ubuntu)
sudo apt-get install trivy

# macOS
brew install trivy

# Docker
docker pull aquasec/trivy

Exemples d'utilisation :

# Générer SBOM depuis image conteneur
trivy image --format cyclonedx --output sbom.cdx.json alpine:latest

# Générer SBOM depuis système de fichiers
trivy fs --format cyclonedx --output sbom.cdx.json /chemin/vers/projet

# Générer SBOM avec info vulnérabilités
trivy image --format cyclonedx --output sbom.cdx.json \
  --scanners vuln nginx:latest

Avantage : Trivy peut générer des SBOM et scanner les vulnérabilités en une seule passe.

Cdxgen (CycloneDX)

Idéal pour : analyse de code source dans de nombreux langages Licence : Apache 2.0 Format de sortie : CycloneDX

Installation :

# npm (nécessite Node.js)
npm install -g @cyclonedx/cdxgen

# Docker
docker pull ghcr.io/cyclonedx/cdxgen

Exemples d'utilisation :

# Scanner le répertoire courant
cdxgen -o sbom.json

# Scanner un type de projet spécifique
cdxgen -t python -o sbom.json

# Scanner avec résolution de dépendances profonde
cdxgen --deep -o sbom.json

# Scanner un répertoire spécifique
cdxgen -o sbom.json /chemin/vers/projet

Langages supportés : JavaScript, Python, Java, Go, Rust, PHP, Ruby, .NET, C/C++, et plus.

Comparaison des outils

Recommandation : commencez avec Syft pour la plupart des cas. Ajoutez Trivy si vous avez besoin de scan de vulnérabilités intégré. Utilisez cdxgen pour les projets de code source complexes.

Micrologiciels et appareils embarqués

Les outils ci-dessus fonctionnent bien pour les conteneurs et les gestionnaires de packages. Pour les micrologiciels et appareils embarqués (cible principale du CRA), l'approche est différente.

Les images de micrologiciel sont des blobs binaires, pas des registres de packages. La première étape standard consiste à extraire le système de fichiers :

# Extraire le système de fichiers de l'image micrologiciel
binwalk -Me firmware.bin

# Lancer Syft sur le système de fichiers extrait
syft dir:_firmware.bin.extracted/squashfs-root -o cyclonedx-json > sbom.cdx.json

Utilisez binwalk -Me (extraction récursive) plutôt que -e pour les images imbriquées ou compressées. La couverture sera inférieure à celle des images de conteneurs. Les binaires dépouillés perdent les informations de symboles, et Syft peut ne pas identifier tous les composants.

Pour l'analyse au niveau binaire des composants compilés, BLint, cve-bin-tool ou EMBA permettent une inspection plus approfondie. Les SDK propriétaires et les bibliothèques closed-source intégrés dans les micrologiciels nécessitent généralement des entrées SBOM manuelles. Documentez le fournisseur, la version et l'URL source.

Intégration CI/CD

La génération manuelle de SBOM ne passe pas à l'échelle. Intégrez-la dans votre pipeline de build.

GitHub Actions

name: Génération SBOM

on:
  push:
    branches: [main]
  release:
    types: [published]

jobs:
  sbom:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write   # requis pour la signature sans clé Cosign
    steps:
      - name: Checkout du code
        uses: actions/checkout@v4

      - name: Construire l'image conteneur
        run: |
          docker build -t myapp:${{ github.sha }} .

      - name: Installer Syft
        run: |
          curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin

      - name: Générer le SBOM depuis l'image construite
        run: |
          syft myapp:${{ github.sha }} -o cyclonedx-json > sbom.cdx.json

      - name: Installer Cosign
        uses: sigstore/cosign-installer@v3

      - name: Signer le SBOM (sans clé)
        run: |
          cosign sign-blob sbom.cdx.json --bundle sbom.cdx.json.sigstore.json --yes

      - name: Téléverser le SBOM et la signature comme artefacts
        uses: actions/upload-artifact@v4
        with:
          name: sbom
          path: |
            sbom.cdx.json
            sbom.cdx.json.sigstore.json
          retention-days: 90

      # Optionnel : téléverser vers CRA Evidence pour la conservation à long terme
      - name: Téléverser vers CRA Evidence
        if: github.event_name == 'release'
        env:
          CRA_EVIDENCE_TOKEN: ${{ secrets.CRA_EVIDENCE_TOKEN }}
        run: |
          curl -X POST https://api.craevidence.com/api/v1/ci/sbom \
            -H "Authorization: Bearer $CRA_EVIDENCE_TOKEN" \
            -F "file=@sbom.cdx.json" \
            -F "product_id=${{ vars.PRODUCT_ID }}" \
            -F "version=${{ github.ref_name }}"

Note : La rétention des artefacts CI (retention-days: 90) est prévue pour la commodité des développeurs, pas pour la conformité. La rétention de 10 ans exigée par le CRA nécessite un stockage dédié à long terme sur chaque version. Voir la section Rétention ci-dessous.

GitLab CI

generate-sbom:
  stage: build
  image: anchore/syft:latest
  script:
    - syft dir:. -o cyclonedx-json > sbom.cdx.json
  artifacts:
    paths:
      - sbom.cdx.json
    expire_in: 90 days
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
    - if: $CI_COMMIT_TAG

Jenkins

pipeline {
    agent any

    stages {
        stage('Générer SBOM') {
            steps {
                sh '''
                    curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b .
                    ./syft dir:. -o cyclonedx-json > sbom.cdx.json
                '''
            }
        }

        stage('Archiver SBOM') {
            steps {
                archiveArtifacts artifacts: 'sbom.cdx.json', fingerprint: true
            }
        }
    }
}

Intégration build Docker

Générer le SBOM pendant le build Docker :

# Build multi-étapes avec génération SBOM
FROM node:20 AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# Générer SBOM dans l'étape de build
FROM anchore/syft:latest AS sbom
COPY --from=builder /app /app
RUN syft dir:/app -o cyclonedx-json > /sbom.cdx.json

# Image finale
FROM node:20-slim
COPY --from=builder /app/dist /app
COPY --from=sbom /sbom.cdx.json /app/sbom.cdx.json
CMD ["node", "/app/index.js"]

Signature du SBOM

Le CRA n'impose pas la signature du SBOM, mais signer établit que le SBOM n'a pas été modifié depuis sa génération. Les équipes d'achats en entreprise et les organismes notifiés attendent de plus en plus une signature vérifiable aux côtés du fichier SBOM.

Cosign (partie du projet Sigstore) est l'outil standard :

# Installer Cosign
brew install cosign

# Signer un fichier SBOM. Produit un bundle contenant la signature et le certificat
cosign sign-blob sbom.cdx.json --bundle sbom.cdx.json.sigstore.json

# Vérifier ultérieurement
cosign verify-blob sbom.cdx.json --bundle sbom.cdx.json.sigstore.json \
  --certificate-identity <votre-identité> \
  --certificate-oidc-issuer <votre-émetteur>

Conservez sbom.cdx.json et sbom.cdx.json.sigstore.json ensemble. Le bundle contient la signature, le certificat de signature et l'entrée du journal de transparence Rekor. Toute personne disposant du bundle peut vérifier le SBOM sans vous contacter.

Pour CI/CD, Cosign prend en charge la signature sans clé en utilisant l'identité OIDC du pipeline (GitHub Actions, GitLab CI). Aucune clé à gérer. L'exemple GitHub Actions ci-dessus inclut déjà ceci : le job nécessite la permission id-token: write, et sign-blob prend --yes pour s'exécuter sans invite interactive. Cosign 2.0 et ultérieur font de la signature sans clé le mode par défaut, de sorte que l'ancien indicateur COSIGN_EXPERIMENTAL n'est plus nécessaire.

Surveillance continue

Un SBOM signé et stocké n'est pas l'étape finale. De nouvelles vulnérabilités sont divulguées pour des composants qui étaient propres au moment de la version. Le SBOM stocké doit être ré-analysé régulièrement pour que ces CVE remontent.

Grype lit un SBOM existant directement, de sorte que la ré-analyse n'a pas besoin de l'environnement de build d'origine :

name: SBOM Rescan

on:
  schedule:
    - cron: "0 6 * * 1"  # Hebdomadaire, lundi 06:00 UTC

jobs:
  rescan:
    runs-on: ubuntu-latest
    steps:
      - name: Récupérer le SBOM stocké
        env:
          SBOM_URL: ${{ vars.SBOM_URL }}
        run: |
          curl -sSfL -o sbom.cdx.json "$SBOM_URL"

      - name: Installer Grype
        run: |
          curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin

      - name: Scanner le SBOM pour détecter les nouvelles CVE
        run: |
          grype sbom:./sbom.cdx.json

CRA Evidence exécute automatiquement cette ré-analyse pour chaque SBOM téléversé et vous alerte quand une nouvelle CVE correspond à un composant, couvrant ainsi le même besoin sans job planifié.

Qualité SBOM : respecter TR-03183

La directive technique allemande BSI TR-03183 étend les éléments minimum NTIA. Bien que non légalement requis dans toute l'UE, suivre TR-03183 assure des SBOM de haute qualité.

Champs requis

Validation de la qualité SBOM

Utilisez ces outils pour vérifier votre SBOM :

# Valider le format CycloneDX
npm install -g @cyclonedx/cyclonedx-cli
cyclonedx validate --input-file sbom.cdx.json

# Vérifier les champs minimum avec jq
jq '.components[] | select(.version == null or .purl == null)' sbom.cdx.json

# Compter les composants avec hashes
jq '[.components[] | select(.hashes != null)] | length' sbom.cdx.json

Améliorer la qualité SBOM

Si votre SBOM manque de données :

1. Utilisez les fichiers de verrouillage : package-lock.json, Pipfile.lock, go.sum contiennent plus de métadonnées
2. Scannez les artefacts construits : plus complet que les scans du code source seul
3. Combinez les outils : différents outils trouvent différents composants
4. Ajoutez des entrées manuelles : pour les composants commerciaux ou internes

Maintenir les SBOM à jour

Un SBOM est un instantané. Il doit être mis à jour pour rester utile.

Quand regénérer

• Chaque version (majeure, mineure, correctif)
• Après mises à jour des dépendances
• Après correctifs de sécurité
• Quand la configuration de build change

Stratégie de versionnement

produit-v1.0.0-sbom.cdx.json
produit-v1.0.1-sbom.cdx.json
produit-v1.1.0-sbom.cdx.json

Ou utilisez des horodatages :

produit-sbom-2026-01-15T10-30-00Z.cdx.json

Rétention

La rétention des artefacts CI (90 jours dans les exemples ci-dessus) est prévue pour la commodité des développeurs, pas pour la conformité. L'obligation de 10 ans nécessite un stockage dédié à long terme. CRA Evidence est conçu pour cela : stockage SBOM versionné avec ré-analyse de vulnérabilités et export du dossier technique, lié à chaque version de produit.

Si vous préférez l'héberger vous-même, tout grand stockage objet fonctionne dès que vous activez les bons contrôles :

Une politique de cycle de vie seule ne suffit pas. Le stockage doit aussi prendre en charge le versionnement, les contrôles d'accès et, idéalement, l'immuabilité pour satisfaire aux exigences d'audit.

Pièges courants

Génération SBOM ponctuelle

Problème : créer un SBOM une fois et ne jamais le mettre à jour.

Solution : automatisez la génération SBOM dans CI/CD. Chaque build devrait produire un SBOM frais.

Dépendances transitives manquantes

Problème : le SBOM ne liste que les dépendances directes, manquant les packages imbriqués.

Solution : utilisez les fichiers de verrouillage, scannez les artefacts construits, activez les options de scan profond.

Mauvaise version de format

Problème : utiliser CycloneDX 1.3 quand TR-03183 recommande 1.4+.

Solution : vérifiez la version de sortie de votre outil. Mettez à jour les outils régulièrement.

Pas de valeurs de hash

Problème : les composants sans hashes cryptographiques ne peuvent pas être vérifiés.

Solution : assurez-vous que votre outil inclut les hashes. Syft et Trivy ajoutent des hashes SHA-256 quand ils peuvent lire les fichiers des composants.

Création manuelle

Problème : créer des SBOM à la main est sujet aux erreurs et non durable.

Solution : toujours automatiser. Entrées manuelles uniquement pour les composants que les outils ne peuvent pas détecter.

Ignorer les composants internes

Problème : ne documenter que les dépendances open source, pas le code propriétaire.

Solution : les composants internes ont aussi besoin de documentation. Ajoutez-les manuellement ou configurez les outils de façon adaptée.

Liste de contrôle d'implémentation SBOM

Exigences : comprenez ce que le CRA exige pour les SBOM dans notre guide des exigences SBOM.

Qualité : validez votre SBOM contre le standard BSI TR-03183.

VEX : ajoutez du contexte de vulnérabilité à votre SBOM avec les documents VEX.

Cet article est fourni à titre informatif uniquement et ne constitue pas un conseil juridique. Pour des conseils de conformité spécifiques, consultez un conseiller juridique qualifié familier avec les réglementations produit de l'UE.