Les directives donnent aux RSSI un moyen de faire pression sur les fournisseurs en faveur de la transparence de l’IA, mais les analystes affirment que le plus difficile sera de prouver que les informations fournies correspondent à la réalité.
L’Agence américaine de cybersécurité et de sécurité des infrastructures (CISA) et ses partenaires du G7 ont publié une liste d’éléments minimaux pour une nomenclature de logiciel d’IA, une décision qui pourrait aider les RSSI à évaluer la sécurité et la provenance des systèmes d’IA entrant dans les environnements d’entreprise.
Les directives étendent les concepts SBOM traditionnels à l’IA en appelant à la documentation des modèles, des ensembles de données, des composants logiciels, des fournisseurs, des licences et d’autres dépendances. Les éléments minimaux supplémentaires ne sont ni exhaustifs ni obligatoires, a déclaré la CISA, mais reflètent un consensus parmi les experts du G7 et devraient s’étendre à mesure que la technologie de l’IA évolue.
Pour les responsables de la sécurité, le document place plus fermement les risques liés à l’IA dans la surveillance de la chaîne d’approvisionnement des entreprises. Cela pourrait intégrer les SBOM IA aux mêmes conversations sur les risques liés aux fournisseurs qui entourent déjà la composition des logiciels, les services cloud et les plates-formes technologiques tierces.
Mais une différence importante est que les SBOM IA nécessitent une visibilité au-delà de la composition logicielle, car le risque IA est façonné par les modèles, les données, l’infrastructure et le comportement du système.
« Les systèmes d’IA ajoutent de nouvelles couches d’opacité : lignée de modèles, données de formation et d’inférence, historique de réglage fin, invites, bases de données vectorielles, modèles de base tiers, API, logique d’orchestration et comportement d’exécution », a déclaré Sakshi Grover, directeur de recherche senior pour IDC Asia Pacific Cybersecurity Services.
Les logiciels d’IA sont également différents car ils sont probabilistes, avec des résultats façonnés par la provenance des données ainsi que par le code, selon Keith Prabhu, fondateur et PDG de Confidis.
« Les logiciels d’IA englobent intrinsèquement plus que de simples logiciels », a déclaré Prabhu. « En plus des composants logiciels, il faudrait également suivre les modèles, les données d’entraînement, les invites et les instructions système, les poids et points de contrôle des modèles, ainsi que les dépendances GPU. »
Sanchit Vir Gogia, analyste en chef chez Greyhound Research, a expliqué ce changement de manière plus générale.
« La question n’est plus seulement « quel code se trouve à l’intérieur de ce produit ? La question est : « quels codes, modèles, données, infrastructures, contrôles et décisions du fournisseur façonnent le comportement de ce système ? » », a déclaré Gogia.
Comment l’utiliser
L’utilisation immédiate des orientations peut concerner la gestion des risques liés aux achats et aux fournisseurs. Cela donne aux équipes de sécurité un moyen de faire pression sur les fournisseurs avant que les produits basés sur l’IA ne soient autorisés à entrer en production.
« Les organisations devraient demander aux fournisseurs de fournir une visibilité sur la provenance des modèles, les sources de données de formation, les dépendances des logiciels et des API, les obligations de licence, les pratiques de tests de sécurité, les cycles de mise à jour, les contrôles de surveillance de l’exécution et les limites de responsabilité partagée », a déclaré Grover.
Le niveau de contrôle peut également dépendre du type de fournisseur.
« Pour les grands fournisseurs, les RSSI doivent spécifiquement rechercher la transparence concernant les dépendances des modèles de base tiers, les flux de données géographiques, les pratiques de mise à jour des modèles et si les données des clients sont conservées pour la formation ou le réglage du modèle », a ajouté Grover. « Pour les startups, l’accent doit être mis sur la maturité des processus de gouvernance, le suivi des dépendances, les pratiques de développement sécurisées, les contrôles d’identité et la surveillance opérationnelle tout au long du cycle de vie de l’IA. »
La même approche fondée sur les risques devrait s’appliquer à la manière dont la technologie sera utilisée. Pour les déploiements à plus haut risque, Gogia a déclaré que les SBOM IA devraient faire partie d’un ensemble plus large de preuves du fournisseur, soutenu par une documentation sur les flux de données, l’architecture de sécurité, le comportement du modèle, l’impact sur la confidentialité, les conclusions de l’équipe rouge, la réponse aux incidents, la journalisation et les tests d’injection rapide.
Les lacunes qui subsistent
La plus grande lacune est qu’un SBOM IA peut montrer ce qu’un fournisseur dit être à l’intérieur d’un système d’IA, mais ne prouve pas si le système peut être fiable pour la manière dont une entreprise envisage de l’utiliser.
« Un minimum d’éléments crée de la visibilité », a déclaré Gogia. « Ils ne créent pas d’assurance. Ils indiquent à l’acheteur ce que le vendeur prétend exister. Ils ne prouvent pas, à eux seuls, que chaque dépendance a été divulguée, que chaque ensemble de données est licite, que chaque contrôle fonctionne, que chaque modèle se comporte dans les limites de tolérance ou que chaque chemin d’exécution est surveillé. «
Le plus dur sera de prouver que le document correspond à la réalité. Les équipes de sécurité peuvent recevoir un SBOM IA d’un fournisseur, mais elles doivent toujours déterminer si celui-ci reflète le système exécuté en production et suit le rythme des modifications apportées à l’environnement IA. Prabhu a déclaré que même un SBOM IA de haute qualité n’offrirait qu’une visibilité partielle sur les risques liés à l’IA. Des problèmes tels que l’évolution du comportement de l’IA, les hallucinations, la modification de l’utilisation des invites et la transparence limitée des données de formation peuvent encore rendre difficile pour les responsables de la sécurité l’évaluation des risques réels. À mesure que les systèmes d’IA mûrissent, les SBOM d’IA devront également évoluer pour combler ces lacunes, a ajouté Prabhu.
