Choisir un outil AI BOM pour son pipeline DevSecOps

Souhaitez-vous vérifier les licences des modèles, suivre les dépendances vulnérables ou savoir si les modèles utilisés ont changé ? Les champs nécessaires et les outils à choisir varient selon cet objectif. Commencez par définir les éléments à inventorier : identifiant et version du modèle, fournisseur, dépendances logicielles, lieux d’utilisation et responsable, ainsi que, si nécessaire, jeux de données et licences.

Le ML-BOM de CycloneDX est un format capable de représenter notamment des modèles et des jeux de données. Toutefois, la présence d’un champ dans le format ne signifie pas qu’un outil peut en récupérer la valeur dans votre environnement.

cdxgen est une option pour générer des BOM, notamment à partir du code source. Dependency-Track reçoit des BOM CycloneDX et peut servir à leur enregistrement depuis la chaîne CI/CD ainsi qu’à l’analyse des composants. La génération assurée par le premier et la réception et la gestion assurées par le second remplissent des rôles différents : évaluez-les en envisageant aussi leur combinaison.

Les outils de génération diffèrent eux aussi par les éléments qu’ils analysent. AIBoMGen CLI génère une nomenclature IA (AI BOM) au format CycloneDX à partir de l’utilisation de modèles Hugging Face dans un dépôt ; une GitHub Action est également disponible. xgrep analyse hors ligne l’utilisation de SDK d’IA et de modèles dans le code et produit une sortie au format CycloneDX 1.6. Toutefois, la sortie de xgrep dédiée à l’IA ne comprend pas les dépendances logicielles générales : il faut générer une SBOM séparément.

Même si vous utilisez déjà un générateur de SBOM, celui-ci ne peut pas nécessairement recueillir les informations propres aux modèles. Recherchez d’autres options dans le CycloneDX Tool Center et vérifiez non seulement les formats pris en charge, mais aussi les champs d’information sur les modèles produits en sortie, les interfaces CLI ou API, l’authentification et l’articulation avec votre gestion existante des tickets.

L’exemple suivant est un exemple officiel de cdxgen v13.6.0. Générez une BOM sur une cible ne contenant aucune donnée confidentielle, puis comparez l’identifiant du modèle, sa version et sa licence avec la configuration d’origine. Il s’agit d’un exemple de commande, et non du résultat d’une exécution dans cet environnement.

Les jeux de données et les modèles de base mentionnés dans une fiche de modèle sont déclarés par le fournisseur. Ne les considérez pas comme une preuve de leur utilisation effective pour l’entraînement ; vérifiez séparément les mentions de la fiche, les dépendances observées et les éléments de preuve issus des tâches d’entraînement.

cdxgen -r --include-formulation -o aibom.json --bom-audit --bom-audit-categories ai-bom .

Les modèles sélectionnés à l’exécution au moyen de variables d’environnement ou d’API externes peuvent échapper à la seule analyse statique du dépôt. Si nous étions chargés d’examiner le code, nous confronterions l’inventaire généré à la configuration de l’application et aux historiques d’utilisation, puis examinerions les références qui n’y figurent pas. L’analyse de code seule ne permet pas nécessairement de connaître l’ensemble des usages de modèles externes.

Après l’intégration à la CI, modifiez la version d’un modèle pour vérifier qu’une différence apparaît dans l’artefact suivant et que les champs nécessaires sont conservés par le système destinataire. La réussite de la commande de génération ne garantit pas que la CI échouera si un problème est détecté. Il faut configurer séparément les conditions d’échec et le traitement des codes de sortie, et mettre en place un fonctionnement qui ne considère pas une vérification manuelle en attente comme une validation.