La chaîne d'approvisionnement de votre IA est le plus grand risque de sécurité que vous ne gérez pas

Le problème

En février 2024, les chercheurs en sécurité de JFrog ont découvert plus de 100 modèles d'IA malveillants sur Hugging Face, l'un des référentiels publics les plus populaires pour le machine learning. Ces modèles n'étaient pas simplement défaillants. Ils étaient militarisés. Lorsqu'un développeur en téléchargeait un et le chargeait à l'aide d'une commande standard, le modèle ouvrait silencieusement une porte dérobée — un reverse shell — vers un serveur distant. L'attaquant obtenait immédiatement l'accès au système de ce développeur.

Un modèle spécifique, téléversé par un utilisateur nommé « baller423 », utilisait un format de fichier courant appelé pickle pour injecter du code pendant le processus de chargement. Dès qu'un data scientist exécutait la commande standard torch.load() , du code malveillant s'exécutait automatiquement. Il se connectait à une adresse IP appartenant au Korea Research Environment Open Network.

Il ne s'agit pas d'un risque théorique. Cela se produit en ce moment même sur les plateformes que vos équipes utilisent probablement tous les jours. Si votre organisation extrait des modèles d'IA à partir de sources publiques — et c'est le cas de la plupart d'entre elles —, vous importez des fichiers binaires qu'aucun être humain ne peut lire ou examiner à l'œil nu. Contrairement au code logiciel traditionnel, les poids des modèles d'IA sont des structures opaques. Les comportements malveillants se dissimulent au sein de millions de paramètres numériques. Vos processus actuels de revue de code ne peuvent tout simplement pas détecter cela. La chaîne d'approvisionnement de l'IA est aujourd'hui la partie la plus vulnérable et la moins gouvernée de votre infrastructure technologique.

Pourquoi cela concerne votre entreprise

L'exposition financière et réglementaire est bien réelle et ne cesse de croître. Considérez ces chiffres issus des recherches du livre blanc :

• 83 % des organisations ne disposent pas de contrôles automatisés de sécurité de l'IA. Seules 17 % ont mis en place des défenses automatisées. Les autres, selon la formule des chercheurs, « opèrent à l'aveugle ».
• Le Shadow AI — l'utilisation non autorisée d'outils d'IA par les employés — représente 90 % de l'utilisation de l'IA en entreprise. Vos équipes informatiques et de sécurité ne peuvent probablement pas visualiser la majeure partie de l'activité liée à l'IA au sein de votre organisation actuellement.
• Les incidents impliquant des outils d'IA non vérifiés augmentent le coût d'une violation de données de 670 000 $ en moyenne. C'est le surcoût que vous payez pour une adoption non gouvernée de l'IA.
• Seules 12 % des entreprises ont mis en œuvre une gouvernance de l'IA dotée de véritables contrôles techniques. 56 % supplémentaires déclarent être « prêtes », mais ne disposent pas des mécanismes d'application nécessaires pour le concrétiser.
• 86 % des organisations n'ont aucune visibilité sur la manière dont l'IA déplace les données en interne. Si vous ne pouvez pas visualiser les flux de données, vous ne pouvez ni les protéger ni prouver votre conformité.

Pour votre conseil d'administration et vos régulateurs, la question est limpide. Pouvez-vous montrer exactement à un auditeur quels modèles d'IA s'exécutent dans votre environnement, d'où ils proviennent et à quelles données ils touchent ? Si ce n'est pas le cas, vous vous exposez à des écarts de conformité au regard des cadres émergents tels que le NIST AI 100-2. Vous vous exposez également au préjudice réputationnel d'une faille de sécurité que vous n'avez jamais vue venir — parce que le vecteur d'attaque était un modèle d'IA que personne n'avait vérifié.

Ce qui se passe réellement sous le capot

Pour comprendre pourquoi cette menace est si difficile à détecter, imaginez un modèle d'IA comme une boîte de recettes scellée. Les logiciels traditionnels sont comme une recette rédigée en texte clair : vous pouvez lire chaque instruction et repérer un élément dangereux. Un modèle d'IA, en revanche, est une boîte verrouillée contenant des millions de minuscules cadrans. Les cadrans produisent des résultats, mais vous ne pouvez pas ouvrir la boîte pour lire les instructions. Un modèle empoisonné présente exactement la même apparence et les mêmes performances qu'un modèle sain — jusqu'à ce qu'un déclencheur spécifique n'active le comportement dissimulé.

C'est ce qu'on appelle l'empoisonnement des données (data poisoning), et les calculs sous-jacents sont alarmants. Des chercheurs d'Anthropic et de l'AI Red Team de NVIDIA ont démontré que l'empoisonnement de seulement 0,00016 % des données d'entraînement — soit environ 250 documents au sein d'un jeu de données massif — compromet définitivement un modèle de 13 milliards de paramètres. Une fois les données empoisonnées intégrées aux poids du modèle, l'ajout de données saines supplémentaires ne résout rien. La porte dérobée est permanente.

