SBOM pour l’IA : l’inventaire accélère l’alerte, sans remplacer l’analyse

Un SBOM pour l’IA sert à déterminer rapidement si un système contient un composant visé par une alerte de sécurité. Il associe composants, versions, dépendances et provenance à un système identifiable ; relié aux avis de vulnérabilité et aux déploiements, cet inventaire réduit le périmètre à examiner.

Il ne démontre toutefois ni que la faiblesse est exploitable dans l’environnement réel, ni que le risque justifie une interruption ou un correctif immédiat. Pour éviter cette confusion, il faut séparer trois couches : la composition déclarée, les dépendances effectivement déployées et le contexte d’exploitabilité.

Trois couches pour décrire un même système

La composition déclarée indique ce qui devrait former le système : logiciels, modèles, bibliothèques, images de conteneurs, services et artefacts associés. La couche du déploiement établit ce qui fonctionne réellement dans chaque environnement. La troisième décrit les conditions nécessaires pour qu’une vulnérabilité présente devienne exploitable.

Cette distinction traite deux écarts fréquents. Un composant déclaré pendant la construction peut être absent de l’artefact final ; une extension chargée au démarrage peut, à l’inverse, manquer dans le document produit en amont. Même lorsqu’une version vulnérable est confirmée, il reste à savoir si le code concerné est chargé, activé et atteignable.

La présentation de l’ANSSI définit précisément le SBOM pour l’IA comme une cartographie de la chaîne d’approvisionnement, des composants déployés et de leurs dépendances, conçue pour améliorer la transparence, la traçabilité et le temps de réaction face aux vulnérabilités.

Ce que la nomenclature doit inventorier

Le socle logiciel comprend le nom et la version de chaque composant, son fournisseur ou son auteur, un identifiant utilisable par les outils, sa provenance et ses relations avec les autres éléments. Il couvre notamment le système d’exploitation, les bibliothèques de calcul, le moteur d’inférence, les conteneurs, l’orchestrateur et les services externes indispensables.

La partie propre à l’IA doit rattacher les artefacts au logiciel qui les charge : modèle de base, variante ou point de contrôle, adaptation, fichiers de configuration et mécanisme de récupération. Les données utiles à la traçabilité peuvent inclure l’origine et la version des jeux de données, des index de recherche ou des extensions, sans nécessairement tout réunir dans un fichier unique.

Le critère décisif est la continuité des identifiants. Une entrée décrivant un modèle ou une bibliothèque doit pouvoir être rapprochée de l’artefact livré, du registre de déploiement et de l’actif en production. Les exclusions, dépendances inconnues et informations indisponibles doivent rester visibles : une lacune explicite vaut mieux qu’une apparence trompeuse d’exhaustivité.

Le déploiement réel doit rester vérifiable

Une nomenclature produite lors de la construction répond à la question « qu’avons-nous assemblé ? ». La réponse à une alerte exige aussi de localiser cet assemblage : version du service, image exécutée, environnement concerné, date de dernière observation et, lorsque cela compte, région ou parc de machines.

Le SBOM doit donc être régénéré après les changements qui modifient sa composition, puis associé à l’artefact correspondant. Une empreinte ou un autre identifiant immuable permet d’éviter qu’une nomenclature décrivant une version voisine soit utilisée pour juger le système en production. L’historique reste nécessaire pour retrouver les déploiements plus anciens encore actifs.

Les dépendances dynamiques réclament une attention distincte. Extensions activées après installation, modules téléchargés au démarrage et services appelés à distance ne sont pas toujours restitués par un relevé de construction. Un inventaire d’actifs ou des observations d’exécution doivent alors compléter le SBOM, sans être confondus avec lui.

De l’alerte à l’exploitabilité

Le gain de temps apparaît quand un avis de sécurité est automatiquement comparé aux SBOM conservés. Le résultat est une liste de composants, versions, produits et environnements potentiellement concernés. Cette correspondance accélère le tri ; elle ne constitue pas un verdict d’exposition.

L’analyse doit encore confirmer la présence dans l’artefact exécuté, le chargement du code vulnérable, la configuration requise et l’existence d’un chemin permettant à un attaquant d’atteindre la fonction. L’évaluation du risque ajoute ensuite la criticité du service, la sensibilité des données, les contrôles compensatoires, l’impact possible et les contraintes de l’organisation.

Dans son cadre destiné aux acheteurs fédéraux, le NIST recommande l’intégration aux alertes, les formats lisibles par machine et des référentiels signés. Il précise aussi que le SBOM complète la gestion des vulnérabilités et l’évaluation des fournisseurs au lieu de les remplacer, et que des données impossibles à ingérer, analyser puis convertir en action améliorent peu la gestion du risque.

Les contrôles qui rendent l’inventaire opérant

Un SBOM utile doit être géré comme un artefact vivant de la chaîne de livraison. Les contrôles portent autant sur la qualité de la nomenclature que sur son raccordement aux systèmes qui consomment ses données :

• Mise à jour : définir les modifications qui déclenchent une nouvelle génération et mesurer l’écart entre l’inventaire et l’exécution.
• Identifiants cohérents : conserver les mêmes références dans le SBOM, le registre d’artefacts, l’inventaire d’actifs et les avis de sécurité.
• Format lisible par machine : employer un format standard compatible avec l’ingestion, la comparaison et la surveillance automatisées.
• Intégrité : associer la nomenclature à l’artefact, vérifier son origine et la signer lorsque son authenticité doit être démontrée.
• Couverture explicite : signaler les dépendances inconnues, les composants non résolus et les exclusions de périmètre.
• Raccordement aux alertes : comparer les composants aux avis de vulnérabilité, puis transmettre les correspondances aux responsables des actifs concernés.
• Statut d’analyse : distinguer les éléments potentiellement affectés, non affectés, en cours d’examen et corrigés, avec une justification vérifiable.

La nomenclature répond ainsi à « de quoi le système est-il composé ? » et, une fois reliée au déploiement, à « où ce composant est-il utilisé ? ». L’exploitabilité, le niveau de risque et le choix entre correction, isolation, contrôle compensatoire ou acceptation temporaire restent des conclusions d’analyse. Le SBOM accélère l’arrivée de l’alerte au bon périmètre technique ; il ne prend pas la décision.