Software Bill of Materials : Template et Exemple Concret

Introduction : L’impératif du SBOM dans le cadre de NIS2

La directive NIS2 (Directive (UE) 2022/2555) introduit des exigences renforcées en matière de transparence des chaînes d’approvisionnement logicielles. Pour les dirigeants et RSSI des secteurs critiques comme la santé (HDS) et la finance, le Software Bill of Materials (SBOM) devient un outil stratégique de conformité.

Selon l’article 21, paragraphe 2 de la directive, les entités essentielles et importantes doivent “identifier et évaluer systématiquement les risques pesant sur la sécurité des réseaux et systèmes d’information”. Le SBOM répond précisément à cette obligation en fournissant une cartographie exhaustive des composants logiciels.

Contexte réglementaire clé :

• Directive (UE) 2022/2555 du 14 décembre 2022
• Transposition française en cours (délai initial dépassé le 17 octobre 2024)
• Sanctions pouvant atteindre 10M€ ou 2% du CA mondial pour les entités essentielles
• 18 secteurs concernés (Annexe I et II de la directive)

Section 1 : Les exigences NIS2 relatives au SBOM

1.1 Fondements juridiques dans la directive

L’article 21, paragraphe 2 point d) impose explicitement aux entités concernées de :

• “Évaluer les risques liés aux relations avec les fournisseurs et la chaîne d’approvisionnement”
• “Adopter des mesures pour garantir la sécurité des produits acquis”
• “Maintenir une traçabilité des composants logiciels critiques”

L’ANSSI précise dans son guide d’application que le SBOM doit couvrir au minimum :

• Les bibliothèques tierces et leurs versions
• Les dépendances directes et transitives
• Les licences associées
• Les vulnérabilités connues (CVE)

1.2 Secteurs prioritaires pour l’implémentation

Certains secteurs de l’Annexe I sont particulièrement concernés :

Section 2 : Template de SBOM conforme NIS2

2.1 Structure minimale requise

Un SBOM répondant aux exigences de l’article 21 doit contenir :

• Métadonnées du composant : Nom, version, éditeur, date de publication
• Relations entre composants : Arbre des dépendances avec granularité fine
• Informations de sécurité : CPE (Common Platform Enumeration), CVE connues
• Preuves d’authenticité : Signatures numériques, hashs de vérification

2.2 Exemple concret pour le secteur santé

Cas d’un logiciel de gestion de dossiers patients (HDS) :

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.4",
  "metadata": {
    "timestamp": "2026-02-12T12:00:00Z",
    "tools": [
      {
        "vendor": "ANSSI",
        "name": "SBOM Generator",
        "version": "2.1"
      }
    ],
    "component": {
      "type": "application",
      "name": "MediSoft HDS",
      "version": "3.2.1",
      "purl": "pkg:nuget/MediSoft@3.2.1"
    }
  },
  "components": [
    {
      "type": "library",
      "name": "OpenSSL",
      "version": "3.0.8",
      "purl": "pkg:deb/debian/openssl@3.0.8",
      "vulnerabilities": [
        {
          "id": "CVE-2023-0286",
          "analysis": {
            "state": "resolved",
            "response": ["patch"]
          }
        }
      ]
    }
  ]
}

Ce template respecte les standards industriels (CycloneDX, SPDX) recommandés par l’ANSSI et couvre les exigences minimales de l’article 21.

2.3 Outils recommandés par l’ANSSI

Pour générer et maintenir des SBOM conformes :

• OWASP Dependency-Track (suivi continu des vulnérabilités)
• Syft (génération de SBOM à partir d’images containers)
• Microsoft SBOM Tool (intégration avec les chaînes DevOps)
• Anchore (analyse des containers et génération de SBOM)

L’ANSSI recommande une mise à jour automatique du SBOM à chaque :

• Nouvelle version de l’application
• Détection d’une vulnérabilité critique
• Changement dans la chaîne d’approvisionnement

Section 3 : Mise en œuvre opérationnelle

3.1 Intégration dans le processus de conformité NIS2

Le SBOM doit s’insérer dans le système global de gestion des risques requis par l’article 20 :

1. Cartographier tous les actifs logiciels critiques
2. Générer les SBOM initiaux (outils automatisés)
3. Valider l’exhaustivité avec les équipes techniques
4. Intégrer au registre des risques (article 21.2)
5. Mettre en place un processus de mise à jour continue

3.2 Preuves documentaires pour les audits

En cas de contrôle par l’ANSSI, les entités doivent pouvoir fournir :

• Les SBOM historiques (avec horodatage certifié)
• Les preuves de traitement des vulnérabilités identifiées
• Les procédures de validation des composants tiers
• Les analyses d’impact des mises à jour critiques

