La nomenclature logicielle (SBOM) est une liste de tous les composants, bibliothèques et autres dépendances utilisés dans une application logicielle. Les formats standard pour les SBOM incluent SPDX, CycloneDX et CPE (Common Platform Enumeration). Ces formats fournissent une manière structurée de représenter les composants et les dépendances d'une application logicielle, facilitant ainsi la compréhension et la gestion des risques de sécurité associés à ces composants.
Dans cet article, nous allons expliquer en détail quels sont les différents formats et normes SBOM, ce qu'un SBOM doit inclure et pourquoi toutes les organisations doivent l'utiliser.
Qu'est-ce qu'une norme SBOM ?
La complexité et la nature dynamique des chaînes d'approvisionnement des systèmes logiciels modernes posent un défi important en matière de transparence. Ce manque de transparence contribue aux risques de cybersécurité et augmente les coûts associés au développement, à l'approvisionnement et à la maintenance. Les conséquences sont considérables et touchent non seulement les entreprises, mais également les questions collectives telles que la sécurité publique et la sécurité nationale dans notre monde interconnecté.
Une transparence accrue dans les chaînes d’approvisionnement en logiciels peut conduire à une réduction des risques et des coûts de cybersécurité en :
- Améliorer l'identification des systèmes vulnérables et identifier la cause première des incidents
- Diminuer le travail non planifié et improductif
- Permettant une différenciation du marché et une sélection de composants plus éclairées
- Standardiser les formats dans plusieurs secteurs, conduisant à une réduction de la duplication des efforts
- Détection des composants logiciels suspects ou contrefaits
La collecte et le partage de ces informations dans un format clair et cohérent peuvent contribuer à réduire les coûts, à améliorer la fiabilité et à renforcer la confiance dans notre infrastructure numérique.
Dans ce but, le groupe de travail sur la transparence des logiciels de la NTIA sur les normes et les formats a été créée en 2018 pour évaluer les formats actuels des nomenclatures logicielles et identifier les utilisations futures potentielles. Le groupe a examiné les normes et initiatives existantes liées à l'identification des composants externes et des bibliothèques partagées utilisés dans les produits logiciels et à la communication de ces informations dans un format lisible par machine. Le groupe n'a pas considéré les formats propriétaires. L'enquête originale a été publiée fin 2019 et mise à jour en 2021, en mettant l'accent sur la mise en évidence des avantages de l'écosystème d'outils SBOM et de l'importance de la coordination et de l'harmonisation dans le monde technique du SBOM. L’essentiel à retenir est que les données SBOM peuvent être transmises dans différents formats et que l’écosystème doit prendre en charge l’interopérabilité entre elles.
Le groupe de travail a constaté que trois formats sont couramment utilisés :
- Software Package Data Exchange (SPDX®), un format open source lisible par machine développé par la Linux Foundation et désormais une norme ISO/IEC
- CycloneDX (CDX), un format open source lisible par machine développé par la communauté OWASP
- Software Identification (SWID), une norme industrielle ISO/IEC utilisée par divers éditeurs de logiciels commerciaux
Il convient de noter que ces trois formats partagent des informations communes. Cependant, ils sont traditionnellement utilisés à différentes étapes du processus de développement logiciel et sont destinés à différents publics. Nous aborderons chacun de ces formats en détail dans cet article.
Que doit inclure un SBOM ?
Les composants minimum de la NTIA d’un SBOM, appelés éléments, se composent de trois grands domaines interdépendants. Ces éléments permettent une approche flexible de la transparence logicielle, abordant à la fois la technologie et le fonctionnement fonctionnel. Plus de détails ou d’avancées techniques pourraient être ajoutés à l’avenir. Comme mentionné précédemment, il s’agit actuellement des composants minimaux et les organisations peuvent en exiger davantage. La capacité de transparence dans la chaîne d'approvisionnement en logiciels peut s'améliorer et évoluer au fil du temps.
Ces éléments minimum requis pour le SBOM sont généralement regroupés en trois catégories :
- Champs de données: Un SBOM doit inclure des données importantes sur les composants logiciels, telles que le nom du composant, le nom du fournisseur, la version et les identifiants uniques. Il doit également inclure des informations sur les dépendances entre les composants, permettant une identification et un suivi précis de tous les composants logiciels tout au long de la chaîne d'approvisionnement.
- Pratiques et processus : La documentation SBOM doit également décrire les pratiques et procédures standard pour créer et mettre à jour le SBOM, le distribuer et y accéder, ainsi que gérer les erreurs.
- Prise en charge de l'automatisation : La nomenclature du logiciel doit être à la fois lisible par machine et pouvoir être générée automatiquement pour un suivi continu des données. Il se présente généralement dans des formats standard tels que les balises SPDX, CycloneDX et SWID, qui les rendent également lisibles par les humains.
Format standard SPDX SBOM
La spécification SPDX® (Software Package Data Exchange) est une norme ISO/IEC permettant de partager des informations sur les composants logiciels, les licences, les droits d'auteur et les détails de sécurité dans plusieurs formats de fichiers. Ce projet a développé et continue d'améliorer un ensemble de normes d'échange de données qui permettent aux entreprises et aux organisations de partager des métadonnées logicielles dans un format compréhensible à la fois par les humains et les machines, simplifiant ainsi les processus de la chaîne d'approvisionnement logicielle.
Les informations SPDX peuvent être liées à des produits logiciels spécifiques, des composants ou des ensembles de composants, des fichiers individuels ou même de petits extraits de code. Le projet SPDX se concentre sur la création et l'affinement d'un langage pour décrire les données pouvant être échangées dans le cadre d'un SBOM, et sur la possibilité de présenter ces données dans plusieurs formats de fichiers (RDF/XML, XLSX, tag-value, JSON, YAML). , et XML) pour faciliter la collecte et le partage d'informations sur les progiciels et le contenu associé, ce qui permet d'améliorer les délais et la précision.
La spécification SPDX décrit les champs et sections nécessaires pour un document valide, mais il est important de noter que toutes les sections ne sont pas obligatoires : seule la section d'informations sur la création est obligatoire. Le créateur du document peut choisir les sections et les champs qu'il souhaite inclure, décrivant le logiciel et les informations de métadonnées qu'il envisage de partager.
SPDX peut capturer efficacement les données de nomenclature logicielle en représentant tous les composants trouvés dans le développement et le déploiement de logiciels. Il est utilisé pour documenter les images de distribution .iso, les conteneurs, les progiciels, les fichiers binaires, les fichiers sources, les correctifs et même de petits extraits de code intégrés dans d'autres fichiers. SPDX offre un ensemble complet de relations pour connecter les éléments logiciels au sein des documents et entre les documents SBOM. Un document SPDX SBOM peut également référencer des sources externes telles que la base de données nationale sur les vulnérabilités et d'autres métadonnées du système de packaging.
Plusieurs composants composent un document SPDX : informations de création, informations sur le package, informations sur le fichier, informations sur l'extrait de code, autres informations sur les licences, relations et annotations.
Chaque document SPDX peut être représenté par une implémentation complète d'un modèle de données et une syntaxe d'identifiant, permettant l'échange entre différents formats de sortie de données (RDF/XML, valeur de balise, XLSX) et la validation formelle de l'exactitude du document. La version 2.2 de la spécification SPDX inclut des formats de sortie supplémentaires tels que JSON, YAML et XML, et traite également des « inconnues connues » telles qu'identifiées dans le document SBOM d'origine. Plus d'informations sur le modèle de données sous-jacent de SPDX peuvent être trouvées dans l'annexe III de la spécification SPDX et sur le site Web de SPDX.
Format standard SBOM CycloneDX
Le projet CycloneDX a été créé en 2017 dans le but de développer une norme SBOM entièrement automatisée et axée sur la sécurité. Le groupe de travail principal publie chaque année des versions immuables et rétrocompatibles, en utilisant un processus de normalisation basé sur les risques. CycloneDX inclut les spécifications existantes telles que l'URL du package, les ID et expressions de licence CPE, SWID et SPDX. Les SBOM peuvent être représentés dans différents formats, notamment XML, JSON et Protocol Buffers (protobuf).
CycloneDX est une spécification SBOM légère destinée à être utilisée dans l'analyse des composants de la chaîne d'approvisionnement et la sécurité des logiciels. Il permet la communication de l'inventaire des composants logiciels, des services externes et des relations entre eux. Il s'agit d'un standard open source développé par l'OWASP (Open Web Application Security Project).
CycloneDX peut capturer la nature dynamique des composants open source dont le code source est accessible, modifiable et redistribuable. La spécification peut représenter le pedigree d'un composant, y compris ses ancêtres, descendants et variantes, décrivant la lignée du composant sous n'importe quel point de vue, ainsi que les validations, correctifs et différences qui le rendent unique.
Le projet CycloneDX maintient une liste d'outils open source et propriétaires connus qui prennent en charge ou sont compatibles avec la norme, qui est prise en charge par la communauté.
La spécification CycloneDX présente un modèle objet détaillé qui garantit la cohérence dans toutes les implémentations. Il peut être validé à l'aide du schéma XML et du schéma JSON, ou à l'aide de l'interface de ligne de commande CycloneDX. Des types de médias pour XML et JSON sont également fournis pour la livraison et la consommation automatisées des formats pris en charge.
Les SBOM CycloneDX peuvent contenir les informations suivantes : Métadonnées de nomenclature, composants, services, dépendances, compositions et extensions.
CycloneDX est une norme SBOM complète qui peut caractériser différents types de logiciels, notamment les applications, les composants, les services, les micrologiciels et les appareils. Il est largement utilisé dans tous les secteurs pour décrire des progiciels, des bibliothèques, des frameworks, des applications et des images de conteneurs. Le projet est compatible avec les principaux écosystèmes de développement et propose des implémentations d'usines logicielles telles que les actions GitHub, permettant aux organisations d'automatiser entièrement la création de SBOM.
Balise SWID
Les balises SWID, ou balises d'identification de logiciel, ont été créées pour permettre aux organisations de suivre de manière transparente les logiciels installés sur leurs appareils gérés. La norme a été établie par l'ISO en 2012 et révisée sous le nom d'ISO/IEC 19770-2:2015 en 2015. Ces balises contiennent des informations détaillées sur une version spécifique d'un produit logiciel.
La norme SWID décrit un cycle de vie pour le suivi des logiciels : une balise SWID est ajoutée à un point final lors de l'installation d'un produit logiciel et supprimée lors du processus de désinstallation du produit. L'existence d'un Tag SWID spécifique correspond directement à la présence du logiciel qu'il décrit. Plusieurs organismes de normalisation, tels que le Trusted Computing Group (TCG) et l'Internet Engineering Task Force (IETF), intègrent les balises SWID dans leurs normes.
Pour suivre le cycle de vie d'un composant logiciel, la spécification SWID dispose de quatre types de balises : primaire, correctif, corpus et supplémentaire. Les balises de corpus, primaires et de correctifs ont des objectifs similaires dans la mesure où elles décrivent l'existence et la présence de différents types de logiciels, tels que les installateurs de logiciels, les installations de logiciels et les correctifs logiciels, ainsi que les états possibles des produits logiciels. D'un autre côté, les balises supplémentaires fournissent des détails supplémentaires que l'on ne trouve pas dans les balises de corpus, primaires ou de patch.
Les balises supplémentaires peuvent être liées à n’importe quelle autre balise pour fournir des métadonnées supplémentaires qui peuvent être utiles. Ensemble, les balises SWID peuvent remplir diverses fonctions, telles que la découverte de logiciels, la gestion de la configuration et la gestion des vulnérabilités.
Les balises SWID peuvent fonctionner comme un SBOM, car elles fournissent des informations d'identification pour un composant logiciel, une liste de fichiers et de hachages cryptographiques pour les artefacts du composant, ainsi que des informations de provenance sur le créateur du SBOM (tag) et du composant logiciel. Les balises peuvent également être liées à d’autres balises, permettant une représentation d’un arbre de dépendances.
Les balises SWID peuvent être générées pendant le processus de construction et d'empaquetage, permettant la création automatique d'un SBOM basé sur des balises SWID lorsque le composant logiciel correspondant est empaqueté.
Pourquoi les nomenclatures logicielles sont-elles importantes ?
Les nomenclatures logicielles (SBOM) deviennent de plus en plus importantes pour les organisations qui visent à gérer et sécuriser les logiciels qu'elles utilisent. Il n'y a pas de réponse courte à la question de qu'est-ce qu'un SBOM. Les SBOM fournissent une liste complète de tous les composants et dépendances qui composent un progiciel, y compris des informations telles que les numéros de version, les auteurs et les informations de licence. Ces informations sont essentielles pour la sécurité et la conformité, ainsi que pour suivre la provenance des composants logiciels.
De nombreuses organisations, y compris celles des secteurs réglementés, utilisent les SBOM pour garantir la conformité aux réglementations telles que le Règlement général sur la protection des données (RGPD) et la norme de sécurité des données de l'industrie des cartes de paiement (PCI DSS). Les SBOM peuvent également aider à identifier et à gérer les vulnérabilités des logiciels, ainsi qu'à suivre la provenance des composants logiciels. De plus, les SBOM peuvent aider à la gestion des licences logicielles, garantissant que les organisations utilisent les logiciels conformément aux termes de leurs licences.
Les SBOM peuvent également être utilisés pour suivre l'utilisation de logiciels open source, qui deviennent de plus en plus courants dans le développement de logiciels. En fournissant des informations détaillées sur les composants open source utilisés dans un progiciel, les SBOM peuvent aider les organisations à garantir la conformité aux licences open source.
De plus, les SBOM peuvent être utilisés pour prendre en charge le développement et la maintenance de logiciels. En fournissant des informations détaillées sur les composants utilisés dans un progiciel, les SBOM peuvent aider les développeurs à comprendre les dépendances d'un progiciel, ce qui peut les aider à identifier les problèmes de compatibilité potentiels et à prendre des décisions éclairées concernant l'utilisation de nouveaux composants.