Pourquoi les risques liés à la chaîne d’approvisionnement de l’IA dépassent le modèle SBOM

Pendant des années, les nomenclatures logicielles reposaient sur des hypothèses généralement valables. Les dépendances étaient statiques. Les cycles de publication étaient prévisibles. En répertoriant les éléments intégrés à une application au moment de sa compilation, les équipes pouvaient prendre ensuite des décisions éclairées en matière de risques. Cette approche fonctionnait parce que les logiciels traditionnels se comportaient de manière prévisible, dans un périmètre bien défini. L’IA remet presque immédiatement ces hypothèses en question.

Les chaînes d’approvisionnement de l’IA évoluent rapidement. De nouveaux modèles open source apparaissent du jour au lendemain. Les frameworks d’agents évoluent dans des dépôts publics plus vite que la plupart des équipes de sécurité ne peuvent les suivre. Les serveurs MCP, les prompts, les jeux de données et les outils d’orchestration changent constamment au gré des expérimentations des développeurs. Le rythme n’est pas seulement plus rapide : il est fondamentalement différent.

Les composants d’IA ne sont pas non plus des éléments passifs. Ils façonnent activement le système pendant son exécution. Les modèles peuvent faire appel à de nouveaux outils à l’exécution. Les agents génèrent des prompts, enchaînent des actions et invoquent des services qui n’étaient pas définis dans le code d’origine. Les composants créent à la volée de nouvelles relations et de nouveaux chemins d’exécution : la chaîne d’approvisionnement n’est donc plus figée au moment de la compilation.

C’est là que le modèle SBOM commence à montrer ses limites. Une liste statique de composants ne peut pas représenter un système qui évolue en fonctionnement. Les équipes de sécurité ont besoin de plus qu’un instantané de ce qui existait au moment du commit. Elles doivent voir comment les composants d’IA interagissent, quels éléments ils appellent et comment ces relations évoluent.

C’est ce besoin qui a donné naissance à l’idée d’une nomenclature des composants d’IA. Mais le terme peut prêter à confusion. Une AIBOM n’est pas une liste de contrôle. C’est une cartographie vivante des composants, des comportements et des connexions, qui reflète le fonctionnement réel des systèmes d’IA. Les artefacts statiques ne suffisent plus lorsque le logiciel est conçu pour évoluer.

Le problème s’amplifie : la moitié de la chaîne d’approvisionnement de l’IA se trouve hors des dépôts de code

Dès lors que l’on admet que les chaînes d’approvisionnement de l’IA sont dynamiques, un autre problème apparaît. Le contenu du dépôt ne représente qu’une partie de la situation. Une part croissante de la chaîne d’approvisionnement de l’IA n’est jamais intégrée au contrôle de version : elle s’exécute sur les machines des développeurs.

Les développeurs installent et testent des outils d’IA localement, souvent plus vite que les équipes de sécurité ne peuvent les suivre. Dans une grande entreprise de médias, les équipes ont mis en place des serveurs MCP locaux pour gagner en rapidité, avant de découvrir que l’équipe sécurité ne savait ni où ils se trouvaient ni aux données auxquelles ils accédaient. Dans une société d’investissement internationale, des développeurs ont testé localement des agents d’IA et des outils d’automatisation disposant d’un large accès aux systèmes internes, sans examen préalable. Dans une autre grande entreprise, l’utilisation d’outils MCP locaux était officiellement interdite, mais les développeurs ont continué à s’en servir, car ils leur facilitaient le travail.

Ce comportement n’est pas malveillant : il est pragmatique. Les développeurs utilisent les outils qui les aident à résoudre des problèmes. Le risque apparaît lorsque ces outils fonctionnent en dehors des contrôles sur lesquels s’appuient les équipes de sécurité.

Les agents d’IA locaux et les serveurs MCP ont souvent un accès direct aux pipelines, aux identifiants et aux services internes. Les données peuvent circuler sans documentation ni supervision. Comme ces composants ne passent jamais par les workflows CI/CD, SAST ou SCA, leur comportement reste largement invisible, alors qu’ils ne sont qu’à un ordinateur portable de la production.

Cette évolution a rendu le Shadow IT plus complexe. Le Shadow IT concernait les solutions SaaS non approuvées. Le Shadow AI englobe les modèles, outils locaux, serveurs MCP, agents et frameworks expérimentaux non approuvés qui s’exécutent sur les postes des développeurs. Il est local, évolue rapidement et dépend des individus plutôt que des achats.

