Qu'est-ce qu'un SBOM ? Software Bill of Materials

Un SBOM (Software Bill of Materials) est un inventaire structuré et lisible par machine de tous les composants logiciels qui composent une application : dépendances directes et transitives, versions exactes, hashes cryptographiques, licences, fournisseurs, identifiants uniques Package URL (PURL). C'est l'équivalent d'une nomenclature industrielle appliquée au logiciel. Le SBOM est devenu une exigence réglementaire structurante depuis 2021-2024 sous l'impulsion conjointe de l'Executive Order 14028 (Biden, 12 mai 2021), du Cyber Resilience Act UE (règlement UE 2024/2847, entré en vigueur 11 décembre 2024, applicable principales obligations 11 décembre 2027), de NIS 2 (directive UE 2022/2555, transposée octobre 2024), de DORA (règlement UE 2022/2554, applicable janvier 2025). Trois crises supply chain ont démocratisé le SBOM : SolarWinds SUNBURST (décembre 2020), Log4Shell (CVE-2021-44228, décembre 2021), xz-utils backdoor (CVE-2024-3094, mars 2024). Deux standards dominants en 2026 : SPDX (Linux Foundation, ISO/IEC 5962:2021, version 3.0 sortie 2024, orienté compliance) et CycloneDX (OWASP, v1.6 actuelle 2024, orienté AppSec). Les outils de génération leaders : Syft (Anchore, open-source, 30+ écosystèmes), Trivy (Aqua), CycloneDX GitHub Action, Microsoft SBOM Tool. L'apport principal du SBOM : transformer une question supply chain de 3-7 jours en une question de 5 minutes grâce à la visibilité préalable. Cet article détaille la définition du SBOM, son contexte réglementaire, les 3 standards, le contenu minimum selon NTIA 2021, la stack de génération 2026, les cas d'usage incident response, l'intégration en pipeline DevSecOps et notre bilan factuel.

1. Définition et rôle fondamental du SBOM

Définition opérationnelle : un SBOM est une nomenclature structurée machine-readable listant tous les composants logiciels d'une application, avec suffisamment d'informations pour identifier, auditer et corriger les composants vulnérables ou non conformes.

Fonctions principales

• Visibilité supply chain : savoir exactement ce qu'on utilise, incluant les dépendances transitives (dépendances des dépendances).
• Gestion des vulnérabilités : mapping automatique des composants aux CVE publiées, alertes précoces.
• Conformité licences : identifier les licences incompatibles (GPL vs propriétaire), éviter risques légaux.
• Incident response supply chain : répondre à « est-ce qu'on utilise X en version Y ? » en secondes plutôt qu'en jours.
• Due diligence M&A : évaluation rapide de la qualité supply chain d'un actif.
• Conformité réglementaire : EO 14028, Cyber Resilience Act UE, NIS 2, DORA.

2. Contexte réglementaire et historique

Trois crises supply chain fondatrices

1. SolarWinds SUNBURST (décembre 2020) : attaque supply chain sur le logiciel SolarWinds Orion, backdoor signée propagée à 18 000 organisations dont agences fédérales US. Révèle la nécessité de maîtrise supply chain logicielle.
2. Log4Shell (CVE-2021-44228, décembre 2021) : RCE critique dans Log4j 2.x (versions 2.0 à 2.14.1, et 2.15.0 partiellement), CVSS 10.0. Des milliers d'organisations incapables d'identifier rapidement leur exposition.
3. xz-utils backdoor (CVE-2024-3094, mars 2024) : backdoor sophistiquée introduite dans liblzma par un contributeur malveillant de long terme (Jia Tan), affectant OpenSSH. Découverte par Andres Freund (Microsoft) par chance avant diffusion massive. Rappelle la fragilité de la supply chain open-source.

Réponse réglementaire