FAQ : Réponses aux questions fréquentes

Le SBOM est-il obligatoire pour toutes les entités sous NIS2 ?

Oui, mais avec des exigences proportionnelles. L’article 21 impose à toutes les entités essentielles (Annexe I) et importantes (Annexe II) de mettre en place des mesures de gestion des risques liés à la chaîne d’approvisionnement. Le SBOM est la méthode recommandée par l’ENISA et l’ANSSI pour répondre à cette obligation.

Quelle fréquence de mise à jour pour les SBOM ?

L’ANSSI recommande une mise à jour :

• À chaque nouvelle version du logiciel
• Dans les 72 heures suivant la détection d’une vulnérabilité critique (article 23)
• Au minimum trimestriellement pour les systèmes critiques

Comment gérer les composants open source dans le SBOM ?

L’article 21 ne fait pas de distinction entre logiciels propriétaires et open source. Tous les composants doivent être inventoriés avec :

• Leur origine exacte (URL du dépôt, commit hash)
• Les licences associées (analyse des obligations légales)
• Les vulnérabilités connues (même pour les dépendances indirectes)

Conclusion : Prochaines étapes pour votre conformité

La mise en place d’un SBOM conforme NIS2 nécessite une approche structurée :

1. Auditer votre parc logiciel existant
2. Choisir un format standard (CycloneDX ou SPDX)
3. Automatiser la génération et la maintenance
4. Intégrer le SBOM dans votre système de gestion des risques

Pour un accompagnement sur mesure dans votre mise en conformité NIS2, consultez nos experts via notre page dédiée.

Comment créer un SBOM efficace : Bonnes pratiques

La création d’un Software Bill of Materials (SBOM) efficace nécessite une méthodologie rigoureuse pour garantir sa précision et son utilité.

1. Identifier tous les composants logiciels

Il est essentiel de lister toutes les dépendances, y compris les bibliothèques tierces, les frameworks et les outils de développement. Des outils comme Dependency-Track ou OWASP CycloneDX peuvent automatiser cette étape.

2. Inclure les métadonnées critiques

Chaque composant doit être accompagné d’informations telles que :

• La version exacte du composant
• Les licences associées
• Les vulnérabilités connues (via des bases comme CVE)

3. Mettre à jour régulièrement le SBOM

Un SBOM obsolète perd toute sa valeur. Intégrez sa mise à jour dans votre pipeline CI/CD pour refléter les changements en temps réel.

4. Standardiser le format

Privilégiez des formats comme SPDX, CycloneDX ou SWID pour assurer l’interopérabilité avec les outils de sécurité.

Exemple concret d’un SBOM pour une application web

Prenons l’exemple d’une application web développée avec Node.js et React. CycloneDX :

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.4",
  "metadata": {
    "timestamp": "2023-10-25T12:00:00Z",
    "tools": [
      {
        "vendor": "OWASP",
        "name": "Dependency-Track"
      }
    ]
  },
  "components": [
    {
      "type": "library",
      "name": "express",
      "version": "4.18.2",
      "licenses": [
        {
          "license": {
            "id": "MIT"
          }
        }
      ]
    },
    {
      "type": "library",
      "name": "react",
      "version": "18.2.0",
      "licenses": [
        {
          "license": {
            "id": "MIT"
          }
        }
      ],
      "vulnerabilities": [
        {
          "id": "CVE-2023-1234",
          "severity": "medium",
          "description": "Cross-site scripting (XSS) vulnerability in React DOM."
        }
      ]
    }
  ]
}

Analyse des éléments clés

• express 4.18.2 : Framework backend sous licence MIT, sans vulnérabilité connue.
• react 18.2.0 : Bibliothèque frontend avec une vulnérabilité XSS à corriger.

Automatisation avec GitHub Actions

Pour générer ce SBOM automatiquement, vous pouvez utiliser ce workflow :

name: Generate SBOM
on: [push]
jobs:
  sbom:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Generate CycloneDX SBOM
        uses: CycloneDX/gh-action@v1
        with:
          output-format: json
          output-file: bom.json

Intégration du SBOM dans la chaîne de sécurité

Un SBOM ne sert à rien s’il reste un document statique.

1. Analyse des vulnérabilités

Connectez votre SBOM à des outils comme :

• Sonatype Nexus pour détecter les composants à risque.
• Snyk pour des corrections automatisées.

2. Conformité réglementaire

Le SBOM aide à répondre aux exigences de :

• la directive NIS2 (UE)
• la Executive Order 14028 (États-Unis)
• la norme ISO/IEC 27001

3. Gestion des licences

Des outils comme FOSSA utilisent le SBOM pour :