Résultat : le manque de visibilité s’accentue. Même la vue la plus complète d’un dépôt ne révèle pas les composants d’IA qui n’y sont jamais intégrés. À mesure que le développement de l’IA s’accélère, les machines des développeurs sont devenues l’un des éléments les moins bien compris de la chaîne d’approvisionnement de l’IA.

Pourquoi l’AI-BOM ne suffit pas à résoudre le problème (mais constitue un début)

Une nomenclature des composants d’IA apporte une structure essentielle aux systèmes d’IA modernes. Elle offre une visibilité sur les modèles référencés dans le code source, les frameworks d’agents présents dans les dépôts, les configurations de serveurs MCP, les prompts, les jeux de données et les dépendances déclarées. Pour les composants d’IA intégrés au code, examinés et versionnés, cette visibilité est précieuse.

Cette visibilité établit une base de référence. Elle permet aux équipes de sécurité de passer des suppositions aux faits et de commencer à encadrer l’utilisation de l’IA en toute confiance. Dans le contrôle de version, l’AI-BOM donne une vue claire des éléments présents et de leurs liens. Sa limite concerne ce qui n’atteint jamais le dépôt.

L’AI-BOM ne peut pas détecter les chaînes d’outils MCP locales sur les machines des développeurs, les environnements d’exécution d’agents d’IA utilisés pour les tests, les clients LLM installés sur les postes, ni les outils CLI et frameworks agentiques que les développeurs expérimentent localement. Beaucoup de ces outils ne sont jamais intégrés à GitHub.

Cela crée un angle mort. La visibilité basée sur les dépôts reflète les intentions, pas tout ce qui s’exécute réellement pendant le développement. Dès que les outils d’IA dépassent le périmètre de CI/CD et de l’analyse traditionnelle pour s’étendre aux ordinateurs portables, ils échappent à l’AIBOM, alors que ces composants ont souvent accès à des données sensibles et à des systèmes internes.

L’AIBOM ne suffit pas à résoudre le problème. C’est un point de départ indispensable, mais elle ne raconte qu’une partie de l’histoire. Lorsque les outils d’IA fonctionnent en dehors du dépôt, une part importante des risques s’y trouve également.

La solution : unifier l’AI-BOM et la visibilité sur les postes des développeurs

Combler l’écart entre les dépôts et les machines des développeurs ne nécessite pas d’ajouter de contraintes. Il faut adopter un autre modèle de visibilité. Plutôt que d’ajouter des agents lourds sur les postes ou d’imposer de nouveaux workflows, l’approche émergente consiste à mettre en corrélation les informations existantes dans différents environnements.

La détection AIBOM basée sur les dépôts reste efficace dans son domaine de prédilection : identifier les modèles, les frameworks d’agents, les prompts, les jeux de données et les configurations dans le contrôle de version. Une analyse légère des machines des développeurs vient la compléter en révélant les serveurs MCP locaux, les environnements d’exécution d’agents et les outils d’IA effectivement utilisés. Ces analyses sont conçues à cet effet et ciblent un périmètre précis ; il ne s’agit pas d’une surveillance classique des postes. Ensemble, elles offrent une vue cohérente de la chaîne d’approvisionnement de l’IA telle qu’elle existe concrètement.

Cette vue unifiée répond aux attentes des clients. Certains veulent suivre les mêmes frameworks MCP dans les dépôts et les environnements locaux. D’autres souhaitent disposer d’un point unique pour répondre à une question simple : quels composants d’IA sont utilisés dans l’organisation, où que ce soit ? Beaucoup veulent des garde-fous qui favorisent une utilisation sûre sans interdire les outils ni perturber les workflows des développeurs.

La force de cette approche tient au fait que la visibilité devient le moyen de contrôle. Lorsque les équipes peuvent visualiser les composants présents, leurs liens et les environnements où ils s’exécutent, la gouvernance devient concrète. Les politiques peuvent porter sur les outils approuvés, les configurations sûres et la cohérence des versions, plutôt que sur des restrictions que les développeurs contournent.

La gestion de la posture de sécurité de l’IA fournit la couche unificatrice. Elle rassemble dans une vue unique les informations issues des dépôts, les relations entre dépendances, la détection des serveurs MCP et des agents locaux, ainsi que les politiques de gouvernance. Le résultat n’est pas un contrôle renforcé par la contrainte, mais un meilleur contrôle grâce à une compréhension approfondie, qui permet aux organisations d’encadrer l’IA de manière responsable à mesure qu’elle évolue.

La proposition de valeur combinée : une vue complète de votre chaîne d’approvisionnement de l’IA