Ces modèles empoisonnés agissent comme des « agents dormants ». Ils réussissent chaque test standard et chaque benchmark de référence. Ils se comportent normalement dans votre environnement d'assurance qualité (QA). Mais lorsqu'ils rencontrent un déclencheur spécifique — une chaîne de texte unique, un motif d'image particulier, ou même une manipulation d'entrée au niveau du bit —, le modèle bascule dans son mode malveillant. Cela peut se traduire par le contournement de l'authentification, l'exfiltration de données sensibles ou la génération de code malveillant que vos systèmes en aval exécutent automatiquement.

Le danger s'étend au-delà des modèles eux-mêmes. Même les scanners de sécurité censés vous protéger échouent. JFrog a découvert trois vulnérabilités zero-day dans PickleScan, un outil couramment utilisé pour auditer les modèles d'IA. Des attaquants pouvaient manipuler les extensions de fichiers pour faire apparaître un modèle compromis comme « sûr ». Les recherches indiquent que jusqu'à 96 % des alertes actuelles des scanners sont des faux positifs, ce qui désensibilise votre équipe de sécurité face aux menaces réelles.

Ce qui fonctionne (et ce qui ne fonctionne pas)

Commençons par trois approches courantes qui s'avèrent insuffisantes :

• Se fier aux scores de confiance des référentiels publics. Hugging Face n'est pas un éditeur de logiciels agréé. Les plus de 100 modèles malveillants qui y ont été découverts prouvent que la popularité et la disponibilité ne sont pas synonymes de sécurité.
• Rédiger des politiques de gouvernance de l'IA sans application automatisée. Un document de politique n'empêche pas un développeur de télécharger un modèle non vérifié à deux heures du matin. Sans barrières techniques, 77 % des employés continueront de coller des données propriétaires dans des outils d'IA publics.
• Exécuter des scanners de code standards sur des fichiers de modèles d'IA. Les outils traditionnels d'analyse statique n'ont pas le contexte requis pour inspecter les poids des modèles. Ils ne peuvent pas détecter les portes dérobées dissimulées dans les paramètres numériques ni les modèles malveillants intégrés dans les métadonnées des modèles.

Ce qui fonctionne en revanche, c'est de traiter chaque modèle d'IA comme du code exécutable potentiellement malveillant. Voici le principe architectural en trois étapes :

1. Entrée — Créer un inventaire logiciel pour le Machine Learning (ML-BOM). Avant que tout modèle ne pénètre dans votre environnement, générez un enregistrement infalsifiable de son origine, de ses données d'entraînement, de ses dépendances logicielles et de sa signature cryptographique. Considérez cela comme un document de chaîne de traçabilité pour chaque artefact d'IA. Des standards comme CycloneDX et SPDX 3.0 prennent désormais en charge des profils spécifiques à l'IA précisément à cette fin. Vos pratiques de traçabilité et de provenance des données constituent le socle fondamental en la matière.

2. Traitement — Appliquer la vérification cryptographique au moment du chargement. Votre serveur d'inférence — le système qui exécute les modèles d'IA — doit inclure un « contrôleur d'admission » (Admission Controller) qui compare la signature numérique de chaque modèle à un registre de confiance avant son chargement en mémoire. Cela signifie que seuls les modèles signés par les clés propres à votre organisation peuvent s'exécuter. Utilisez des modules de sécurité matériels (HSM) pour gérer ces clés. Bannissez totalement le format pickle au profit de SafeTensors, un format qui n'autorise aucun code exécutable.

3. Sortie — Surveiller le comportement du modèle en continu lors de l'exécution. Comparez les résultats générés par le modèle à des références de validation saines afin de détecter toute dérive ou anomalie signalant l'activation d'une porte dérobée. Appliquez des couches de désinfection des entrées (input sanitization) qui reformulent les requêtes avant qu'elles n'atteignent le modèle, neutralisant ainsi les charges utiles déclencheuses minutieusement conçues. Limitez le débit des requêtes pour prévenir les attaques par extraction de modèle.

L'avantage de la piste d'audit est précisément ce qui rend cette approche précieuse pour votre équipe de conformité. Chaque modèle dispose d'un ML-BOM signé. Chaque déploiement possède une chaîne de signatures vérifiée. Chaque inférence fait l'objet d'une surveillance de ses sorties. Lorsque votre régulateur ou votre auditeur vous demande « comment savez-vous que ce modèle d'IA est sûr ? », vous pouvez présenter une preuve cryptographique — et non un simple document de politique.

Pour les organisations œuvrant dans la sécurité et la résilience de l'IA, cela n'est désormais plus facultatif. La convergence de la sécurité de l'IA et de la sécurité de la chaîne d'approvisionnement logicielle implique que les protections de vos pipelines CI/CD existants doivent s'étendre aux artefacts de modèles. Si votre modèle est sécurisé mais que la bibliothèque Python qui l'exécute est compromise, votre système est tout de même violé. Une approche unifiée de l'évaluation de la sécurité et du durcissement à la fois sur les actifs logiciels et sur les actifs d'IA est le seul moyen de combler cette brèche.

Lisez l'analyse technique complète pour des conseils détaillés sur la mise en œuvre, ou explorez la version interactive pour découvrir comment ces contrôles s'appliquent à votre environnement spécifique.