L'industrie n'a pas encore pleinement compris l'idée d'un SBOM, et nous avons déjà commencé à entendre un nouveau terme – ML-BOM – Machine Learning Bill of Material. Avant que la panique ne s'installe, comprenons pourquoi une telle nomenclature doit être produite, les défis liés à la génération d'une ML-BOM et à quoi une telle ML-BOM peut ressembler.
En lisant ce blog, vous pourriez vous demander si cet article a été généré par l’IA. La raison en est que l’IA est omniprésente autour de nous et qu’il est difficile de la différencier des artefacts créés par l’homme. Cependant, les progrès rapides de l'IA posent également des risques privés, commerciaux et sociétaux, et des législations commencent à être mises en œuvre pour limiter ces risques, par exemple, le Loi de l'UE sur l'IA. Il n'entre pas dans le cadre de cet article d'approfondir ces risques, mais pour en mentionner quelques-uns : il existe des risques de comportement dangereux, discriminatoire et portant atteinte à la vie privée des systèmes basés sur l'IA, ainsi que de la propriété intellectuelle, des licences et de la cybersécurité. -les risques de sécurité.
Une première étape pour gérer ces risques consiste à savoir quelles technologies d’IA sont utilisées dans chaque système ; ces connaissances peuvent permettre aux parties prenantes de gérer les risques (par exemple, gérer les risques juridiques en connaissant la licence des ensembles de données et des modèles) et de réagir aux nouvelles découvertes concernant ces technologies (par exemple, si un modèle s'avère discriminatoire, la partie prenante peut cartographier tous les risques). systèmes qui utilisent ce modèle pour atténuer le risque).
En jetant un coup d’œil sur l’évolution de la réglementation, en examinant Executive Order 13960 sur « Promouvoir l'utilisation d'une intelligence artificielle digne de confiance au sein du gouvernement fédéral » révèle des principes tels que la responsabilisation, la transparence, la responsabilité, la traçabilité et la surveillance réglementaire, qui nécessitent tous de comprendre quelles technologies d'IA sont utilisées dans chaque système.
Un ML-BOM est une documentation des technologies d'IA au sein d'un produit. CycloneDX, le format OWASP bien connu pour SBOM, version 1.5 et ultérieure, le prend en charge et constitue désormais un standard pour ML-BOM.
Générer une ML-BOM est un défi ; il existe de nombreuses façons de représenter des modèles et des ensembles de données ; Les modèles et ensembles de données d'IA peuvent être consommés à la volée, et la décision quant aux modèles à utiliser peut être prise par programme, à la volée, sans laisser de traces aux technologies d'analyse de composants standard pour les détecter. En plus de ces défis, l’IA est encore une technologie émergente, contrairement à la maturité des gestionnaires de progiciels. L’industrie ne comprend donc pas encore pleinement les besoins d’un ML-BOM.
Comme point de départ, nous avons décidé de nous concentrer sur la génération d'un ML-BOM pour les projets qui utilisent un standard de facto, HuggingFace. HuggingFace est un « gestionnaire de packages » pour les modèles et ensembles de données d'IA et est accompagné de bibliothèques Python populaires. Voici quelques instantanés d'un SBOM que nous avons généré automatiquement à partir d'un tel produit.
Imaginez un produit composé de nombreux composants, dont certains sont des modèles d'apprentissage automatique. Le composant CycloneDX ci-dessous décrit un tel modèle :
Ce composant identifie le modèle et fournit un lien pour explorer davantage les informations sur ce modèle. En outre, il comprend des informations sur les licences qui peuvent être utilisées à des fins de conformité.
CycloneDX V1.5 définit également un champ spécifique à l'IA nommé « modelCard » comme moyen standard de documenter les propriétés du modèle d'apprentissage automatique. Voici un exemple de modèle de carte que nous avons créé.
Un cas d'utilisation d'une telle modelCard peut consister à rechercher tous les produits qui utilisent des modèles de classification d'images ou à exécuter une stratégie qui empêche l'utilisation de types de modèles spécifiques.
CycloneDX permet la documentation d'une arborescence de composants – hiérarchie de sous-composants. Étant donné que HuggingFace, en tant que gestionnaire de packages IA, représente les modèles et ensembles de données IA sous forme de dépôts git, nous avons décidé de documenter les fichiers du modèle/ensemble de données IA en tant que sous-composants du composant de modèle d'apprentissage automatique. Voici à quoi cela ressemble :
Outre les informations de fichier standard, les propriétés incluent des informations supplémentaires, telles que des informations de sécurité. Dans ce cas, nous voyons deux mesures de sécurité :
- Analyse antivirus : elle est importante lors de la consommation d'ensembles de données sensibles aux virus (comme les images, les PDF et les exécutables).
- Analyse Pickle – mesures de risque de sécurité concernant les fichiers d'ensembles de données de type « pickle », qui sont plus sujets aux risques (pour comprendre les risques dans ce format, voir l'explication sur le Site Web de HuggingFace).
Ces données peuvent être utilisées pour appliquer des politiques qui vérifient que l’analyse antivirus et pickle a réussi.
ML-BOM est un nouveau concept ; ce que nous montrons ici est une première étape. Mais même en tant que tel, nous pouvons comprendre la valeur que cela apporterait compte tenu de l’adoption croissante, de la réglementation et des risques liés à l’IA.
Pour terminer, j'ai demandé à ma boule de cristal (alias ChatGPT) de décrire l'avenir des ML-BOM, et voici sa réponse :
« Dans un avenir pas si lointain, les ML-BOM pourraient bien devenir des maestros du cyber-pilotage automatique, orchestrant la symphonie des modèles d'apprentissage automatique avec une touche d'automatisation, tout en dansant à travers les subtilités des pipelines CI/CD. .»
Eh bien, peut-être avons-nous besoin de plus que des ML-BOM…
Ce contenu vous est proposé par Scribe Security, l'un des principaux fournisseurs de solutions de sécurité de bout en bout pour la chaîne d'approvisionnement logicielle, offrant une sécurité de pointe aux artefacts de code ainsi qu'aux processus de développement et de livraison de code tout au long des chaînes d'approvisionnement logicielles. En savoir plus.