SBOM : générer, auditer et sécuriser votre supply chain logicielle

Selon les derniers chiffres de la CISA (Cybersecurity and Infrastructure Security Agency), 91 % des bases de code commerciales contiennent des dépendances open source présentant au moins une vulnérabilité connue. Le constat est sans appel : sans inventaire exhaustif de ce qui compose vos logiciels, vous naviguez à l'aveugle.

Le Software Bill of Materials (SBOM), littéralement la "nomenclature logicielle", répond à ce problème de façon structurelle. Pas un outil de plus, mais un standard d'inventaire qui liste chaque composant, chaque bibliothèque, chaque dépendance transitive embarquée dans un livrable. Les organisations qui l'adoptent raccourcissent nettement leur temps de réponse aux incidents de type supply chain.

Ce guide couvre l'essentiel : les deux formats qui comptent, les outils pour les produire, et comment les intégrer concrètement dans une CI/CD.

Le marché du SBOM repose sur deux formats ouverts. Les connaître conditionne un choix éclairé.

SPDX (Software Package Data Exchange)

Maintenu par la Linux Foundation, SPDX est le plus ancien des deux. Il a été conçu initialement pour la conformité des licences open source avant d'intégrer progressivement les métadonnées de sécurité. Ses points forts :

• Adoption massive : reconnu par l'ISO/IEC 5962:2021, c'est le seul format SBOM normalisé ISO
• Couverture des licences : granularité fine sur les obligations juridiques (SPDX License List)
• Formats multiples : JSON, RDF, YAML, tag-value, XML

Sa faiblesse : les champs liés à la sécurité (vulnérabilités, exploitabilité) ont été ajoutés tardivement et restent moins natifs que chez son concurrent.

CycloneDX

Né au sein de l'OWASP, CycloneDX a été pensé dès le départ pour la sécurité applicative. Ses atouts :

• VEX natif (Vulnerability Exploitability eXchange) : il intègre directement les informations d'exploitabilité, ce qui sépare les vulnérabilités réellement exploitables du bruit
• Léger et orienté DevSecOps : le format est plus compact et plus simple à parser dans un pipeline
• Support étendu : SBOM, SaaSBOM, VDR, OBOM (hardware), MBOM (manufacturing)

Selon les données de la communauté OWASP, CycloneDX est aujourd'hui le format le plus adopté dans les pipelines CI/CD, tandis que SPDX domine dans les contextes de conformité juridique et de gouvernance des licences.

Recommandation terrain : si votre priorité est la sécurité opérationnelle et l'intégration CI/CD, partez sur CycloneDX. Si vous devez répondre à des audits de licences ou à des exigences ISO, SPDX reste imposé par les référentiels. Dans l'idéal, vos outils doivent supporter les deux.

Syft : la génération du SBOM

Syft, développé par Anchore (plus de 6 000 stars GitHub), est devenu la référence open source pour générer des SBOM. Il analyse des images de conteneurs, des systèmes de fichiers et des archives, puis produit un inventaire dans le format de votre choix.

# Générer un SBOM CycloneDX depuis une image Docker
syft registry.example.com/mon-app:latest -o cyclonedx-json > sbom.cdx.json

# Générer un SBOM SPDX depuis un répertoire
syft dir:/chemin/vers/le/projet -o spdx-json > sbom.spdx.json

Syft détecte automatiquement les gestionnaires de paquets (npm, pip, Maven, Go modules, Cargo, NuGet, APK, RPM, DEB) et résout les dépendances transitives. C'est cette profondeur d'analyse qui fait sa valeur : vous voyez ce que contient réellement votre livrable, pas seulement ce que vous avez déclaré.

Grype : le scan de vulnérabilités

Grype (plus de 8 000 stars GitHub) prend le relais en croisant le SBOM généré par Syft avec des bases de vulnérabilités : NVD, GitHub Advisory Database et les flux spécifiques aux distributions (Red Hat, Debian, Ubuntu, Alpine).

# Scanner un SBOM existant
grype sbom:./sbom.cdx.json

# Scanner directement une image
grype registry.example.com/mon-app:latest --fail-on critical

L'option --fail-on est centrale en CI/CD : elle fait échouer le pipeline si une vulnérabilité d'un certain niveau de sévérité est détectée. C'est le mécanisme de gate qui empêche un livrable vulnérable d'atteindre la production.

Trivy : l'alternative tout-en-un

Trivy, développé par Aqua Security, combine génération de SBOM et scan de vulnérabilités dans un seul outil. Il couvre également les misconfiguration IaC (Terraform, Kubernetes manifests) et les secrets exposés.

