Une vulnérabilité grave touche une bibliothèque largement utilisée. L’entreprise demande à ses prestataires s’ils sont concernés. Les réponses arrivent progressivement : « analyse en cours », « probablement pas », « notre produit est sécurisé ». Pendant ce temps, personne ne dispose d’une liste suffisamment précise pour rechercher le composant dans les versions réellement déployées.
La SBOM, nomenclature des composants logiciels, vise à réduire cette incertitude. Elle décrit ce qui entre dans un logiciel ou un artefact donné. Mais recevoir un fichier ne suffit pas. Il faut pouvoir le relier à une version, interpréter ses identifiants et transformer les alertes en décisions.
L’intérêt opérationnel n’est donc pas de collectionner des inventaires. C’est de raccourcir le chemin entre une information sur une dépendance et une action proportionnée sur votre système.
En bref — Une SBOM décrit des composants et leurs relations pour un périmètre identifié. Elle n’est ni un audit de sécurité ni une garantie d’absence de vulnérabilité. Sa valeur dépend de sa fraîcheur, de sa traçabilité jusqu’au déploiement et du processus de traitement des alertes. Une information VEX peut préciser l’impact d’une vulnérabilité, mais doit elle aussi être vérifiable et actualisée.
Choisir l’objet que vous voulez réellement inventorier
Un logiciel peut être livré sous plusieurs formes : code source, paquet compilé, image de conteneur, installateur ou application hébergée. Les composants visibles ne sont pas forcément identiques à chaque étape. Une dépendance de compilation peut ne pas être présente dans l’artefact final ; une image peut inclure des paquets système absents de la liste du projet.
La première question consiste donc à nommer le périmètre. Cherchez-vous les bibliothèques de l’application, les composants du système embarqué, les modules réellement distribués ou l’ensemble des services nécessaires à l’exploitation ? Un inventaire doit dire ce qu’il couvre et ce qu’il ne couvre pas.
Associez chaque document à un produit, une version et, si possible, un identifiant d’artefact suffisamment précis. Une étiquette « version actuelle » devient rapidement ambiguë lorsque plusieurs environnements utilisent des versions différentes. Un hash ou un identifiant de build aide à distinguer les objets sans dépendre seulement d’un nom commercial.
L’inventaire de production reste indispensable. Une SBOM décrit un artefact ; elle ne prouve pas à elle seule qu’il est effectivement déployé sur vos systèmes. Il faut pouvoir relier les environnements, les versions actives et les documents correspondants.
Ce principe vaut particulièrement lorsque l’entreprise utilise des conteneurs. Les questions d’exploitation posées dans notre guide Kubernetes pour les PME incluent justement la maîtrise des images et de leur cycle de vie, pas seulement l’orchestration.
Les champs utiles avant le choix du format
Des formats comme SPDX et CycloneDX structurent les échanges. Leur usage facilite l’intégration avec des outils, mais ne rend pas automatiquement le contenu exhaustif. Il faut aussi préciser la version du format et les profils supportés par vos systèmes.
Pour une première démarche, concentrez-vous sur les informations nécessaires aux investigations : nom du composant, version, fournisseur lorsqu’il est connu, identifiants techniques, relations de dépendance et contexte de génération. Les empreintes et les références de paquet peuvent aider à réduire les ambiguïtés.
| Information | Utilité opérationnelle | Erreur fréquente |
|---|---|---|
| Version du produit livré | Relier le document au déploiement | Document conservé sans correspondance précise |
| Nom et version du composant | Rechercher une dépendance affectée | Nom abrégé ou version manquante |
| Relation entre composants | Comprendre les dépendances indirectes | Liste aplatie qui masque le contexte |
| Identifiant de paquet ou empreinte | Réduire les confusions d’identification | Correspondance fondée seulement sur un nom |
| Date et méthode de génération | Évaluer la fraîcheur et les limites | Inventaire manuel ancien présenté comme actuel |
Les licences peuvent également être présentes et utiles pour leur propre gouvernance. Une information de licence ne résout toutefois pas une vulnérabilité. Les processus juridiques et de sécurité peuvent utiliser la même base tout en gardant des critères différents.
N’imposez pas des champs que personne ne saura maintenir. Mieux vaut définir un socle exploitable, identifier les inconnues et progresser vers une meilleure couverture que recevoir un document riche en apparence mais rempli de valeurs approximatives.
Générer au bon moment, conserver au bon endroit
Une génération liée à la construction du logiciel permet de suivre les versions livrées plus régulièrement qu’un inventaire ponctuel. Elle doit toutefois tenir compte des composants effectivement présents dans l’artefact et des limites de l’outil utilisé.
Le pipeline peut produire un document, le valider structurellement puis l’associer à la livraison. Conservez l’artefact, sa nomenclature et les informations permettant de retrouver leur provenance. Un contrôle d’intégrité peut signaler qu’un fichier a changé ; il ne démontre pas que son contenu était complet à l’origine.
Pour un produit acheté, précisez les modalités de réception avec le fournisseur : cadence, versions concernées, format, canal de transmission et point de contact. Demandez comment une correction de l’inventaire sera diffusée après livraison. La procédure doit rester praticable lors d’un incident.
Les informations peuvent révéler une partie de l’architecture. Organisez leur accès et leur conservation selon le contexte, plutôt que de déposer tous les documents sur une page publique par défaut. La protection de cette information ne doit pas empêcher les équipes autorisées de s’en servir.
Dans le cas d’un SaaS, vous n’aurez pas nécessairement accès à l’inventaire complet de l’infrastructure du fournisseur. Les engagements attendus peuvent alors porter sur le périmètre communiqué, les délais de réponse et la traçabilité des versions. Il faut distinguer ce qui est contractuellement prévu de ce qui reste inconnu.
Une correspondance de vulnérabilité est le début de l’enquête
Un outil rapproche des composants et des avis de sécurité. Cette opération peut produire des alertes pertinentes, mais aussi des ambiguïtés : même nom pour plusieurs projets, version mal normalisée, paquet modifié ou dépendance non utilisée dans le chemin concerné.
La première étape est de confirmer l’identification. Le composant signalé correspond-il réellement à celui qui est livré ? La plage de versions affectées s’applique-t-elle ? Le fournisseur a-t-il apporté une correction sans changer de numéro de version apparent ? Chaque réponse doit reposer sur une information documentée.
Vient ensuite l’analyse d’exposition. Le composant est-il accessible depuis une zone exposée ? La fonction vulnérable est-elle activée ? Quels privilèges sont nécessaires ? Existe-t-il une exploitation connue ou des mesures temporaires adaptées ? Le score de sévérité aide à comparer les conséquences potentielles, mais ne décrit pas seul votre contexte.
Il faut éviter deux raccourcis. « Le composant est présent » ne prouve pas automatiquement que toutes les conditions d’exploitation sont réunies. « Nous n’utilisons pas cette fonction » ne suffit pas non plus si personne n’a vérifié les chemins d’exécution et la configuration réelle.
Une priorité doit combiner les éléments disponibles et l’incertitude restante. Lorsque l’entreprise ne peut pas confirmer l’exposition d’un système critique, cette inconnue peut justifier une investigation rapide. L’absence de réponse n’est pas une preuve d’absence de risque.
Utiliser le VEX sans transformer une affirmation en exemption
Un document VEX, pour Vulnerability Exploitability eXchange, peut transmettre une information sur l’état d’un produit vis-à-vis d’une vulnérabilité : affecté, non affecté, corrigé ou encore en investigation, selon le modèle utilisé. Il apporte un contexte que la liste de composants ne contient pas nécessairement.
La valeur de cette information dépend de son périmètre et de sa justification. « Non affecté » doit être rattaché à un produit et à une version précis, avec une raison exploitable. Une phrase générale sur toute une gamme ne suffit pas pour conclure sur votre installation.
Conservez l’émetteur, la date et les conditions qui fondent l’affirmation. Une justification liée à une fonction désactivée peut perdre sa validité si une configuration change. Une correction documentée doit être rapprochée de la version effectivement installée.
Le VEX n’a donc pas vocation à supprimer aveuglément les alertes. Il aide à prendre une décision et à expliquer pourquoi elle a été prise. La réévaluation reste nécessaire lorsque les hypothèses changent ou que de nouvelles informations apparaissent.
Donner un propriétaire à chaque décision
L’inventaire traverse plusieurs responsabilités : développement, infrastructure, achats et fournisseurs. Sans répartition, chacun peut supposer que l’autre traite l’alerte. Définissez une file de traitement avec un responsable, une échéance et une preuve attendue.
Pour chaque cas, consignez le produit, la version, la vulnérabilité, le niveau d’exposition connu et l’action retenue. L’action peut être une mise à jour, une restriction temporaire, une investigation supplémentaire ou une acceptation documentée du risque. Les reports doivent avoir une date de réexamen.
La mise à jour demande parfois des essais de compatibilité et un retour arrière. Elle doit rester reliée aux objectifs de service, comme dans la politique de budget d’erreur et de disponibilité. Corriger sans préparer l’exploitation peut déplacer le risque au lieu de le réduire.
Une preuve de correction peut être la version déployée, le résultat d’un contrôle et la fermeture motivée du dossier. L’absence de nouvelle alerte dans un tableau n’est pas toujours une preuve suffisante : un changement de configuration de l’outil peut aussi la faire disparaître.
Mesurer la couverture sans fabriquer un taux rassurant
Un inventaire de 120 composants dont 109 possèdent une version complète affiche une complétude de 90,83 % pour ce champ et ce périmètre. Ce chiffre ne signifie pas que 90,83 % de tout le patrimoine logiciel est connu. Les composants non découverts ne figurent pas au dénominateur.
Autre exemple fictif : sur 100 applications identifiées, 30 disposent d’un inventaire actuel, 20 d’un inventaire ancien et 50 d’aucun document exploitable. La couverture actuelle est de 30 %. Regrouper les 20 anciennes avec les 30 actuelles produirait une présentation plus flatteuse, mais masquerait la fraîcheur.
Choisissez donc plusieurs indicateurs simples : applications couvertes par version active, âge des documents, proportion de composants identifiés et délai de réponse aux demandes. Ajoutez des mesures de traitement : temps de qualification, dossiers en attente et corrections confirmées.
Le nombre d’alertes clôturées demande la même prudence. Dans un scénario fictif, 20 alertes comprennent huit doublons, quatre correspondances non confirmées et huit corrections nécessaires. Fermer les douze premiers dossiers ne signifie pas avoir corrigé douze vulnérabilités. La catégorie de clôture doit rester visible.
Présentez ces mesures avec leur définition et leurs limites. Une tendance n’est comparable que si le périmètre reste stable ou si son évolution est expliquée. L’ajout de nouveaux produits peut faire baisser la couverture affichée tout en améliorant la connaissance du patrimoine. C’est une progression opérationnelle, pas nécessairement une dégradation de la sécurité.
Une première mise en œuvre à taille raisonnable
Choisissez quelques produits importants et accessibles à l’équipe. Pour chacun, retrouvez la version active, obtenez ou générez une nomenclature et testez sa lecture. Simulez ensuite une recherche de composant et une alerte afin de vérifier les délais et les responsabilités.
Le livrable utile est modeste : inventaire de périmètre, documents associés, procédure de qualification et dossier de décision. Il permet de mesurer les obstacles : fournisseur lent, format non supporté, dépendance sans version ou environnement sans référence de déploiement.
Élargissez ensuite selon la criticité, en automatisant les opérations répétitives. La gestion des reprises et doublons dans les processus automatisés peut aider pour l’ingestion des documents et la création des dossiers, sans déléguer automatiquement les décisions de risque.
Poser les bonnes questions lors d’un achat logiciel
La SBOM peut entrer dans une discussion fournisseur sans devenir une exigence formelle impossible à exploiter. Demandez d’abord quel produit et quelle livraison le document couvre, qui le génère et comment il est mis à jour. Une réponse précise sur un périmètre limité vaut mieux qu’une promesse d’exhaustivité non démontrée.
Prévoyez ensuite un test de réception. Le fichier est-il lisible par votre chaîne ? Les identifiants permettent-ils de reconnaître les composants ? La version livrée correspond-elle au document ? Une clause générale sur la fourniture d’une nomenclature ne résout pas ces questions d’intégration.
La communication lors d’une vulnérabilité mérite son propre engagement. Quel interlocuteur répond ? Peut-il préciser l’impact sur une version, fournir une justification et indiquer une correction ? Un prestataire doit pouvoir expliquer ses conclusions sans se limiter à une formule commerciale sur la sécurité du produit.
Comparez enfin le coût de traitement avec les moyens de l’équipe. Recevoir des milliers d’alertes sans responsable de qualification ne crée pas une capacité de gestion. Un service d’accompagnement peut être utile, mais ses décisions doivent rester traçables : éléments examinés, statut retenu et critères de priorité.
La lecture des clauses et du coût total d’un achat SaaS aide à intégrer cette capacité dans la comparaison des offres. Le livrable attendu n’est pas seulement un fichier à la signature. C’est une information maintenue et utilisable pendant la vie du produit, avec un chemin de réponse lorsque le risque change.
La SBOM apporte finalement une capacité d’enquête plus précise. Elle ne remplace ni le développement sécurisé ni la maîtrise des accès, mais elle réduit le temps perdu à chercher ce qui compose un produit. Son succès se mesure au moment où une nouvelle alerte arrive : l’entreprise sait retrouver les systèmes concernés, vérifier le contexte et démontrer ce qu’elle a décidé.
Je suis Romain, rédacteur passionné par tout ce qui touche au high-tech, à la crypto, et à l’innovation. Diplômé d’une école de marketing à Paris, je mets ma plume au service des dernières tendances et avancées technologiques.