Impact Cyber Resilience Act UE : changement de paradigme majeur. Tout produit avec éléments numériques vendu en UE (du thermostat connecté au logiciel d'entreprise) devra à partir de décembre 2027 maintenir un SBOM, corriger les vulnérabilités pendant toute la durée de support (minimum 5 ans), notifier ENISA sous 24 heures pour les vulnérabilités activement exploitées. Amendes pouvant atteindre 15 millions d'euros ou 2,5 % du CA mondial.

3. Les trois standards SBOM en 2026

SPDX vs CycloneDX — choix pragmatique 2026

• SPDX : privilégier pour compliance et interopérabilité large avec outils legacy, audits ISO, procurement grand compte. ISO/IEC 5962:2021 donne un poids réglementaire fort.
• CycloneDX : privilégier pour DevSecOps pipelines, intégration avec outils modernes (OWASP Dependency-Track, Snyk, Trivy), métadonnées sécurité riches (CWE, vulnérabilités, services, applications IA).

Best practice : générer les deux formats simultanément. Syft et Trivy supportent les deux en sortie via un seul scan.

4. Le contenu minimum d'un SBOM selon NTIA 2021

La NTIA (National Telecommunications and Information Administration) US a publié en juillet 2021 les Minimum Elements For a Software Bill of Materials — référentiel de facto pour le contenu minimum d'un SBOM conforme à l'EO 14028.

Extensions modernes recommandées (CycloneDX et SPDX 3.0)

• Hashes cryptographiques : SHA-256 minimum, idéalement SHA-512, pour attester intégrité.
• Licences SPDX : license identifier standardisé (MIT, Apache-2.0, GPL-3.0, etc.).
• Vulnérabilités connues : CVE associés avec score CVSS.
• Score EPSS (Exploit Prediction Scoring System) : probabilité d'exploitation dans les 30 jours.
• Services utilisés (CycloneDX 1.5+) : APIs et services externes dont dépend l'application.
• Composants IA (CycloneDX 1.6, 2024) : modèles ML utilisés, datasets d'entraînement, providers LLM.

5. Exemple de SBOM CycloneDX et commandes de génération

Exemple concret d'un SBOM CycloneDX simplifié pour une application Node.js, exploitable en portfolio GitHub public :

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "serialNumber": "urn:uuid:12345678-1234-5678-1234-567812345678",
  "version": 1,
  "metadata": {
    "timestamp": "2026-04-24T09:00:00Z",
    "tools": [
      {
        "vendor": "Anchore",
        "name": "Syft",
        "version": "1.22.0"
      }
    ],
    "component": {
      "type": "application",
      "bom-ref": "pkg:npm/myapp@1.0.0",
      "name": "myapp",
      "version": "1.0.0",
      "purl": "pkg:npm/myapp@1.0.0"
    }
  },
  "components": [
    {
      "type": "library",
      "bom-ref": "pkg:npm/axios@1.6.5",
      "name": "axios",
      "version": "1.6.5",
      "purl": "pkg:npm/axios@1.6.5",
      "hashes": [
        {
          "alg": "SHA-256",
          "content": "8e6f2e1c0a3b4d5f6789abcdef0123456789abcdef0123456789abcdef012345"
        }
      ],
      "licenses": [
        {
          "license": {
            "id": "MIT"
          }
        }
      ],
      "supplier": {
        "name": "axios contributors",
        "url": ["https://github.com/axios/axios"]
      }
    },
    {
      "type": "library",
      "bom-ref": "pkg:npm/express@4.18.2",
      "name": "express",
      "version": "4.18.2",
      "purl": "pkg:npm/express@4.18.2",
      "hashes": [
        {
          "alg": "SHA-256",
          "content": "9876543210fedcba9876543210fedcba9876543210fedcba9876543210fedcba"
        }
      ],
      "licenses": [
        {
          "license": {
            "id": "MIT"
          }
        }
      ]
    },
    {
      "type": "library",
      "bom-ref": "pkg:npm/jsonwebtoken@9.0.2",
      "name": "jsonwebtoken",
      "version": "9.0.2",
      "purl": "pkg:npm/jsonwebtoken@9.0.2",
      "licenses": [
        {
          "license": {
            "id": "MIT"
          }
        }
      ]
    }
  ],
  "dependencies": [
    {
      "ref": "pkg:npm/myapp@1.0.0",
      "dependsOn": [
        "pkg:npm/axios@1.6.5",
        "pkg:npm/express@4.18.2",
        "pkg:npm/jsonwebtoken@9.0.2"
      ]
    }
  ]
}

Commandes Syft et Trivy pour génération automatisée — à intégrer en pipeline CI :

# ===== Installation Syft et Grype (Anchore) =====
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin
curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin
 
# ===== Generation SBOM depuis un repertoire source =====
syft scan dir:./myapp -o cyclonedx-json=sbom.cdx.json
syft scan dir:./myapp -o spdx-json=sbom.spdx.json
 
# ===== Generation SBOM depuis une image Docker =====
syft scan myapp:1.0.0 -o cyclonedx-json=image-sbom.cdx.json
 
# ===== Scan vulnerabilites sur un SBOM existant =====
grype sbom:./sbom.cdx.json --fail-on high
 
# ===== Trivy approche alternative integree =====
trivy image --format cyclonedx --output sbom-trivy.cdx.json myapp:1.0.0
trivy sbom --severity HIGH,CRITICAL ./sbom-trivy.cdx.json
 
# ===== Signature du SBOM avec Cosign (Sigstore) =====
cosign sign-blob --bundle sbom.cdx.json.sig sbom.cdx.json
 
# ===== Attachement du SBOM a une image OCI =====
cosign attest --predicate sbom.cdx.json --type cyclonedx myapp:1.0.0

