Nomenclatures logicielles (SBOM) : l'inventaire de sa propre chaîne d'approvisionnement

Ce que c'est

Une nomenclature logicielle (Software Bill of Materials, SBOM) est la liste des pièces d'un produit logiciel : paquets, versions, fournisseurs, licences, sommes de contrôle et relations entre eux (« contient », « dépend de »). Deux formats se sont imposés. SPDX, de la Linux Foundation, est, selon les indications de la page du projet, une norme internationale librement accessible enregistrée sous ISO/IEC 5962:2021 ; ses racines se trouvent dans la gestion des licences. CycloneDX est un projet OWASP, standardisé sous ECMA-424 selon la page du projet, qui décrit, outre la SBOM, des nomenclatures pour les services, le matériel et la cryptographie, ainsi que le Vulnerability Exploitability eXchange (VEX) — un document par lequel un éditeur indique si une vulnérabilité signalée dans son produit est réellement exploitable. En complément, le cadre SLSA décrit des niveaux de preuve de provenance : une déclaration indiquant quel build, à partir de quelle source, a produit l'artefact.

Pourquoi c'est important

Lorsqu'une vulnérabilité est découverte dans une bibliothèque répandue, la première question est : où cette version tourne-t-elle ? Sans nomenclature, la réponse consiste à reconstruire et fouiller tous les projets ; avec une nomenclature, c'est une simple requête sur des fichiers déjà archivés. Le même inventaire répond aux questions de licence (mention d'attribution, copyleft) et est, selon des rapports largement répandus, de plus en plus exigé comme livrable. Une nomenclature seule ne dit toutefois pas si un composant est resté inchangé et provient bien de la source attendue ; c'est le rôle de la preuve de provenance.

Comment l'appliquer

• Produire la nomenclature lors du processus de publication, et à partir de l'artefact construit (image de conteneur, wheel, JAR), pas seulement du fichier manifeste : c'est le seul moyen de faire apparaître l'image de base, les paquets système et les regroupements que le manifeste ignore.
• Fixer un format en interne et exporter l'autre au besoin ; les deux projets tiennent à jour des listes d'outils et des convertisseurs.
• Conserver le fichier à côté de l'artefact, avec le même identifiant de version, et le signer lorsque les artefacts sont signés.
• Confronter régulièrement les nomenclatures de toutes les versions livrées aux bases de données de vulnérabilités ; consigner sous forme d'attestation VEX les correspondances qui, après vérification, ne sont pas exploitables, afin de ne pas réévaluer chaque semaine la même correspondance.
• Formuler les règles de licence comme un contrôle automatique portant sur la nomenclature (licences autorisées, à vérifier, interdites).
• Conserver les fichiers de verrouillage et les installations vérifiées par empreinte ; la nomenclature documente, elle n'impose rien.

Pièges

Une nomenclature produite à partir du manifeste source s'écarte du contenu réel de l'image. Les nomenclatures vieillissent : elles ne valent que pour un build précis, pas pour « l'application » en général. Les outils ne détectent souvent pas les bibliothèques copiées directement dans le dépôt ou renommées. Une correspondance trouvée lors de la confrontation est une question, pas un diagnostic — seule la vérification que le chemin vulnérable est réellement atteignable dans son propre produit détermine l'urgence, et c'est précisément à cela que sert VEX.