Ce que vous devez savoir sur les nomenclatures logicielles

Le développement de logiciels modernes est incroyablement complexe. De nos jours, les logiciels sont toujours composés d’une combinaison de composants. Ces composants sont généralement des modules et des bibliothèques appelés par d’autres codes ou même des programmes autonomes qui sont utilisés conjointement avec d’autres programmes.

Jusqu’à il y a quelques années, la règle des 80/20 était valable : dans tout logiciel important, 80 % du contenu ne doit pas vous appartenir. Cela n’a aucun sens économique d’essayer de développer plus de 20% de n’importe quel logiciel car il est probable que quelqu’un ait déjà construit des composants avec les fonctionnalités nécessaires. Au lieu de cela, concentrez-vous sur le développement de ce qui vous donne un avantage concurrentiel. Ces dernières années, cet équilibre aurait même pu passer à 90/10.

C’est là qu’intervient la nomenclature logicielle (SBOM). Il s’agit d’un enregistrement formel contenant les détails et les relations de la chaîne d’approvisionnement de tous les composants utilisés dans la création de logiciels. Ces composants peuvent être open source ou propriétaires, disponibles gratuitement ou payants, largement disponibles ou à accès restreint. Les informations présentes dans un SBOM peuvent être utilisées de multiples façons, aidant à répondre à diverses questions contractuelles, légales ou techniques sur le logiciel.

Les premiers efforts pour fournir des SBOM étaient principalement motivés par le désir de se conformer à la loi. Chaque composant logiciel est sous licence spécifique, ce qui peut imposer certaines obligations quant à son utilisation. Pour être conforme à la loi, il faut satisfaire à toutes les obligations de toutes les licences. C’est simple, mais pas facile à réaliser. Une première étape évidente est d’avoir un enregistrement de tous les composants et de toutes les licences, ce qui est exactement ce qu’est un SBOM.

Cependant, au cours des deux dernières années, à la suite d’attaques de la chaîne d’approvisionnement logicielle, la force motrice derrière l’adoption de SBOM et la nécessité de connaître les composants exacts à l’intérieur de chaque logiciel ont été la sécurité. Les SBOM doivent désormais accompagner certains types de livraison de logiciels. Par exemple, le décret exécutif des États-Unis (EO) 14028 conseille aux agences gouvernementales américaines de commencer à exiger des SBOM pour tout produit matériel ou logiciel qu’elles acquièrent.

Qu’est-ce qu’une nomenclature logicielle (SBOM) ?

Au niveau conceptuel, un SBOM ressemble à une simple table des matières : il s’agit d’une liste complète de composants logiciels, avec des informations sur le nom, la version, l’origine et éventuellement des informations supplémentaires sur les licences, les vulnérabilités, la provenance ou tout autre domaine d’intérêt. Parce qu’elles sont facilement compréhensibles, ces informations peuvent être exprimées sous plusieurs formats : sous forme de tableau, de document texte, de tableur, etc. Pour que l’information soit utile, le même format doit être compris et accepté par les deux membres d’un échange.

Échange de données de progiciel (SPDX)

Il y a plus de dix ans, un groupe d’individus intéressés représentant diverses entreprises a commencé à travailler sur le problème de la définition d’un format commun et standardisé qu’ils ont appelé Software Package Data Exchange (SPDX). Tout le monde a convenu que cette norme ne devrait pas être un avantage concurrentiel pour une entreprise en particulier, de sorte que les travaux ont progressé en suivant complètement les principes de l’open source, avec une participation ouverte de tous ceux qui souhaitaient contribuer.

SPDX est une norme ouverte pour la communication des informations SBOM. L’année dernière, il a été ratifié comme norme internationale ISO/CEI 5962:2021. La spécification SPDX est produite de manière collaborative rassemblant un grand nombre de participants, organisés en groupes de travail selon leurs intérêts et leur expertise. Intel a participé activement à de nombreux groupes depuis le début, tels que l’équipe technique définissant la spécification SPDX, l’équipe juridique travaillant sur la liste des licences SPDX et l’équipe de sensibilisation promouvant l’utilisation de SPDX.

L’approche adoptée par SPDX est que les informations présentes dans un SBOM doivent être factuelles. Par exemple, il enregistre simplement la licence déclarée pour chaque composant logiciel et évite les interprétations juridiques des termes ou obligations de la licence. Une autre caractéristique importante de SPDX est que les informations peuvent être encodées dans une variété de formats, comme du texte pur avec une structure minimale, JSON, XML, RDF et même des feuilles de calcul.

La structure d’un document SPDX est hiérarchique. En plus des informations pertinentes pour le document lui-même, comme l’auteur et la date, les informations sont présentées à des niveaux de granularité croissante, correspondant à des packages, des fichiers ou des extraits. Presque toutes les informations à tous les niveaux sont facultatives, de sorte que l’on peut générer un SBOM donnant une vue générale ou contenant des informations dans des détails atroces. La flexibilité du format le rend idéal pour n’importe quel nombre de cas d’utilisation réels. Par exemple, un destinataire d’un SBOM peut ne s’intéresser qu’aux informations sur les failles de sécurité, tandis qu’un autre peut se soucier des licences sous lesquelles se trouvent les différents composants et des obligations légales qu’ils imposent.

Un certain nombre d’outils peuvent gérer les documents SPDX. En fonction de la fonctionnalité et du point précis de la chaîne d’approvisionnement logicielle où l’outil opère, on peut avoir une taxonomie complète des outils. Par exemple, le document SPDX peut être produit pendant la construction du logiciel ou il peut être généré ultérieurement en analysant le logiciel déjà construit. D’autres outils consomment ces informations et peuvent analyser, transformer, comparer ou fusionner des documents SPDX.

Des groupes de travail conçoivent actuellement la prochaine version majeure. SPDX version 3 est un effort majeur, restructurant les informations SBOM en sections modulaires et compartimentées. Cela permettra, par exemple, d’avoir un SBOM avec un accent particulier sur les informations de sécurité et de vulnérabilité et moins de contenu sur les détails de licence. Compte tenu des cas d’utilisation sans cesse croissants des SBOM, cette approche modulaire devrait se traduire par une adoption plus généralisée.

Intel prévoit d’introduire des SBOM pour accompagner ses offres logicielles en 2023. Pendant ce temps, les membres de ouvrir.intel continuera également à participer activement aux efforts de définition des nouvelles versions de SPDX.

Cet article est basé sur une conférence donnée récemment à la conférence sur le logiciel libre du Tyrol du Sud (SFScon), vous pouvez visionner la vidéo et visionner les diapositives ici.