6. Cas d'usage n°1 — Incident response Log4Shell

Cas concret illustrant l'apport du SBOM en incident response supply chain.

Scénario Log4Shell, décembre 2021

• Jour J : publication de CVE-2021-44228 (RCE critique Log4j 2.x), CVSS 10.0, exploitation active observée dans les heures suivantes.
• Question critique pour chaque organisation : « Quelles applications de notre parc utilisent Log4j 2.x vulnérable, et quelles versions ? »

Sans SBOM centralisé

• Audit manuel de chaque application.
• Grep sur tous les pom.xml, build.gradle, package-lock.json, fichiers config.
• Coordination avec équipes dev pour identifier les dépendances transitives.
• Temps médian : 3-7 jours pour grande organisation, parfois plus.
• Pendant ce temps : exploitation en cours.

Avec SBOM centralisé dans OWASP Dependency-Track

• Requête SQL ou API unique sur le catalogue SBOM : SELECT app FROM sbom WHERE component='log4j-core' AND version < '2.17.1'.
• Résultat : liste complète des applications concernées avec versions, environnements, criticité.
• Temps : 5 minutes.
• Pendant ce temps : patch ou mitigation déployée en priorité.

Cas xz-utils backdoor, mars 2024 : même schéma. Les organisations avec SBOM ont identifié leurs instances xz-utils en heures. Les autres ont passé des semaines à cartographier, malgré le faible nombre de systèmes affectés (builds OpenSSH récents uniquement).

7. Intégration pipeline DevSecOps

Pipeline DevSecOps moderne incluant génération SBOM, scan vulnérabilités, signature Cosign et attestation OCI — exploitable en portfolio GitHub.

# .github/workflows/sbom-pipeline.yml
# Pipeline DevSecOps avec generation SBOM complete.
 
name: Build and SBOM Pipeline
 
on:
  push:
    branches: [main]
 
permissions:
  contents: read
  packages: write
  id-token: write
 
jobs:
  build-and-sbom:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
 
      - name: Login to GitHub Container Registry
        uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
 
      - name: Build Docker image
        run: docker build -t ghcr.io/${{ github.repository }}:${{ github.sha }} .
 
      # --- Generation SBOM CycloneDX via Syft ---
      - name: Generate CycloneDX SBOM
        uses: anchore/sbom-action@v0
        with:
          image: ghcr.io/${{ github.repository }}:${{ github.sha }}
          format: cyclonedx-json
          output-file: sbom.cdx.json
 
      # --- Generation SBOM SPDX via Syft ---
      - name: Generate SPDX SBOM
        uses: anchore/sbom-action@v0
        with:
          image: ghcr.io/${{ github.repository }}:${{ github.sha }}
          format: spdx-json
          output-file: sbom.spdx.json
 
      # --- Scan vulnerabilites via Grype sur le SBOM ---
      - name: Scan SBOM with Grype
        uses: anchore/scan-action@v3
        with:
          sbom: ./sbom.cdx.json
          severity-cutoff: high
          fail-build: true
 
      # --- Push de l'image vers registry ---
      - name: Push image
        run: docker push ghcr.io/${{ github.repository }}:${{ github.sha }}
 
      # --- Signature SBOM via Cosign (Sigstore, keyless OIDC) ---
      - name: Install Cosign
        uses: sigstore/cosign-installer@v3
 
      - name: Sign image and attach SBOM attestation
        run: |
          cosign sign --yes ghcr.io/${{ github.repository }}:${{ github.sha }}
          cosign attest --yes \
            --predicate sbom.cdx.json \
            --type cyclonedx \
            ghcr.io/${{ github.repository }}:${{ github.sha }}
 
      # --- Upload SBOM vers OWASP Dependency-Track ---
      - name: Upload SBOM to Dependency-Track
        run: |
          curl -X POST \
            -H "X-Api-Key: ${{ secrets.DEPTRACK_API_KEY }}" \
            -H "Content-Type: multipart/form-data" \
            -F "project=${{ secrets.DEPTRACK_PROJECT_ID }}" \
            -F "bom=@sbom.cdx.json" \
            https://dependency-track.example.internal/api/v1/bom
 
      # --- Archivage SBOM dans artefacts ---
      - name: Upload SBOM artifacts
        uses: actions/upload-artifact@v4
        with:
          name: sbom-files
          path: |
            sbom.cdx.json
            sbom.spdx.json
          retention-days: 90

Ce pipeline produit à chaque build : SBOM CycloneDX, SBOM SPDX, scan Grype bloquant sur vulnérabilités HIGH/CRITICAL, signature image et SBOM via Cosign keyless OIDC Sigstore, push vers OWASP Dependency-Track pour catalogue centralisé, archivage artefacts 90 jours.

8. SBOM, VEX et SLSA — écosystème supply chain security

