Le pipeline d’IA principal d’un fournisseur d’infrastructure d’apprentissage automatique reposait sur une combinaison de bibliothèques open source bien établies et d’une bibliothèque de prétraitement des données plus petite et spécialisée, appelée dataprep, un utilitaire servant à nettoyer et à normaliser les données d’entraînement en entrée. Les trois premières dépendances (scikit-learn, NumPy, pandas) comptaient parmi les projets open source les plus scrutés de l’écosystème du ML, avec des programmes de sécurité actifs, une réponse rapide aux vulnérabilités et un audit continu par la communauté. dataprep, c’était autre chose : maintenue par un seul développeur, sans commit depuis huit mois, sans processus de divulgation des failles de sécurité ni historique d’audit des dépendances. Lorsqu’un chercheur en sécurité a publié une preuve de concept démontrant qu’un artefact de modèle conçu de manière malveillante et traité par dataprep pouvait exécuter du code arbitraire pendant la phase de chargement des données, le fournisseur n’avait aucune surveillance en place pour repérer cette divulgation. La vulnérabilité est restée six mois dans son pipeline d’IA de production. Le fournisseur l’a apprise lorsque l’équipe de sécurité d’un client a signalé l’avis public. Le programme de sécurité de l’IA du fournisseur avait évalué le processus d’entraînement du modèle, la sécurité de l’API d’inférence et la provenance des données d’entraînement. Il n’avait pas évalué la posture de sécurité des bibliothèques qui faisaient l’intermédiaire entre les données d’entraînement et le processus d’entraînement du modèle.
Que sont les dépendances de la chaîne d’approvisionnement de l’IA, au fond ?
Les dépendances de la chaîne d’approvisionnement de l’IA sont les bibliothèques open source, les composants de modèles pré-entraînés, les utilitaires de traitement de données et les paquets de cadres de ML qui constituent la pile logicielle sur laquelle un système d’IA est construit, et par lesquels des attaques de la chaîne d’approvisionnement peuvent compromettre le système d’IA sans attaquer le modèle lui-même. De même que la sécurité de la chaîne d’approvisionnement logicielle reconnaît que la sécurité d’une application dépend de chaque bibliothèque et dépendance qu’elle intègre, la sécurité de la chaîne d’approvisionnement de l’IA reconnaît que l’intégrité d’un système d’IA dépend de chaque composant de la pile qui traite ses données d’entraînement, exécute son inférence ou gère son déploiement.
La dimension du risque propre aux dépendances de l’IA va au-delà du risque standard de la chaîne d’approvisionnement logicielle à plusieurs égards. D’abord, les pipelines d’IA sont souvent assemblés à partir d’un mélange hétérogène de cadres bien établis (TensorFlow, PyTorch, scikit-learn) et d’utilitaires spécialisés (outils de prétraitement des données, bibliothèques d’ingénierie des variables, utilitaires de sérialisation de modèles), ces derniers pouvant présenter une posture de sécurité nettement plus faible que les cadres phares. Une organisation qui concentre son programme de sécurité des dépendances sur les principaux cadres peut passer à côté du risque concentré dans les petits utilitaires spécialisés, moins scrutés et moins activement maintenus.
La vulnérabilité de sérialisation des modèles est un risque précis et bien documenté des dépendances de l’IA. Le format pickle de Python, utilisé par défaut dans de nombreux cadres de ML pour enregistrer et charger les modèles, permet l’exécution de code arbitraire lorsqu’un artefact de modèle malveillant est chargé. Les bibliothèques qui gèrent le chargement des modèles sans contrôles de désérialisation sûre ouvrent une voie par laquelle un attaquant de la chaîne d’approvisionnement capable de substituer un artefact de modèle malveillant dans le registre de modèles peut exécuter du code dans l’environnement d’inférence au chargement du modèle. Cette attaque n’exige aucune exploitation de l’algorithme du modèle, seulement la capacité de remplacer le fichier du modèle sérialisé par un fichier malveillant.
La surface d’attaque des bibliothèques de traitement de données est le deuxième risque précis. Les bibliothèques chargées du prétraitement des données d’entraînement (lecture, analyse, transformation et nettoyage des données en entrée) traitent des données non fiables provenant de sources potentiellement non fiables. Une vulnérabilité d’une bibliothèque de prétraitement déclenchée par des données d’entrée malveillantes ouvre une voie par laquelle un attaquant de la chaîne d’approvisionnement capable d’introduire des données d’entraînement malveillantes peut exécuter du code dans l’environnement d’entraînement lors du traitement de ces données. Le vecteur d’attaque est la donnée d’entraînement, et non le modèle ni l’algorithme d’entraînement.
Le risque lié à la fraîcheur et à la maintenance des dépendances est la dimension de gouvernance. Les dépendances de l’écosystème du ML varient énormément en termes d’activité de maintenance, de processus de divulgation des failles de sécurité et de délais de réponse aux vulnérabilités. Une dépendance maintenue par un seul développeur sans processus de divulgation des failles n’offre pratiquement aucune assurance de sécurité : des vulnérabilités peuvent être découvertes et exploitées bien avant que le mainteneur n’en ait connaissance. Le problème des dépendances transitives l’amplifie : un cadre principal bien maintenu peut comporter des dépendances transitives vers des utilitaires mal maintenus, créant un risque de chaîne d’approvisionnement à travers une chaîne de dépendances qui dépasse la posture de sécurité du cadre principal.
Pourquoi c’est important
Les dépendances de la chaîne d’approvisionnement de l’IA sont importantes pour la TPRM car la sécurité du système d’IA du fournisseur est limitée par la sécurité de chaque composant de sa pile de dépendances, et pas seulement par l’architecture du modèle et le processus d’entraînement. Un fournisseur dont le programme de sécurité de l’IA se concentre sur la couche du modèle en laissant la couche des dépendances sans surveillance a une posture de sécurité plus solide dans les couches qu’il évalue et inconnue dans celles qu’il n’évalue pas.
Là où la plupart des équipes se trompent
L’échec le plus constant consiste à évaluer la sécurité de l’IA au niveau de la couche du modèle (processus d’entraînement, API d’inférence, provenance des données) sans étendre l’évaluation à la pile de dépendances sur laquelle repose le pipeline d’IA. C’est dans la couche des dépendances que se produiront de nombreuses attaques de la chaîne d’approvisionnement de l’IA.
- Sécurité de l’IA évaluée au niveau de la couche du modèle sans évaluation de la couche des dépendances
- Dépendances d’utilitaires spécialisés non évaluées : attention portée uniquement aux principaux cadres
- Format de sérialisation des modèles non évalué au regard d’une désérialisation sûre
- Surveillance des dépendances absente : aucun processus de suivi des divulgations de vulnérabilités dans les dépendances de l’IA
- Dépendances maintenues par une seule personne non identifiées comme présentant un risque élevé
À quoi ressemblent les bonnes pratiques
Les programmes matures de sécurité de la chaîne d’approvisionnement de l’IA tiennent un inventaire complet des dépendances de l’IA, y compris les utilitaires spécialisés et les dépendances transitives, surveillent les divulgations de vulnérabilités pour toutes les dépendances, évaluent les formats de sérialisation des modèles au regard d’une désérialisation sûre et appliquent des normes de maintenance modulées selon le risque, qui signalent comme présentant un risque élevé les dépendances inactives ou maintenues par une seule personne.
- Inventaire complet des dépendances de l’IA : toutes les bibliothèques, y compris les utilitaires spécialisés et les dépendances transitives
- Surveillance continue des vulnérabilités : toutes les dépendances de l’IA incluses dans la surveillance des divulgations de vulnérabilités
- Application d’une désérialisation sûre : chargement des modèles dans des formats sûrs plutôt qu’avec pickle lorsque c’est possible
- Évaluation de l’état des dépendances : activité du mainteneur, processus de divulgation des failles, dernière version publiée
- SBOM automatisée pour les pipelines d’IA : nomenclature logicielle incluant les dépendances de ML
Outils
Sécurité des dépendances : Snyk, Dependabot, OWASP Dependency-Check pour l’analyse des bibliothèques d’IA
Les outils d’analyse de la composition logicielle peuvent s’appliquer aux dépendances des pipelines d’IA comme aux dépendances applicatives. Pour les praticiens de la TPRM, demander si les dépendances du pipeline d’IA du fournisseur sont incluses dans son programme d’analyse SCA, et plus précisément si les utilitaires spécialisés de ML sont couverts en plus des principaux cadres, constitue une question précise sur la sécurité des dépendances de l’IA.
Chargement sûr des modèles : registre de modèles MLflow avec vérification de l’intégrité, ModelScan pour la sûreté des fichiers pickle
ModelScan et des outils similaires analysent les artefacts de modèles sérialisés à la recherche de charges malveillantes avant leur chargement. Pour les praticiens de la TPRM, demander si le processus de chargement des modèles du fournisseur utilise une désérialisation sûre ou analyse les artefacts de modèles avant leur chargement constitue une question précise sur la sécurité de la sérialisation.
Enjeux de gouvernance
Le défi de gouvernance posé par les dépendances de la chaîne d’approvisionnement de l’IA est le problème de l’hétérogénéité de l’écosystème. L’écosystème open source de l’AI/ML contient des milliers de paquets spécialisés dont la qualité de maintenance est très variable. Un programme complet de sécurité des dépendances pour les pipelines d’IA exige des outils d’évaluation couvrant l’ensemble de l’écosystème, et pas seulement les cadres phares.
- Inclure les dépendances du pipeline d’IA dans l’analyse SCA
- Évaluer le format de sérialisation des modèles : éviter pickle lorsqu’il existe des solutions sûres
- Surveiller l’état des dépendances : activité du mainteneur et processus de divulgation des failles
- Demander la SBOM du pipeline d’IA : inventaire complet des dépendances
- Signaler les dépendances maintenues par une seule personne comme nécessitant un examen supplémentaire
Si vous êtes une petite équipe
Demandez à votre fournisseur d’IA le plus à risque la SBOM de son pipeline d’IA, c’est-à-dire la liste complète des paquets Python et de leurs versions dans sa pile de dépendances de ML. Vérifiez ensuite deux points : premièrement, tous les paquets font-ils l’objet d’une surveillance des divulgations de vulnérabilités au moyen d’un outil comme Snyk ou Dependabot ? Deuxièmement, pour tout paquet comptant moins de trois contributeurs actifs ou sans commit depuis six mois, quel est le processus du fournisseur pour évaluer le risque de sécurité ? Ces deux questions révèlent si la couche des dépendances a reçu une attention de sécurité équivalente à celle de la couche du modèle.
- Demander la SBOM du pipeline d’IA : liste complète des dépendances de ML
- Demander si tous les paquets font l’objet d’une surveillance des divulgations de vulnérabilités
- Signaler les paquets maintenus par une seule personne ou inactifs depuis longtemps
- Interroger sur un format de sérialisation des modèles sûr
Ce qu’il faut exiger
Demandez directement :
« Pouvez-vous fournir la nomenclature logicielle de votre pipeline d’IA, plus précisément toutes les dépendances de bibliothèques de ML, y compris les utilitaires spécialisés, et toutes ces dépendances font-elles l’objet d’une surveillance des divulgations de vulnérabilités au moyen d’un outil SCA automatisé ? »
Preuves attendues
- SBOM du pipeline d’IA incluant toutes les dépendances de ML
- Couverture de toutes les dépendances de l’IA par l’outil SCA
- Confirmation du format de sérialisation des modèles et d’un chargement sûr
- Évaluation de l’état des dépendances pour les paquets à haut risque
Un fournisseur qui confirme la couverture de sécurité de son IA doit être invité à fournir la SBOM du pipeline d’IA. La sécurité de la couche du modèle couvre le modèle. La sécurité de la couche des dépendances couvre la pile sur laquelle le modèle s’exécute. Les deux sont nécessaires.
Comment le prouver
- Dossiers de SBOM du pipeline d’IA
- Couverture des dépendances de l’IA par l’analyse SCA
- Évaluation de la sécurité de la sérialisation des modèles
- Dossiers de surveillance de l’état des dépendances
À retenir
Quatre bibliothèques. Trois bien auditées. Une : un seul mainteneur, huit mois d’inactivité, exécution de code arbitraire via des données d’entraînement malveillantes. Six mois dans le pipeline de production avant la découverte. Le programme de sécurité de l’IA couvrait la couche du modèle de manière complète. La couche des dépendances, la pile sur laquelle s’exécute le processus d’entraînement du modèle, n’était pas dans le périmètre. Les attaques de la chaîne d’approvisionnement de l’IA n’exigent pas de compromettre l’algorithme du modèle. Elles exigent de trouver le maillon le plus faible de la pile de dépendances qui traite les données d’entraînement ou charge les artefacts de modèles. La SBOM du pipeline d’IA est l’inventaire. L’analyse SCA est la surveillance. La désérialisation sûre est le contrôle d’architecture. Ensemble, ils couvrent la couche des dépendances que l’évaluation de la couche du modèle laisse de côté.