Sécurité
SPDX : Software Package Data Exchange, format ouvert de description des composants logiciels porté par la Linux Foundation. « La liste des ingrédients imprimée au dos du logiciel, dans une langue que les machines savent lire », par analogie avec l'étiquette nutritionnelle, que personne ne lit jusqu'au jour où l'on cherche s'il y a des arachides dedans.
Ce qu'il décrit : Les paquets, fichiers et extraits qui composent un logiciel, leurs versions, leurs relations de dépendance, leurs empreintes cryptographiques et leurs licences. Un document SPDX est l'une des deux formes les plus répandues de SBOM, l'autre étant CycloneDX, projet de l'OWASP.
Normalisation : La version 2.2.1 de la spécification a été publiée comme norme internationale ISO/IEC 5962:2021. La version 3.0, parue en 2024, réorganise le modèle en profils (sécurité, construction, intelligence artificielle…), ce qui permet de tout décrire, y compris ce que personne n'a demandé.
Identifiants de licence : SPDX maintient aussi la liste officielle des identifiants de licence (MIT, Apache-2.0, GPL-3.0-or-later…). La ligne « SPDX-License-Identifier » placée en tête des fichiers source, notamment dans le noyau Linux, vient de là.
Limite : Un SBOM au format SPDX dit ce qui est présent, pas ce qui est vulnérable ni ce qui est réellement exécuté : il faut le croiser avec les bases de vulnérabilités, et le régénérer à chaque construction pour qu'il ne décrive pas un logiciel disparu.
Ce qui arrive si on s'en passe
Sans inventaire structuré, l'annonce d'une faille critique dans une bibliothèque répandue déclenche une chasse manuelle : chaque équipe fouille ses dépôts, ses images de conteneur et ses binaires fournis par des tiers, et répond « probablement pas » faute de mieux. Les composants embarqués de façon transitive restent invisibles et donc non corrigés. Face au Cyber Resilience Act, le fabricant ne peut pas démontrer qu'il connaît ce qu'il livre, ce qui est une position délicate pour quelqu'un qui en garantit la sécurité.
Explication de la marmotte
Un logiciel est souvent fabriqué avec des centaines de morceaux écrits par d'autres. SPDX est une façon standard d'écrire la liste de ces morceaux, avec leur version et leur licence, dans un fichier que les ordinateurs peuvent lire. Quand une faille est découverte dans l'un de ces morceaux, il suffit de chercher dans les listes pour savoir quels logiciels sont touchés. Sans cette liste, il faut tout vérifier à la main.
Où ce terme est utilisé
- Générer un SBOM CycloneDX dans un pipeline CI (3 occurrences)
- Maîtriser le risque des dépendances transitives (npm, pip, Maven, Go) (2 occurrences)
- SBOM pour inventorier les composants réellement exécutés (2 occurrences)
- Exigences CRA pour produits connectés sécurisés (1 occurrence)
- Formats, bibliothèques et API : rendre la crypto utilisable (1 occurrence)
- L'attaque de la chaîne d'approvisionnement logicielle en une page (1 occurrence)
- La chaîne d'approvisionnement logicielle (1 occurrence)
- SLSA : niveaux Build, provenance in-toto et vérification (1 occurrence)