Lorsque la visibilité couvre à la fois les dépôts et les machines des développeurs, la chaîne d’approvisionnement de l’IA devient enfin plus claire. Le code, à lui seul, ne raconte jamais toute l’histoire. Les expérimentations locales ne montrent pas comment les systèmes sont formalisés et déployés. Réunir les deux offre une vue complète de la manière dont l’IA est réellement développée, testée et utilisée dans toute l’organisation.

La plupart des outils de sécurité ne voient qu’un seul côté de la situation. Certains se concentrent sur ce qui est intégré au contrôle de version. D’autres observent des signaux d’exécution isolés ou l’activité des postes. La gestion de la posture de sécurité de l’IA relie ces différentes vues. Elle identifie ce qui se trouve dans le code et ce qui s’exécute sur les postes des développeurs, puis met ces éléments en corrélation dans un modèle unique et cohérent. Cette perspective combinée transforme des signaux fragmentés en informations exploitables.

C’est important, car les restrictions se sont révélées inefficaces. Interdire les serveurs MCP ne suffit pas à empêcher leur utilisation. Interdire les agents locaux ne fait que rendre les expérimentations moins visibles. Les développeurs continueront à adopter les outils qui les aident à aller plus vite. La visibilité fait la différence entre des risques non maîtrisés et une adoption encadrée. Lorsque les équipes voient quels composants d’IA sont utilisés, où ils s’exécutent et comment ils interagissent, elles peuvent guider les comportements au moyen de politiques et de configurations plutôt que d’interdictions.

Pour garder une longueur d’avance, il faut rester constamment attentif aux nouvelles tendances. L’écosystème de l’IA ne cesse d’évoluer. De nouveaux frameworks d’agents apparaissent régulièrement. Les serveurs MCP évoluent. Les modèles open source changent. Les outils d’orchestration, les chargeurs de jeux de données et les bibliothèques d’automatisation élargissent chaque mois la surface d’exposition. Les clients comptent sur Snyk pour suivre cette évolution et la traduire en détections et en contexte exploitables.

Pour compléter cette approche, la détection des dépôts et des postes de développement révèle ce qui est exposé, mais Snyk Code boucle la boucle en montrant comment ces expositions ont été créées. Les organisations doivent également tirer parti des solutions SAST pour relier les résultats d’exécution et au niveau des ressources aux chemins de code vulnérables qui en sont à l’origine. Les équipes peuvent ainsi passer d’une détection fragmentée à une remédiation coordonnée, où les corrections du code réduisent automatiquement les risques en aval sur les postes et dans les dépôts liés aux systèmes propulsés par l’IA.

C’est cette base de recherche qui permet de conserver une vue complète au fil du temps. À mesure que la chaîne d’approvisionnement de l’IA s’étend et évolue, reconnaître les nouveaux composants et comprendre leur rôle devient aussi important que de savoir ce qui existe déjà. On obtient ainsi une compréhension évolutive des risques liés à l’IA, au rythme des pratiques réelles de développement.

AI-BOM + visibilité sur les postes des développeurs = le nouveau socle de sécurité de l’IA

Lorsque la visibilité couvre à la fois les dépôts et les machines des développeurs, la chaîne d’approvisionnement de l’IA devient enfin compréhensible. Le code montre ce que les équipes ont l’intention de livrer. Les environnements de développement révèlent comment l’IA est explorée, testée et utilisée. Ensemble, ils fournissent aux équipes de sécurité le contexte nécessaire pour passer de suppositions réactives à une gouvernance éclairée.

C’est important, car les restrictions ne peuvent pas être appliquées à grande échelle. Bloquer les serveurs MCP ou les agents locaux ne fait que rendre les expérimentations moins visibles. Les développeurs continueront à adopter les outils qui les aident à aller plus vite. La visibilité distingue les risques non maîtrisés d’une adoption encadrée. Lorsque les équipes voient quels composants d’IA sont utilisés, où ils s’exécutent et comment ils interagissent, elles peuvent guider les comportements au moyen de politiques et de configurations, sans perturber le travail.

Pour maintenir une vue précise, il faut suivre les évolutions en continu. L’écosystème de l’IA évolue rapidement : de nouveaux frameworks d’agents, serveurs MCP, modèles et outils apparaissent sans cesse. La capacité à reconnaître ces composants et à comprendre leur rôle transforme la visibilité en une posture de sécurité durable.

La chaîne d’approvisionnement de l’IA évolue plus vite que les modèles de sécurité traditionnels ne peuvent suivre. Découvrez comment une visibilité continue vous aide à garder une longueur d’avance sans ajouter de contraintes.