Nomenclature logicielle

Une nomenclature logicielle (en anglais Software Bill Of Materials ou SBOM) liste les composants utilisés pour créer un artefact logiciel, y compris les composants logiciels open source et propriétaires. Elle est l'équivalent logiciel de la nomenclature traditionnelle (en anglais Bill Of Materials ou BOM). La SBOM est utile pour la cyber sécurité en permettant d'identifier les vulnérabilités potentielles ou avérées d'un logiciel^[1].

Utilisation

Une nomenclature logicielle ou SBOM permet de vérifier que les composants logiciels (open source ou non) sont bien à jour. Elle permet de s'assurer que ces composants n'ont pas de vulnérabilités connues à ce jour. Enfin, elle permet de lister les licences des différents composants utilisés. Cela aide les organisations à garantir la conformité avec les conditions de licence des composants et éviter des problèmes juridiques par exemple. Dans certains secteurs réglementés, comme par exemple le médical, une SBOM peut être exigée^[2].

Élément d'une SBOM

Pour être pertinente, une SBOM doit contenir un certain nombre d'informations. La NTIA (National Telecommunications and Information Administration) des États-Unis recommande les éléments suivants^[3]:

• le nom du fournisseur
• le nom du composant
• la version du composant
• la relation de dépendance
• l'auteur des données SBOM
• les autres identifiants uniques permettant d'identifier un composant
• l'horodate (date et heure de création des données)

Les autres éléments qui peuvent être importants sont : l'information sur la licence du composant, le hachage du composant (identifiant unique), l'outil qui a créé la SBOM et le contexte de sa création^[4].

Génération

Il est possible de générer manuellement une SBOM, dans un tableur par exemple mais cela peut demander beaucoup de temps et est sujet à des erreurs et des oublis. De plus, la maintenance, lorsqu'il faut ajouter ou enlever un composant ou mettre à jour la version, n'est pas aisée. Il est donc préférable d'utiliser un outil pour générer automatiquement le SBOM, comme par exemple le logiciel trivy^[5].

Formats de fichier

Plusieurs formats standards de SBOM existent, parmi lesquels SPDX, CycloneDX^[6] et SWID (Software Identification)^[7]. Ces fichiers peuvent être consommés par des outils d'analyse de vulnérabilités, qui vont chercher dans les vulnérabilités connues (telles que les CVE) dans des bases de données publiques comme par exemple la National Vulnerability Database (NVD)^[8]. Le fichier VEX (pour Vulnerability Exploitability Exchange) vient compléter la SBOM : il indique pour chaque vulnérabilité présente dans les dépendances si elle est exploitable, si elle a été corrigée, etc.^[9]

Législation

États Unis

La loi américaine de 2014 sur la gestion et la transparence de la chaîne d'approvisionnement numérique (Cyber Supply Chain Management and Transparency Act) était un projet de loi qui a échoué. Elle proposait d'obliger les agences gouvernementales à obtenir les SBOM de tous les nouveaux produits qu'elles achètent et à obtenir les SBOM de « tout logiciel, micrologiciel ou produit utilisé par le gouvernement des États-Unis »^[10]. Cette loi a inspiré des législations ultérieures telles que la loi de 2017 sur l'amélioration de la cybersécurité de l'Internet des objets (Internet of Things Cybersecurity Improvement Act).

Le décret présidentiel américain n° 14028 du 12 mai 2021 sur l'amélioration de la cybersécurité nationale, signé par le président Joe Biden, a chargé le NIST et la NTIA d'établir des lignes directrices pour la gestion de la chaîne d'approvisionnement logicielle, y compris pour les SBOM^[11]. La NTIA définit trois grandes catégories d'éléments minimaux pour les SBOM : les champs de données (informations de base sur chaque composant logiciel), la prise en charge de l'automatisation (la capacité à générer des SBOM dans des formats lisibles par les machines et les humains) et les pratiques et processus (comment et quand les organisations doivent générer des SBOM). L'exigence de « prise en charge de l'automatisation » précise la nécessité d'une « génération automatique », ce qui est possible grâce à l'utilisation de solutions d'analyse de la composition logicielle (en anglais Software Composition Analysis ou SCA).

Union européenne

Le règlement sur la cyber résilience (Cyber Resilience Act ou CRA), qui entrera en vigueur en décembre 2027^[12], oblige notamment les fabricants de produits comportant des éléments numériques à identifier et à documenter les failles de sécurité et les composants de leurs produits. Un élément central de cette documentation est la création d'une nomenclature logicielle (SBOM) dans un format courant lisible par machine. Cette SBOM doit au moins représenter les dépendances supérieures des produits. Si le fabricant met la SBOM à la disposition de l'utilisateur, il doit également indiquer où cette liste peut être consultée. En outre, la documentation technique du produit doit inclure une SBOM. Sur demande motivée de l'autorité de surveillance du marché, la SBOM doit également être mise à disposition. Ces mesures visent à accroître la transparence et la sécurité des produits dans l'Union Européenne en fournissant une vue d'ensemble des composants logiciels utilisés et de leurs dépendances^[13].