# Générer un SBOM et scanner en une commande
trivy image --format cyclonedx --output sbom.cdx.json mon-app:latest
trivy sbom sbom.cdx.json

Trivy a l'avantage de la simplicité, mais Syft et Grype donnent une granularité supérieure et une meilleure séparation des responsabilités dans un pipeline mature.

L'enquête auprès des équipes DevSecOps montre que le SBOM n'a de valeur que s'il est automatisé et systématique. Voici un pipeline type dans GitLab CI :

stages:
  - build
  - sbom
  - scan
  - deploy

generate-sbom:
  stage: sbom
  image: anchore/syft:latest
  script:
    - syft $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA -o cyclonedx-json > sbom.cdx.json
    - syft $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA -o spdx-json > sbom.spdx.json
  artifacts:
    paths:
      - sbom.cdx.json
      - sbom.spdx.json

vulnerability-scan:
  stage: scan
  image: anchore/grype:latest
  script:
    - grype sbom:./sbom.cdx.json --fail-on critical
  allow_failure: false

Les points clés de cette intégration :

1. Générer le SBOM après le build : le SBOM doit refléter l'image finale, pas le code source seul
2. Archiver les SBOM : chaque release doit être accompagnée de son SBOM, stocké par exemple dans Harbor ou un dépôt d'artefacts
3. Fail fast : le scan Grype doit bloquer le pipeline si des vulnérabilités critiques sont détectées
4. Deux formats : générer à la fois CycloneDX (pour le DevSecOps) et SPDX (pour la conformité)

Cette approche prolonge une démarche DevSecOps plus large, où la sécurité s'intègre à chaque étape du cycle de développement.

Selon les derniers textes publiés par l'ENISA et l'Union européenne, deux réglementations imposent désormais une traçabilité accrue de la supply chain logicielle.

NIS2 (Network and Information Security Directive 2)

Entrée en application en octobre 2024, NIS2 élargit considérablement le périmètre des organisations concernées (opérateurs de services essentiels et fournisseurs de services numériques). Elle exige :

• La gestion des risques liés à la chaîne d'approvisionnement (article 21) : les organisations doivent évaluer et maîtriser les risques provenant de leurs fournisseurs et prestataires
• La notification des incidents dans un délai de 24 heures, puis un rapport détaillé sous 72 heures
• Des mesures techniques proportionnées : le SBOM n'est pas explicitement nommé, mais il reste le moyen le plus direct de répondre à l'obligation de transparence sur les composants logiciels

DORA (Digital Operational Resilience Act)

En vigueur depuis janvier 2025, DORA cible spécifiquement le secteur financier. Les exigences pertinentes :

• Gestion des risques TIC : identification exhaustive des actifs logiciels et de leurs dépendances
• Tests de résilience : les prestataires critiques doivent démontrer leur capacité à identifier et corriger les vulnérabilités dans leurs composants

Le Cyber Resilience Act (CRA)

Le CRA va plus loin : à partir de décembre 2027, les fabricants de produits contenant des éléments numériques devront fournir un SBOM. Les obligations de signalement de vulnérabilités et d'incidents entreront en vigueur dès septembre 2026.

L'enquête révèle que les organisations qui anticipent ces exigences via un SBOM automatisé dans leur CI/CD réduisent leur coût de mise en conformité de 40 à 60 % par rapport à celles qui s'y prennent au dernier moment.

1. Commencez par les images de conteneurs : c'est là que le ratio effort/valeur est le plus élevé, surtout si vous utilisez un registre comme Harbor
2. Automatisez dès le départ : un SBOM généré manuellement est un SBOM obsolète
3. Versionnez vos SBOM : chaque tag de release doit avoir son SBOM associé, archivé et accessible
4. Surveillez en continu : une dépendance saine aujourd'hui peut devenir vulnérable demain. Mettez en place un scan récurrent (pas seulement au build)
5. Formez les équipes : le SBOM n'est pas qu'un sujet sécurité, c'est un sujet de gouvernance logicielle qui concerne développeurs, ops et RSSI

Le SBOM n'est plus un nice-to-have. Avec NIS2, DORA et le CRA, il devient une obligation réglementaire pour un nombre croissant d'organisations européennes. Les outils open source (Syft, Grype, Trivy) sont matures, gratuits et intégrables en quelques heures dans une CI/CD existante.

La question n'est plus "faut-il adopter le SBOM ?", mais "pourquoi ne l'avez-vous pas encore fait ?".

• CISA 2025 Minimum Elements for a Software Bill of Materials
• OpenSSF : SBOMs in the Era of the CRA
• Anchore : Open Source Container Security with Syft and Grype
• CycloneDX SBOM Standard
• EU CRA SBOM Requirements (Anchore)