Par Phil Odence

Échange de données de progiciels® (SPDX®) est un format standard pour décrire une nomenclature logicielle qui prend en charge une gamme de cas d’utilisation, notamment les SBOM pour gérer les vulnérabilités de sécurité.

SPDX est un projet ouvert sous les auspices de la Fondation Linux depuis plus d’une décennie, tout le temps dans le but de décrire le contenu logiciel. Plus récemment, SPDX est devenu une norme ISO. (https://www.iso.org/standard/81870.html) Bien en avance sur son temps, SPDX a été initialement conçu dans un souci de conformité aux licences, mais est également devenu une norme pour la prise en charge des cas d’utilisation de la sécurité, comme le reconnaît la Cybersecurity and Infrastructure Security Agency (CISA).

Le cas d’utilisation le plus complexe consiste sans doute à inclure des informations de licence et de copyright sur les packages logiciels. En effet, la propriété légale peut s’appliquer au package, aux fichiers qu’il contient et même à une petite collection de lignes de code. Pour prendre pleinement en charge une telle utilisation, cette norme doit être capable de gérer la granularité, qui est également nécessaire pour certains cas d’utilisation de la sécurité. De plus, l’analyse juridique nécessite une liste standard et immuable de licences, leur texte et des moyens d’exprimer des situations de licence complexes. Ainsi, SPDX inclut une collection de licences (également adoptées par d’autres projets) et un langage d’expression de licence.

Dès le début du projet, certains coins se sont intéressés à une version plus légère et plus simple, permettant aux entreprises de commencer à fournir des informations sur les licences de packages dans un format standard. La norme a évolué pour spécifier un ensemble de base de champs obligatoires et une gamme de surensemble de champs facultatifs. Ce concept a jeté les bases des « profils » en cours de définition, différents ensembles de champs facultatifs et obligatoires requis pour un cas d’utilisation donné. Une autre dimension clé de l’évolution de SPDX a été l’ajout de relations et de références à des documents externes. Cela a été développé à l’origine avec l’idée de lier différents documents SPDX pour permettre, par exemple, à la structure d’une description SPDX de refléter la structure du logiciel qu’elle décrit. La capacité de base, cependant, permet de créer des liens vers d’autres types de documents et est essentielle pour la prise en charge des liens et le SBOM vers les informations de sécurité associées.

La montée récente de l’intérêt pour les SBOM s’est concentrée sur le cas d’utilisation de la sécurité, motivée par le climat général de risque de cybersécurité et, plus précisément, par l’intention du gouvernement américain d’exiger des SBOM des fournisseurs. SPDX évolue dans cette direction depuis un certain temps, et la spécification inclut la fonctionnalité pour la prendre en charge. En 2016, la version SPDX a publié la version 2.1, qui comprenait des champs de référence externes spécifiques pour les cas d’utilisation de la sécurité. La version 2.3 actuelle visait spécifiquement à augmenter la prise en charge de la sécurité, et un profil de clé prévu pour la version 3.0 cible ce cas d’utilisation.

SPDX utilise la capacité de référence externe de SPDX et ajoute de nouvelles catégories de référence pour prendre en charge la liaison aux documents de sécurité. L’annexe K de la spécification : Comment utiliser SPDX dans différents scénarios https://spdx.github.io/spdx-spec/v2.3/how-to-use/ entre dans les détails et fournit des exemples de liens vers diverses ressources liées aux vulnérabilités, notamment les CPE, les CVE, les informations VEX, y compris les informations de sécurité au format CSAF, les correctifs de code et d’autres informations. Il existe également une section mappant les éléments minimaux NTIA aux champs correspondants dans SPDX.

SPDX 3.0, actuellement en cours de développement actif, étend le concept de profils introduit dans la version 2.2 et en possède un spécifiquement conçu pour la sécurité. Avec la version 3.0, les documents SPDX intégreront davantage de contexte pour les données de sécurité liées, permettant ainsi l’efficacité de l’outil.

Les profils sont des ensembles de champs obligatoires et facultatifs pour un cas d’utilisation spécifique. Ainsi, la conformité d’un document à la spécification dépendra d’un cas d’utilisation. Par exemple, un SBOM axé sur la sécurité peut ne pas avoir les fonctionnalités requises pour se conformer au profil légal, mais en revanche, pourrait avoir tous les champs requis pour se conformer aux deux. Un profil de base comprendra un ensemble minimal d’éléments pour décrire un progiciel, correspondant à peu près à ce qui était précédemment appelé SPDX Lite. Au-delà de cela, il y aura alors plusieurs profils, y compris Sécurité, Juridique et autres, comme un pour les applications AI ou un qui inclut des informations de construction.

Une référence externe importante sera la documentation CISA Vulnerability Exploitability eXchange, une évaluation des vulnérabilités de leur logiciel, lisible par machine et fournie par le fournisseur. VEX est toujours un peu une cible mouvante, et de multiples « saveurs » semblent émerger sans qu’une norme ait été fixée. Dans tous les cas, SPDX 3.0 le supportera. De plus, sur la base des contributions de divers projets open source, le groupe envisage d’incorporer un ensemble simple d’éléments de sécurité minimaux en tant que champs SPDX facultatifs dans le profil de sécurité. Ce ne serait pas une nouvelle alternative à CSAF ou VEX mais plutôt un moyen léger pour les projets, non configurés pour aller en profondeur, de fournir les informations de sécurité de base communes à tous les formats de description de vulnérabilité.

Un défi demeure pour quiconque échange des SBOM (quel que soit le format) concernant le référencement sans ambiguïté d’éléments logiciels. Le « Log4j » d’un SBOM est le « Log4j d’Apache » d’un autre. C’est un problème similaire à celui résolu par SPDX pour les références de licence. Une analogie lâche : si les compagnies aériennes devaient partager les horaires de vol sans s’entendre sur la façon de se référer à Londres Heathrow, elles seraient inutiles. Cela ne peut pas être résolu localement sur SPDX, car il est nécessaire pour d’autres formats et applications. Le groupe pense qu’il peut y avoir une solution dans la combinaison de l’URL de package (PURL) pour les composants associés aux gestionnaires de packages et aux CPE et SWID pour les composants logiciels commerciaux. La prise en charge de GITBOM a également été ajoutée à SPDX 2.3, une autre solution possible pour identifier de manière unique les composants logiciels.

SPDX a démontré une base solide et la capacité d’évoluer pour répondre aux besoins changeants des utilisateurs. L’introduction de profils permet une flexibilité considérable. Récemment, une circonscription a lancé un profil de sécurité fonctionnelle (FuSa). Le sujet du matériel a également fait l’objet de discussions, et la spécification pourrait un jour être appelée System Package Data Exchange… SPDX.

Mythes SPDX

SPDX ne peut pas prendre en charge la sécurité.

Faux. SPDX prend actuellement en charge la liaison aux informations de sécurité, et cette capacité sera étendue à un plus large éventail de cas d’utilisation à l’avenir.

SPDX est vieux et compliqué.

Partiellement vrai. L’équipe dirait « bien établie ». « Complexe » pourrait être un meilleur mot que « compliqué », tout comme l’ensemble des problèmes qu’il traite. Et avec les champs facultatifs, SPDX Lite et les profils, cela peut être aussi simple que nécessaire tout en résolvant le problème. Les architectes de SPDX ont adopté une vision à long terme pour créer la flexibilité nécessaire pour gérer un avenir incertain.

SPDX n’est pas lisible par l’homme

Partiellement vrai. SPDX prend en charge divers formats, y compris une feuille de calcul très lisible par l’homme pour des exemples simples. Cela devient plus difficile avec XML et JSON, qui dépendent de l’humain. Mais la réalité est de décrire un logiciel de n’importe quelle taille et de faire quoi que ce soit d’utile avec l’information, les machines doivent être impliquées et les yeux humains ne feraient que ralentir le processus.

SPDX ne prend pas en charge VEX.

Surtout faux. Aujourd’hui, les documents SPDX peuvent faire des références externes aux documents VEX et VDR. Nous sommes dans le camp des personnes qui croient que c’est la meilleure façon de soutenir VEX. Étant donné que les SBOM et les connaissances sur les vulnérabilités des composants contenus évoluent à un rythme très différent, nous ne pensons pas qu’il soit logique de s’attendre à ce que les informations soient toujours incluses dans le document SBOM.

SPDX sert uniquement à la conformité des licences.

Faux. OK, cela dépend du moment où la déclaration a été faite. Il y a dix ans… C’est vrai.

SPDX n’est pas un format pour décrire les SBOM.

Faux. Il est.

SPDX ne peut pas décrire les nomenclatures matérielles.

Vrai… aujourd’hui. Le format est suffisamment flexible pour évoluer dans ce sens à l’avenir, et il est actuellement à l’étude.