Les logiciels modernes reposent sur un empilement de dépendances, de composants open source, de bibliothèques tierces et, de plus en plus, de modèles d’intelligence artificielle et de sources de données externes. Pour les équipes de sécurité, savoir précisément ce qui fonctionne à l’intérieur d’une application relève désormais moins de la conformité que de la nécessité opérationnelle. C’est le principe de la SBOM (Software Bill of Materials, ou nomenclature logicielle).
- La SBOM liste les composants d’un logiciel et accélère la réaction aux failles.
- Le VEX indique si une vulnérabilité affecte réellement un produit.
- Les AI BOM documenteraient les modèles, les données et les sources externes de l’IA.
- La transparence aide surtout les défenseurs, qui doivent localiser les composants vulnérables.
Dans un récent épisode du SecurityWeek Podcast, l’animateur Brian « SchleiF » Schleifer a reçu Allan Friedman, expert en politique de cybersécurité, pour un échange sur les origines de la SBOM, son usage, l’émergence des AI BOM, la gestion des vulnérabilités ou encore le VEX. Friedman, qui a contribué aux premiers travaux gouvernementaux et industriels sur la SBOM, en donne une explication simple : « Le logiciel ne s’écrit pas, il s’assemble. De quoi est-il assemblé ? De logiciels. »
Une SBOM sert d’abord à réagir
Les premières discussions sur la SBOM portaient surtout sur la capacité des éditeurs à produire ces documents, et sur l’obligation, pour les clients, de les réclamer. Aujourd’hui, la question centrale est ce qui se passe après leur réception. Friedman considère que l’un des premiers signes de maturité de la chaîne d’approvisionnement logicielle est de savoir qu’un fournisseur peut générer une SBOM exacte.
Cette capacité devient décisive lors d’une vulnérabilité de type Log4j, de la compromission d’un grand paquet logiciel ou d’une mise à jour malveillante. Un fournisseur qui connaît ses composants peut mesurer son exposition bien plus vite que celui qui doit reconstituer ses dépendances en pleine crise. Pour les clients, cette visibilité peut raccourcir fortement le délai de réaction. Plutôt que de passer des jours, voire des semaines, à contacter des éditeurs, les équipes peuvent analyser directement leur inventaire logiciel.
Le VEX pour distinguer les vrais risques
Plus de visibilité entraîne aussi davantage d’alertes. Friedman met en avant le VEX (Vulnerability Exploitability eXchange), présenté comme un compagnon indispensable de la SBOM. Ce format permet de communiquer, de façon exploitable par des machines, si une vulnérabilité affecte réellement un produit. Une application peut embarquer une version vulnérable d’une bibliothèque sans jamais utiliser la fonctionnalité concernée. Le VEX apporte alors le contexte nécessaire pour distinguer la simple présence d’un composant vulnérable d’une situation réellement exploitable.
Friedman plaisante sur ce qu’il appelle le « vulnerpocalypse », un environnement où les équipes disposent de bien plus d’informations sur les failles que de ressources pour les examiner à la main. La combinaison SBOM et VEX vise donc à mieux hiérarchiser plutôt qu’à produire davantage de données.
L’IA ajoute de nouvelles questions
À mesure que les entreprises intègrent l’apprentissage automatique, l’IA générative et les agents autonomes dans leurs applications, les inventaires logiciels classiques peuvent ne plus suffire. Friedman juge inévitable l’apparition des AI BOM. Une IA reste un logiciel, mais elle introduit des éléments supplémentaires à documenter : le modèle lui-même, les données qui le soutiennent, les sources externes et l’infrastructure qui l’entoure.
Plusieurs questions se posent alors : d’où vient le modèle, quelles données ont servi à l’entraîner, quelles données externes sont introduites à l’exécution, qui en est le propriétaire, et que se passe-t-il lorsqu’un agent crée dynamiquement un outil, exécute une action, puis disparaît ? Selon Friedman, la réponse pourrait passer par un rapprochement entre les concepts de BOM, la journalisation, l’architecture de l’information et la gestion des risques liés aux tiers. L’objectif n’est pas de tout faire entrer dans une AI BOM, mais de disposer d’assez de transparence pour reconstituer les faits, contrôler les dépendances et mener, si nécessaire, une analyse forensique.
Enfin, Friedman conteste l’argument selon lequel la transparence profiterait aux attaquants. Il rappelle que la rétro-ingénierie permet déjà d’identifier de nombreux composants, et que les défenseurs, eux, doivent savoir où se trouvent les composants vulnérables sur des milliers de systèmes. « Vous savez qui a besoin de visibilité sur ce qu’il y a dans un logiciel ? La Blue Team », affirme-t-il, en désignant les équipes chargées de la défense. Il ajoute que la SBOM n’est pas censée résoudre tous les problèmes de cybersécurité : « C’est une donnée. Ce que les organisations en font est là où commence la valeur pour la sécurité. »
