Comment Générer un SBOM Conforme au CRA : Outils, Formats et Intégration CI/CD

Le CRA exige un Software Bill of Materials. 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.

Conseil : Commencez avec Syft ou Trivy pour la generation SBOM -- les deux supportent les sorties CycloneDX et SPDX et s'integrent facilement dans les pipelines CI/CD.

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 :

"identifier et documenter les vulnérabilités et les composants contenus dans le produit, notamment en établissant une nomenclature logicielle dans un format couramment utilisé et lisible par machine"

Points clés :

• Format lisible par machine : Pas un PDF, pas un tableur, des données structurées
• Au moins les dépendances de premier niveau : 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.

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 (norme ISO/IEC 5962:2021) 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.

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
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - 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 SBOM
        run: |
          syft dir:. -o cyclonedx-json > sbom.cdx.json

      - name: Uploader SBOM comme artefact
        uses: actions/upload-artifact@v4
        with:
          name: sbom
          path: sbom.cdx.json
          retention-days: 90

      # Optionnel : Upload vers CRA Evidence
      - name: Upload vers CRA Evidence
        if: github.event_name == 'release'
        env:
          CRA_EVIDENCE_TOKEN: ${{ secrets.CRA_EVIDENCE_TOKEN }}
        run: |
          curl -X POST https://app.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 }}"

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 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"]

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

Le CRA exige une rétention de 10 ans. Stockez les SBOM historiques :

• Dans votre dépôt d'artefacts
• Dans S3/stockage cloud avec politiques de cycle de vie
• Dans CRA Evidence pour un suivi de conformité intégré

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. Scannez les artefacts construits plutôt que le code source seul.

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 appropriément.

Liste de Contrôle d'Implémentation SBOM

LISTE DE CONTRÔLE D'IMPLÉMENTATION SBOM

SÉLECTION DU FORMAT :
[ ] CycloneDX 1.4+ ou SPDX 2.3+ choisi
[ ] Format JSON (lisible par machine)
[ ] Décision documentée

OUTILLAGE :
[ ] Outil principal sélectionné (Syft/Trivy/cdxgen)
[ ] Outil installé et testé localement
[ ] Sortie validée contre le schéma

INTÉGRATION CI/CD :
[ ] Génération SBOM ajoutée au pipeline de build
[ ] Artefacts stockés avec rétention appropriée
[ ] Génération déclenchée sur les releases

ASSURANCE QUALITÉ :
[ ] Tous les composants ont : nom, version, fournisseur
[ ] Valeurs de hash présentes (SHA-256+)
[ ] Information de licence incluse
[ ] Dépendances transitives capturées
[ ] Identifiants PURL utilisés

OPÉRATIONS :
[ ] SBOM versionné aux côtés des releases produit
[ ] SBOM historiques archivés (rétention 10 ans)
[ ] Processus documenté pour l'équipe

OPTIONNEL - INTÉGRATION CRA EVIDENCE :
[ ] Token API configuré
[ ] Upload automatisé sur release
[ ] Scoring qualité activé

Prochaines Étapes

Avec la génération SBOM automatisée, vous êtes prêt pour :

1. Scan de vulnérabilités : Connectez les SBOM aux bases de données de vulnérabilités
2. Conformité des licences : Analysez les obligations de licence
3. Intégration du dossier technique : Incluez les SBOM dans la documentation CRA
4. Préparation au reporting ENISA : Les SBOM permettent une identification rapide des vulnérabilités

CRA Evidence automatise tout ce workflow :

• Upload des SBOM via CLI ou CI/CD
• Scan automatique des vulnérabilités avec Trivy
• Scoring qualité TR-03183
• Export du dossier technique avec SBOM intégrés

Commencez à générer des SBOM conformes sur app.craevidence.com.

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 vulnerabilite a 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.