Passer en revue les bibliothèques open source IA

Le logiciel open source (OSS) fait partie intégrante du développement de logiciels modernes, et les systèmes IA ne font pas exception. Les projets IA dépendent généralement d’infrastructures open source, de bibliothèques de modèles, de modèles préentraînés et d’outils de traitement des données. Tout comme d’autres composants OSS, les bibliothèques spécifiques à l’IA introduisent des risques de chaîne d’approvisionnement qui nécessitent un examen complet de la sécurité avant l’adoption.

Pourquoi les bibliothèques open source IA ont besoin d’une attention particulière

Les bibliothèques AI OSS présentent certains risques qui vont au-delà de celles des dépendances logicielles traditionnelles :

• Modèles préentraînés : de nombreuses bibliothèques IA sont fournies avec ou téléchargent des modèles préentraînés. Un modèle compromis peut contenir des portes dérobées ou un comportement biaisé difficile à détecter par le biais de la révision du code seul.
• Dépendances de pipeline de données : les bibliothèques IA gèrent souvent le chargement, la transformation et l’extraction des fonctionnalités. Les vulnérabilités de ces composants peuvent exposer des données d’apprentissage ou autoriser l’empoisonnement des données.
• Risques de sérialisation : les modèles IA sont fréquemment enregistrés et chargés à l’aide de formats de sérialisation (par exemple, pickle dans Python). La désérialisation des fichiers de modèle non approuvés peut entraîner l’exécution arbitraire du code.
• Cycles de publication rapides : les bibliothèques IA évoluent rapidement, avec des changements fréquents. Les organisations qui épinglent des versions antérieures peuvent manquer des correctifs de sécurité critiques.

Évaluation de l’adéquation des bibliothèques OSS

Avant d’adopter une bibliothèque OSS AI, évaluez-la du point de vue fonctionnel et de sécurité :

• Contexte et objectif : Définissez la raison pour laquelle vous passez en revue cette bibliothèque. L’intégrez-vous à un système de production, en l’utilisant pour l’expérimentation ou en l’évaluant contre des alternatives ? Établissez des critères d’acceptation clairs pour l’examen.
• Évaluation des risques : tenez compte des risques potentiels liés à l’utilisation de la bibliothèque. Utilisez la modélisation des menaces pour identifier les vecteurs d’attaque : comment cette bibliothèque s’adapte-t-elle à la surface d’attaque de votre application ? Que se passe-t-il si la bibliothèque est compromise ?
• Conformité des licences : vérifiez que la licence de la bibliothèque est compatible avec les stratégies de votre organisation, en particulier pour une utilisation commerciale ou gouvernementale.
• Santé de la maintenance : évaluez à quel point la bibliothèque est activement maintenue. Examinez la fréquence des commits, le temps de réponse aux tickets et le nombre de contributeurs actifs. Les bibliothèques abandonnées ou à gestion minimale sont plus risquées.

Révision du code et analyse des dépendances

Effectuez une révision technique du code de la bibliothèque et de sa chaîne de dépendances :

• Inspection du code : examinez le code source de la bibliothèque pour connaître les failles de sécurité telles que les vulnérabilités d’injection, les pratiques de chiffrement non sécurisées et la désérialisation non sécurisée. Examinez soigneusement les mécanismes d’authentification, la validation des entrées et la gestion des erreurs.
• Évaluation des dépendances : évaluez les dépendances transitives de la bibliothèque. Les composants obsolètes ou vulnérables de l’arborescence des dépendances peuvent présenter des risques, même si le code de la bibliothèque est sécurisé.
• Analyse de la composition logicielle (SCA) : utilisez des outils SCA automatisés pour identifier les vulnérabilités connues (CVE) dans la bibliothèque et ses dépendances. De nombreuses organisations intègrent ces outils dans leur pipeline CI/CD pour détecter les problèmes au début.

Contrôles de chaîne d’approvisionnement spécifiques à l’IA

Au-delà des pratiques de révision osS standard, appliquez ces contrôles spécifiques à l’IA :

• Vérification de la provenance du modèle : lorsqu’une bibliothèque inclut des modèles préentraînés, vérifiez l’origine du modèle, qui l’a entraînée et si les données d’apprentissage et le processus sont documentés. Une nomenclature IA (AI-BOM) — une liste structurée comprenant les composants du modèle, les sources de données de formation et les dépendances — aide à établir la confiance.
• Analyse du modèle : analysez les fichiers de modèle téléchargés pour détecter les charges utiles malveillantes connues avant de les charger. Évitez de désérialiser les fichiers de modèle à partir de sources non approuvées.
• Vérifications de reproductibilité : dans la mesure du possible, vérifiez que les modèles peuvent être reproduits à partir de données d’apprentissage et de configurations documentées. Cela permet de confirmer que le modèle n’a pas été falsifié.
• Évaluation en bac à sable : testez les nouvelles bibliothèques IA dans des environnements isolés avant de les déployer en production pour contenir tout comportement inattendu.

Analyse et correction des vulnérabilités

Ne partez pas du principe que d’autres personnes ont effectué des vérifications de vulnérabilité. Appliquez votre propre chaîne d’outils d’évaluation :

• Analyses complètes : utilisez des scanneurs de vulnérabilité pour identifier les faiblesses de sécurité potentielles dans la bibliothèque et ses dépendances.
• Correction hiérarchisée : si des vulnérabilités sont détectées, évaluez leur impact et leur exploitabilité. Hiérarchiser les correctifs en fonction de la gravité et de l’exposition.
• Surveillance continue : les bases de données de vulnérabilité OSS sont mises à jour régulièrement. Configurez des alertes automatisées pour les nouveaux CVE affectant les bibliothèques de votre pile IA.