Nomenclature logicielle (SBOM)

Une nomenclature logicielle (SBOM) est un inventaire formel et lisible par une machine de chaque composant d'un logiciel : bibliothèques, versions, licences et informations sur les fournisseurs.

Tout comme une étiquette alimentaire énumère les ingrédients, une SBOM vous permet de répondre en quelques secondes à la question suivante : ce produit contient-il la version vulnérable de X ? Sans SBOM, cette réponse peut nécessiter plusieurs jours de recherche manuelle.

Lorsqu'une vulnérabilité critique est découverte, la première question opérationnelle porte sur l'exposition : lesquels de nos produits contiennent le composant concerné ?

Lors de l'incident Log4Shell, les organisations disposant de SBOM ont interrogé leur inventaire et effectué le triage en quelques heures. Celles qui n'en avaient pas ont passé des semaines à rechercher le composant dans leurs répertoires de compilation. Les autorités de réglementation et les grands acheteurs exigent de plus en plus des SBOM comme condition d'achat.

• Analyse rapide de l'impact des vulnérabilités
• Conformité des licences et suivi des obligations
• Transparence de la chaîne logistique pour les clients et les auditeurs

Deux normes ouvertes dominent. Les outils peuvent généralement convertir l'une dans l'autre.

• SPDX — une norme de la Linux Foundation, particulièrement adaptée aux licences et largement acceptée par les autorités de réglementation
• CycloneDX — une norme de l'OWASP, axée sur la sécurité, qui prend en charge les données sur les vulnérabilités et les relations entre dépendances

Évitez d'inventer votre propre format ; les utilisateurs et les outils d'analyse s'attendent à trouver ceux-ci.

Chaque entrée de composant doit contenir suffisamment d'informations d'identité pour être comparée aux flux de vulnérabilités. Les champs essentiels sont les suivants :

• nom et version — exacts, et non une plage
• PURL (adresse de paquet) — un identifiant universel tel que pkg:npm/lodash@4.17.21
• hachage — pour vérifier l'intégrité
• licence — identifiant de licence SPDX
• fournisseur — celui qui l'a produit

Générez automatiquement les SBOM à partir du code source ou d'un artefact compilé. Syft est un générateur courant compatible avec plusieurs écosystèmes, qui produit les deux formats standard.

Une SBOM générée à différentes étapes décrit des réalités différentes.

• SBOM du code source — ce que déclare le manifeste ; peut omettre le code regroupé ou intégré localement
• SBOM de compilation — ce que la compilation a réellement récupéré ; la plus précise pour une version livrée
• SBOM d'exécution / déployée — ce qui est réellement présent dans l'image exécutée, y compris les paquets de l'OS

Pour garantir la sécurité de la chaîne logistique, générez-la au moment de la compilation à partir de l'artefact réel et analysez également le conteneur final pour détecter les paquets de l'OS.

Une SBOM devient particulièrement utile lorsqu'elle est fournie à un outil de mise en correspondance qui relie les composants aux CVE connues. Cela dissocie la génération de l'analyse : vous pouvez analyser une ancienne SBOM le jour où une nouvelle CVE est publiée.

Une SBOM peut révéler un composant vulnérable qui n'est pas réellement exploitable dans votre produit (la fonction vulnérable n'est jamais appelée). Un document VEX (eXchange sur l'exploitabilité des vulnérabilités) consigne cette évaluation.

VEX réduit le bruit : au lieu de voir chaque client paniquer à cause d'une CVE répertoriée, vous publiez une déclaration de not_affected avec sa justification, ou de affected avec les mesures correctives. Cela transforme un inventaire brut en analyse exploitable.

Une SBOM n'est digne de confiance que si elle est authentique et liée à l'artefact exact qu'elle décrit. Signez-la et joignez-la comme attestation plutôt que de la conserver dans un fichier isolé.

Les SBOM générées manuellement deviennent immédiatement obsolètes. Intégrez la génération à la chaîne de traitement afin que chaque version en produise et en stocke une comme artefact de compilation, idéalement signée et analysée dans la même tâche.

• Générez-la à partir de l'artefact compilé, et pas seulement du dépôt
• Stockez les SBOM dans un registre interrogeable, indexé par version
• Réanalysez régulièrement les SBOM stockées en les comparant aux flux de CVE actualisés
• Conditionnez les mises en production au résultat de l'analyse des vulnérabilités

Les SBOM échouent discrètement lorsqu'elles sont traitées comme une simple case à cocher.

• Obsolète — générée une fois et jamais régénérée
• Incomplète — omet les paquets de l'OS ainsi que le code lié statiquement ou intégré localement
• Non vérifiée — aucun hachage ne la relie à l'artefact déployé
• Inutilisée — produite, mais jamais analysée ni interrogée

Le but est d'obtenir une SBOM exacte, régénérée, signée et analysée en continu, et non un simple fichier JSON ponctuel.

Vous pouvez désormais inventorier le contenu de votre logiciel et agir en conséquence.

• Une SBOM est une liste lisible par une machine de chaque composant, au format SPDX ou CycloneDX
• Identifiez les composants par leur PURL, leur version, leur hachage et leur licence
• Générez-la au moment de la compilation, puis fournissez-la à un outil de mise en correspondance (grype, osv-scanner) pour rechercher les CVE
• Utilisez VEX pour déclarer l'exploitabilité réelle et réduire les fausses alertes
• Signez et automatisez le processus dans l'intégration continue ; réanalysez les SBOM stockées en les comparant aux nouveaux flux

Ensuite : prouver l'origine des artefacts grâce à la signature.