Le SBOM ne suffit pas seul. Deux compléments structurants en 2026.

VEX (Vulnerability Exploitability eXchange)

• Problème : un SBOM liste les composants. Un scan identifie les CVE. Mais beaucoup de CVE détectées ne sont pas réellement exploitables dans un contexte applicatif donné (code vulnérable non appelé, mitigation déjà en place).
• Solution VEX : format standardisé (CSAF 2.0, CycloneDX VEX, OpenVEX) pour déclarer pour chaque CVE détectée : exploitable, non exploitable, en cours d'analyse, non impactée (justifications).
• Bénéfice : réduction du bruit vulnerability management, priorisation efficace.

SLSA (Supply-chain Levels for Software Artifacts)

• Problème : le SBOM dit « qu'est-ce qu'il y a dans mon logiciel ». SLSA dit « comment mon logiciel a été construit ».
• Framework SLSA (Google puis OpenSSF, v1.0 avril 2023) : 4 niveaux de garanties d'intégrité du processus de build. SLSA 1 (documentation), SLSA 2 (attestations signées), SLSA 3 (build reproductible isolé), SLSA 4 (audit indépendant).
• Complémentarité avec SBOM : SLSA certifie que le SBOM est produit de manière fiable par un processus de build intègre.

Écosystème complet 2026

Un produit mature en 2026 combine les 5 pour couvrir supply chain security de bout en bout.

9. OWASP Dependency-Track — la plateforme centralisée recommandée

OWASP Dependency-Track est la plateforme open-source leader 2026 pour centraliser, corréler et exploiter les SBOMs à l'échelle enterprise.

Fonctionnalités principales

• Catalogue centralisé de SBOMs CycloneDX.
• Mapping automatique CVE via NVD, OSV, VulnDB.
• Score EPSS intégré.
• Alertes temps réel en cas de nouvelle CVE.
• Dashboards par projet, par composant, par CVE.
• API REST complète pour intégration CI/CD.
• Support VEX natif.
• Licence compliance.
• Intégrations : Jira, Slack, Teams, webhook.

Déploiement : Helm chart Kubernetes officiel, image Docker, 4-16 Go RAM recommandés selon catalogue. Solution on-premise ou cloud self-hosted. Alternatives commerciales : Snyk Supply Chain Security, Sonatype Nexus IQ, FOSSA, Anchore Enterprise.

10. Pour aller plus loin

• Qu'est-ce que l'OWASP Top 10 : cadre OWASP complet — SBOM lié à A06:2021 Vulnerable Components et A08:2021 Software/Data Integrity Failures.
• Secrets management pour développeurs : complément supply chain security.
• C'est quoi une vulnérabilité SSRF : vulnérabilité applicative classique.
• OWASP Top 10 Web — introduction et vue d'ensemble 2025 : analyse des 10 catégories.
• Roadmap AppSec : parcours AppSec engineer complet.
• Roadmap Secure Coding : développement sécurisé.

11. Points clés à retenir

• SBOM = nomenclature structurée machine-readable de tous les composants logiciels d'une application.
• 3 crises supply chain fondatrices : SolarWinds SUNBURST (2020), Log4Shell (CVE-2021-44228), xz-utils backdoor (CVE-2024-3094).
• Réglementations obligatoires : EO 14028 (US 2021), Cyber Resilience Act UE (2024/2847, applicable décembre 2027), NIS 2, DORA.
• 2 standards dominants : SPDX (ISO/IEC 5962:2021, compliance) et CycloneDX (OWASP, AppSec). Best practice : générer les deux.
• 7 champs minimum NTIA : auteur, timestamp, supplier, component name, version, identifiers (PURL), dependency relationships.
• Outils leaders 2026 : Syft (Anchore, open-source), Trivy (Aqua), CycloneDX GitHub Action, Microsoft SBOM Tool.
• Cas d'usage n°1 : incident response supply chain. Log4Shell sans SBOM = 3-7 jours, avec SBOM centralisé = 5 minutes.
• OWASP Dependency-Track : plateforme open-source leader pour centralisation SBOMs à l'échelle enterprise.
• Écosystème supply chain security complet : SBOM + VEX + SLSA + Sigstore + SSDF.
• Cyber Resilience Act UE obligatoire décembre 2027 — SBOM, correction vulnérabilités support, notification ENISA 24h. Amendes 15 M€ ou 2,5 % CA mondial.

La formation OWASP Web Security Zeroday Cyber Academy inclut un module approfondi SBOM et supply chain security avec labs Syft plus Grype plus OWASP Dependency-Track, intégration pipeline GitHub Actions complet avec signature Cosign OIDC, préparation au Cyber Resilience Act UE, et coaching d'entretien AppSec plus DevSecOps ciblé éditeurs logiciels plus scale-ups régulés NIS 2/DORA/CRA.