Software Bill of Materials : Template et Exemple Concret

Introduction

La directive NIS2 (UE) 2022/2555 impose de nouvelles obligations strictes en matière de cybersécurité pour les secteurs critiques et essentiels. Parmi ces exigences, la mise en place d’un Software Bill of Materials (SBOM) devient un élément clé de la gestion des risques liés à la supply chain logicielle.

Selon l’article 21 de la directive, les entités concernées doivent “prendre des mesures techniques et organisationnelles appropriées pour gérer les risques pesant sur la sécurité des réseaux et systèmes d’information”. Le SBOM répond directement à cette exigence en permettant une traçabilité complète des composants logiciels.

Qu’est-ce qu’un Software Bill of Materials (SBOM) ?

Définition officielle

Un SBOM est une liste exhaustive de tous les composants logiciels, bibliothèques et dépendances utilisés dans une application ou un système. Il inclut :

• Les versions exactes de chaque composant
• Les licences associées
• Les vulnérabilités connues
• Les relations entre les composants

Cadre réglementaire NIS2

Bien que le terme SBOM ne soit pas explicitement mentionné dans la directive (UE) 2022/2555, plusieurs articles imposent des obligations qui nécessitent sa mise en œuvre :

• Article 21(2) : Exigence de gestion des risques dans la chaîne d’approvisionnement
• Article 21(3)(d) : Obligation de politiques de sécurité pour l’acquisition de logiciels
• Article 23 : Notification des incidents impliquant des vulnérabilités logicielles

Pourquoi le SBOM est-il critique pour la conformité NIS2 ?

Répondre aux exigences de l’article 21

L’article 21 impose aux entités essentielles et importantes de mettre en œuvre des mesures de gestion des risques qui incluent :

• L’analyse des risques liés aux fournisseurs
• La gestion des vulnérabilités
• La traçabilité des composants critiques

Exemples sectoriels concrets

Secteur de la santé (HDS) : Un éditeur de logiciels médicaux doit documenter tous les composants open source utilisés dans son application pour répondre aux exigences de l’Annexe I.

Secteur financier : Une banque doit pouvoir tracer les bibliothèques cryptographiques utilisées dans ses applications mobiles pour se conformer à la fois à NIS2 et au règlement DORA.

Template complet de SBOM conforme NIS2

Structure obligatoire

Un SBOM conforme aux exigences NIS2 doit contenir au minimum :

• Métadonnées de l’application principale
• Liste hiérarchique des composants
• Informations de version et de patch
• Dépendances externes
• Vulnérabilités connues (CVE)
• Licences logicielles

Exemple concret pour une application bancaire

Mise en œuvre opérationnelle

Processus de création

La création d’un SBOM implique 4 étapes clés :

• Inventaire automatique des composants
• Analyse des dépendances
• Vérification des vulnérabilités
• Génération du document final

Outils recommandés

Plusieurs solutions permettent de générer des SBOM conformes :

• OWASP Dependency-Track
• SPDX Tools
• CycloneDX
• Syft

FAQ

Quelles entités sont concernées par l’obligation de SBOM ?

Toutes les entités essentielles (Annexe I) et importantes (Annexe II) de la directive NIS2 qui développent ou utilisent des logiciels critiques doivent mettre en place des SBOM. Cela inclut notamment les secteurs de la santé, de la finance, de l’énergie et des transports.

Quels formats sont recommandés pour un SBOM ?

Les formats standardisés comme SPDX, CycloneDX ou SWID sont recommandés pour assurer l’interopérabilité. La directive NIS2 ne spécifie pas de format particulier mais exige que l’information soit complète et exploitable.

À quelle fréquence mettre à jour le SBOM ?

Le SBOM doit être mis à jour à chaque nouvelle version de l’application et lors de la découverte de nouvelles vulnérabilités. L’article 23 de la directive impose une notification sous 24h pour les incidents critiques.

Comment intégrer le SBOM dans une démarche NIS2 complète ?

Le SBOM doit s’insérer dans le système de gestion des risques global exigé par l’article 21. Il doit être relié aux processus d’évaluation des fournisseurs, de gestion des vulnérabilités et de réponse aux incidents.

Conclusion

Le Software Bill of Materials représente un élément clé de la conformité à la directive NIS2 pour les secteurs critiques. Sa mise en œuvre permet non seulement de répondre aux exigences réglementaires, mais aussi d’améliorer significativement la sécurité des systèmes d’information.

Pour approfondir votre démarche de conformité NIS2, consultez notre guide complet sur la mise en œuvre des mesures techniques et organisationnelles exigées par l’article 21.

Accéder à notre accompagnement NIS2