L'impératif architectural de l'intégrité de la chaîne d'approvisionnement IA : sécuriser le cycle de vie du machine learning contre les modèles malveillants et les déploiements Shadow AI

L'intégration rapide des modèles de machine learning dans les environnements d'entreprise a dépassé le développement de cadres de sécurité robustes, créant une vulnérabilité systémique au cœur de l'infrastructure numérique moderne. Alors que le marché s'est largement concentré sur les capacités des services wrappers de grands modèles de langage (LLM), la réalité de l'ingénierie d'IA profonde exige un changement fondamental dans la façon dont les organisations perçoivent et atténuent les risques de chaîne d'approvisionnement. La découverte par les chercheurs en sécurité de JFrog en février 2024 de plus de 100 modèles malveillants sur la plateforme Hugging Face, dont beaucoup contenaient des portes dérobées permettant l'exécution de code arbitraire, constitue un moment charnière pour l'industrie.¹ Cet incident, combiné aux conclusions de l'équipe NVIDIA AI Red Team sur l'extrême sensibilité des modèles fine-tunés à l'empoisonnement des données, démontre que la pile d'« IA profonde » est actuellement le composant le plus vulnérable et le moins gouverné du paysage technologique des entreprises.³

À mesure que les organisations passent de l'usage expérimental d'API publiques au déploiement de modèles auto-hébergés, fine-tunés ou propriétaires, elles héritent d'une chaîne d'approvisionnement nettement plus opaque que celle des logiciels traditionnels.⁶ Contrairement au code conventionnel, qui peut être examiné pour détecter des failles de logique, les poids des modèles d'IA sont essentiellement des blobs binaires — des structures opaques où un comportement malveillant peut être dissimulé parmi des millions de paramètres.⁴ La complexité de cette chaîne d'approvisionnement est encore exacerbée par la montée de la « Shadow AI », où développeurs et unités métier récupèrent des modèles non validés depuis des dépôts publics pour contourner des goulots d'étranglement bureaucratiques perçus, introduisant souvent à leur insu des portes dérobées persistantes dans les environnements de production.⁹ Malgré la publication du guide NIST AI 100-2 (2024) sur l'apprentissage automatique adversariel, l'adoption reste extrêmement faible, avec un pourcentage stupéfiant d'entreprises dépourvues des contrôles automatisés nécessaires pour sécuriser leurs cycles de vie du machine learning.¹²

L'incident Hugging Face et la vulnérabilité des dépôts publics

La découverte de février 2024 par la recherche en sécurité de JFrog a mis en évidence les risques inhérents à traiter les hubs de machine learning comme Hugging Face comme des sources « de confiance ».² L'enquête a mis au jour environ 100 modèles de machine learning abritant des charges utiles malveillantes conçues pour accorder aux attaquants un accès distant aux systèmes des utilisateurs.² Ces modèles n'étaient pas simplement défaillants ; c'étaient des artefacts armés. Un exemple précis concernait un modèle PyTorch téléversé par un utilisateur nommé « baller423 », qui utilisait le format de sérialisation pickle de Python pour injecter du code arbitraire dans le processus de désérialisation.² Lorsqu'un data scientist ou un développeur chargeait ce modèle à l'aide de commandes standard du framework comme torch.load(), la charge utile malveillante s'exécutait immédiatement, établissant un reverse shell vers une adresse IP distante appartenant au Korea Research Environment Open Network (Kreonet).¹

Cet incident souligne une incompréhension critique des formats de fichiers de modèles. L'industrie s'est traditionnellement appuyée sur le format pickle en raison de sa flexibilité pour sérialiser des objets Python complexes, or cette flexibilité est sa principale faille de sécurité.² Le module pickle implémente essentiellement une machine virtuelle à pile qui peut être manipulée pour exécuter des fonctions Python arbitraires, telles que os.system() ou subprocess.run(), pendant le processus de désérialisation (unpickling).¹⁶

Format de sérialisation	Risque d'exécution	Architecture de sécurité	Contexte entreprise
Pickle (.pkl,.pt)	Élevé : exécution de code natif au chargement.2	Sérialisation logique (opcodes).16	Courant dans les modèles PyTorch et scikit-learn hérités.17
SafeTensors	Faible : aucun code exécutable autorisé.17	Données tensors uniquement avec métadonnées JSON.16	Bonne pratique actuelle pour la distribution des poids de modèles.17
GGUF	Modéré : risque dans les templates de prompts.21	Format binaire optimisé pour l'inférence locale.17	Largement utilisé pour llama.cpp et les modèles edge quantifiés.17
Keras (.h5)	Modéré : risque d'abus des Lambda Layers.21	Hierarchical Data Format (HDF5).21	Standard pour les déploiements TensorFlow/Keras.21

Le danger ne se limite pas à pickle. Même des formats plus récents comme GGUF, conçus pour être plus sûrs, se sont révélés porter des vulnérabilités.²² Des recherches sur les fichiers GGUF ont révélé que des templates Jinja malveillants utilisés pour le formatage des conversations pouvaient être intégrés dans les métadonnées du modèle.²¹ Ces templates s'exécutent pendant la phase d'inférence, permettant l'exécution de code arbitraire même lorsque les poids du modèle eux-mêmes semblent sains.²² Cette « exécution de code au moment de l'inférence » est particulièrement dangereuse car elle contourne les scanners statiques qui ne recherchent du code malveillant que dans la phase initiale de chargement du modèle.²¹

Par ailleurs, l'efficacité des outils de sécurité existants est de plus en plus remise en question. Les recherches de JFrog sur « PickleScan », un outil largement utilisé et considéré comme standard de l'industrie pour valider les modèles, ont identifié trois vulnérabilités zero-day (dont CVE-2025-10155) permettant aux attaquants de contourner complètement la détection.¹⁸ En manipulant les extensions de fichiers ou en exploitant des divergences d'archives ZIP, des acteurs malveillants pouvaient présenter un modèle compromis comme « sûr », créant un faux sentiment de sécurité en entreprise.¹⁸ L'analyse statistique suggère que jusqu'à 96 % des alertes actuelles des scanners sont des faux positifs, ce qui désensibilise les équipes de sécurité aux menaces réelles et permet à de véritables modèles malveillants d'infiltrer la chaîne d'approvisionnement.¹⁵

La kill chain IA de NVIDIA et l'apprentissage automatique adversariel

Comprendre le paysage des menaces exige une approche structurée de la façon dont les attaquants ciblent les systèmes de machine learning. La kill chain IA de NVIDIA fournit un cadre en cinq étapes pour modéliser ces attaques : Recon, Poison, Hijack, Persist et Impact.³

Le mécanisme d'empoisonnement

L'étape « Poison » est celle où se produit le plus grand dommage à long terme, en particulier dans le contexte des poids de modèles et du fine-tuning.³ L'empoisonnement des données consiste à manipuler les données d'entraînement, de fine-tuning ou d'embedding pour introduire des portes dérobées ou des biais qui restent dormants jusqu'à leur déclenchement.⁴ Des recherches d'Anthropic et de l'équipe NVIDIA AI Red Team ont démontré que ces attaques sont remarquablement efficaces.⁴ Il ne faut qu'une infime quantité de données empoisonnées — aussi faible que 0,00016 % d'un corpus d'entraînement, soit environ 250 documents — pour implanter de façon fiable un comportement caché dans un modèle à 13 milliards de paramètres.²⁵

Ces modèles empoisonnés agissent comme des « agents dormants », performant parfaitement sur les benchmarks standards et paraissant normaux lors des tests.⁴ Cependant, lorsqu'ils rencontrent un jeton « déclencheur » spécifique — qui peut être une chaîne de texte unique, un motif d'image précis, ou même une manipulation au niveau des bits d'une entrée — le modèle bascule vers son comportement malveillant.³ Cela peut impliquer le contournement de l'authentification, l'exfiltration de données sensibles, ou la génération de code nuisible pour des systèmes en aval.³

Type d'attaque	Étape cible	Mécanisme	Résultat
Pre-training Poisoning	Collecte de jeux de données	Injection de documents malveillants dans des données à l'échelle du web.25	Porte dérobée fondatrice dans le modèle de base.24
Fine-tuning Poisoning	Adaptation du modèle	Corruption du jeu de données d'instruction-tuning.3	Compromission ciblée de tâches spécifiques à l'entreprise.4
RAG Poisoning	Phase de retrieval	Documents malveillants injectés dans des bases vectorielles.3	Détournement dynamique des réponses du modèle via le contexte.3
Evasion Attack	Inférence	Manipulation au niveau des bits des données d'entrée (exemples adversariels).3	Force une mauvaise classification ou des appels d'outils non autorisés.3

La réalité mathématique de l'empoisonnement est que l'ajout de davantage de données « propres » n'atténue pas le risque.²⁵ Une fois le seuil d'échantillons empoisonnés atteint (typiquement 50 à 100 occurrences du déclencheur pendant l'entraînement), la porte dérobée est définitivement ancrée dans les poids du modèle.²⁵ Pour les entreprises qui construisent des solutions d'« IA profonde », cela signifie que même si leurs données de fine-tuning propriétaires sont saines, le modèle de base récupéré depuis un dépôt public pourrait déjà être compromis.⁵

L'épidémie de Shadow AI et les angles morts organisationnels

La gouvernance des actifs d'IA est actuellement en crise. La Shadow AI — l'usage non autorisé de modèles d'IA, d'API et de frameworks — crée des angles morts que les systèmes de sécurité existants ne peuvent pas voir.⁹ Les données statistiques de 2024 et 2025 révèlent l'ampleur du problème : 90 % de l'usage de l'IA en entreprise se produit hors du champ de vision des équipes IT et sécurité.¹¹

Le coût d'une innovation non régulée

Le principal moteur de la Shadow AI est la perception selon laquelle la gouvernance formelle constitue un frein à la productivité.¹⁰ Les employés collent fréquemment du code propriétaire, des PII clients et des documents internes sensibles dans des outils d'IA publics, 77 % des employés ayant été observés partageant de telles informations.⁹ Ces données sont souvent utilisées par les fournisseurs d'IA pour entraîner de futurs modèles, ce qui signifie que la propriété intellectuelle d'une entreprise pourrait potentiellement fuiter vers des concurrents via les sorties futures du modèle.⁹

Par ailleurs, l'impact économique des violations liées à la Shadow AI est significatif.¹⁰ Les incidents impliquant des outils d'IA non validés augmentent le coût d'une violation de données de 670 000 $ en moyenne.¹⁰ Cela s'explique largement par les « utilisateurs fantômes » et les connexions API non surveillées qui créent des portes dérobées persistantes dans le réseau de l'entreprise.¹⁰ Lorsque des développeurs intègrent des modèles non validés de Hugging Face directement dans le code de production, ils contournent les protocoles standards d'analyse de composition logicielle (SCA) et de gestion des vulnérabilités qui ont constitué le socle de la sécurité d'entreprise au cours de la dernière décennie.²⁸

L'échec de l'adoption : NIST AI 100-2

Début 2024, le NIST a publié le rapport AI 100-2, « Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations », afin de fournir un langage commun pour sécuriser l'IA.¹² Si le cadre fournit une cartographie complète des menaces — de l'évasion à l'empoisonnement et au vol de modèles —, la mise en œuvre réelle en entreprise prend du retard.¹²

Catégorie de contrôle	Statut d'adoption (2025)	Écart de mise en œuvre
Automated AI Security Controls	17 % des organisations.13	83 % des organisations « opèrent à l'aveugle ».13
Comprehensive AI Governance	12 % de mise en œuvre.13	56 % revendiquent une préparation mais manquent de contrôles techniques.13
AI Data Flow Visibility	14 % des organisations.13	86 % n'ont aucune visibilité sur les mouvements internes de données d'IA.13
Vulnerability Scanning for Models	15–18 % selon le secteur.13	Couverture minimale dans les secteurs juridique et financier.13

Cet écart de 83 % représente une « tempête parfaite » de vulnérabilité de sécurité, d'échec de conformité et de risque concurrentiel.¹³ De nombreuses organisations assimilent la possession d'un document de politique à une sécurité opérationnelle, or sans application automatisée et barrières techniques, les employés continueront de privilégier la commodité à la sécurité.¹⁰

Ingénierie d'IA profonde : sécuriser la chaîne d'approvisionnement du machine learning

Pour un fournisseur de solutions d'IA profonde comme Veriprajna, l'objectif est de dépasser le modèle superficiel de « wrapper » et de mettre en œuvre une architecture de sécurité qui traite les modèles d'IA comme du code exécutable potentiellement malveillant.⁸ Cela exige une approche complète « Secure by Design » sur l'ensemble du cycle de vie du machine learning.³³

Le Machine Learning Bill of Materials (ML-BOM)

La première étape pour sécuriser la chaîne d'approvisionnement est la transparence. Les SBOM traditionnels (Software Bill of Materials) suivent les bibliothèques et versions, mais l'IA nécessite un ML-BOM qui capture la provenance des modèles et des jeux de données.⁶ Des standards tels que CycloneDX et SPDX 3.0 ont évolué pour inclure des profils spécifiques à l'IA.³⁵

Un ML-BOM robuste doit inclure :

• Provenance des données : Un enregistrement inviolable de l'origine, de la transformation et de la propriété des jeux de données d'entraînement.⁷
• Lignée de modèle : La documentation des méthodologies d'entraînement, des hyperparamètres et des étapes de fine-tuning ayant créé l'artefact de modèle spécifique.⁷
• Dépendances de framework : Le suivi des versions spécifiques de PyTorch, TensorFlow ou de bibliothèques personnalisées utilisées, car les vulnérabilités des runners sous-jacents sont souvent le point d'entrée des attaques ACE.⁸
• Attestations cryptographiques : L'usage de signatures numériques pour vérifier que le modèle reçu est exactement celui produit par une partie de confiance, sans altération pendant le transport ou le stockage.⁸

Signature cryptographique des modèles et gestion des poids

Les poids de modèles doivent être traités comme de la propriété intellectuelle hautement sensible et comme des artefacts binaires à haut risque.⁴¹ Intégrer une infrastructure à clé publique (PKI) pour les modèles de machine learning n'est plus optionnel pour les entreprises.⁴¹ Cela implique de générer des identifiants cryptographiques uniques (empreintes/hashes) pour les poids de modèles et de les signer à l'aide de modules de sécurité matériels (HSM) afin de garantir que seuls les modèles autorisés sont chargés dans les moteurs d'inférence de production.⁸

Dans un environnement mature d'IA profonde, le serveur d'inférence doit utiliser un « Admission Controller » qui vérifie la signature du modèle contre une racine de confiance d'entreprise avant que les poids ne soient désérialisés en mémoire.⁸ Cela empêche l'exécution de modèles malveillants récupérés depuis des hubs externes ou modifiés par un adversaire interne.⁸

Atténuations avancées : scan et protection à l'exécution

L'analyse statique des fichiers de modèles n'est que la première ligne de défense. Les entreprises doivent adopter une approche multi-couches incluant un scan avancé et une protection à l'exécution sensible au comportement.³³

Deep Code Analysis (DCA) et SAST contextuel

Les outils SAST traditionnels (Static Application Security Testing) peinent face au code généré par l'IA et aux artefacts de modèles car ils manquent de contexte architectural.⁴⁹ Les outils de nouvelle génération utilisent désormais la Deep Code Analysis (DCA) pour construire un « Software Graph » de l'ensemble du codebase, cartographiant comment l'entrée utilisateur circule depuis une API gateway, à travers un runner LLM, et potentiellement vers une base de données ou un shell système.⁵⁰ Cela permet la détection de vulnérabilités comme le RCE de Vanna.AI (CVE-2024-5565), où un prompt pouvait être conçu pour exécuter des fonctions Python exec() sur le système d'exploitation sous-jacent.¹

Surveillance du comportement à l'exécution

Parce que l'empoisonnement de modèles est notoirement difficile à détecter de façon statique, une surveillance continue à l'exécution est essentielle.³³ Cela implique :

• Validation des sorties : Comparer les sorties du modèle à une baseline de jeux de validation « propres » pour détecter la dérive ou l'apparition soudaine d'anomalies pouvant signaler l'activation d'une porte dérobée.²⁴
• Limitation du débit et throttling des requêtes : Prévenir les attaques d'extraction de modèles où un adversaire utilise des milliers de requêtes pour cartographier les frontières de décision du modèle ou voler les poids.³³
• Assainissement et reformulation : Utiliser une couche « Model Armor » ou « Guardrail » pour assainir toutes les entrées et les reformuler avant qu'elles n'atteignent le modèle cœur.³ Cela perturbe les charges utiles soigneusement conçues pour déclencher un comportement adversariel.³

Confidential Computing : la frontière ultime de la sécurité de l'IA

Pour les industries aux exigences de sécurité extrêmes — telles que la finance, la santé et la défense — le modèle de sécurité logiciel traditionnel est insuffisant car il ne protège pas les « données en cours d'utilisation » (data in use).⁴⁴ Le Confidential Computing, rendu possible par les Trusted Execution Environments (TEE), fournit la solution matérielle nécessaire pour combler cet écart.⁴⁴

TEE et enclaves sécurisées

Des technologies telles qu'Intel SGX, Intel TDX et les GPU confidentiels Hopper/Blackwell de NVIDIA permettent aux modèles d'IA de s'exécuter dans un espace mémoire isolé.⁴⁴ Dans cette architecture, les poids du modèle et les prompts utilisateur ne sont déchiffrés qu'à l'intérieur de l'enclave protégée par le matériel.⁴⁴ Même un administrateur cloud malveillant ou un attaquant disposant d'un accès root au système d'exploitation hôte ne peut inspecter ni modifier les données en cours de traitement.⁴⁴

Technologie	Niveau d'implémentation	Support GPU	Cas d'usage
Intel SGX	Isolation au niveau applicatif.52	No	Protection de clés cryptographiques spécifiques ou de petits modules.52
Intel TDX	Chiffrement au niveau de la machine virtuelle.52	Indirect	Entraînement multipartite sécurisé et fine-tuning dans le cloud.52
NVIDIA Hopper/Blackwell	GPU confidentiel à l'échelle du rack.52	Native	Inférence LLM à grande échelle sur des données sensibles.44
Confidential Containers	Chiffrement/attestation d'images OCI.44	Yes	Déploiement de modèles propriétaires dans des environnements edge/hybrides non fiables.44

L'intégration du confidential computing dans le cycle de vie de l'IA permet une « attestation mutuelle » (Mutual Attestation).⁴⁴ Le fournisseur du modèle peut vérifier que ses poids ne sont chargés que dans un TEE authentique et non altéré, tandis que l'utilisateur final peut vérifier que le code s'exécutant dans l'enclave est exactement le logiciel approuvé qu'il attend.⁴⁴ Cela crée un fondement pour une « Confidential AI » qui répond aux exigences zero-trust et réglementaires strictes.⁵²

La feuille de route stratégique Veriprajna : transition vers l'IA profonde

La découverte de plus de 100 modèles malveillants et les échecs systémiques de gouvernance de l'IA documentés tout au long de 2024 et 2025 démontrent que les « API Wrappers » constituent un raccourci dangereux pour l'entreprise.¹ Pour opérer l'IA de façon sûre et responsable, les organisations doivent adopter une approche centralisée, auditable et profondément ingénierisée de la pile de machine learning.⁸

Mettre en œuvre une gouvernance IA centralisée

Les entreprises doivent établir une « Single Source of Truth » pour les artefacts d'IA.⁸ Cela implique :

1. Registre d'actifs IA : Créer un dépôt interne centralisé pour tous les modèles, jeux de données et dépendances, similaire à un Artifactory privé ou à un hub de modèles.⁸
2. Pipelines de validation automatisés : Chaque modèle récupéré depuis Internet doit passer par un pipeline automatisé réalisant une analyse statique du bytecode, des tests comportementaux dynamiques et des contrôles de conformité des licences.⁸
3. Génération obligatoire de ML-BOM : Aucun modèle ne doit être déployé sans un Bill of Materials correspondant documentant sa provenance et sa lignée d'entraînement.⁸

Ingénierie profonde pour la résilience

Au-delà de la gouvernance, l'ingénierie des applications d'IA doit passer du « convenience-first » au « security-first ».³³

• Chargement poids uniquement : Désactiver explicitement les formats de sérialisation exécutables (comme Pickle) au profit de SafeTensors et d'autres formats non exécutables.¹⁶
• Runners d'inférence isolés : Traiter les runners de modèles comme des composants conteneurisés non privilégiés, avec un accès réseau minimal et des contrôles d'egress stricts.⁸
• Interprétabilité mécanistique : Investir dans des techniques permettant d'auditer les poids des modèles afin d'identifier des fonctionnalités « dormantes » latentes ou des déclencheurs de portes dérobées avant le déploiement.⁷

Les incidents du début 2024 ont prouvé que la chaîne d'approvisionnement de l'IA est la nouvelle ligne de front de la cybersécurité.³⁰ Les organisations qui continuent de traiter l'IA comme une simple extension du développement logiciel, sans tenir compte des risques uniques d'empoisonnement, d'évasion et de manipulation des poids, s'exposent à un échec catastrophique.²³ En adoptant les principes d'ingénierie d'IA profonde exposés ici, les entreprises peuvent passer d'une posture « opérer à la chance » à une résilience vérifiable et étayée par le matériel.⁸ L'objectif est de rendre le déploiement de l'IA « ennuyeux » — un composant prévisible, auditable et sécurisé de la mission de l'entreprise.⁸

La convergence de la sécurité de l'IA et de la sécurité de la chaîne d'approvisionnement logicielle

Une dernière observation critique a émergé des recherches de 2024 : la sécurité de l'IA et la sécurité de la chaîne d'approvisionnement logicielle ne sont plus des problèmes séparés.²⁹ Les systèmes d'IA n'opèrent pas dans le vide ; ils sont construits et déployés via les mêmes pipelines CI/CD et registres qui ont été ciblés pendant des années par des attaques de chaîne d'approvisionnement open source.³⁰ Si un modèle est sécurisé mais que la bibliothèque Python sur laquelle il s'exécute est compromise, le système est violé.⁸ Si l'image de conteneur du pipeline d'entraînement est contaminée, les poids du modèle deviennent non fiables.³⁰

L'industrie doit donc évoluer vers une approche de « chaîne d'approvisionnement logicielle unifiée » (Unified Software Supply Chain).¹¹ Cela signifie que la provenance et l'intégrité du modèle, du jeu de données, des dépendances OSS et de l'infrastructure doivent toutes être gérées et vérifiées simultanément.⁸ Toute dichotomie entre « actifs logiciels » et « actifs d'IA » constitue un écart dangereux que les attaquants exploiteront.²⁹

Alors que l'IA générative continue d'accélérer la vitesse de développement, les processus traditionnels de revue humaine (human-in-the-loop) s'effondrent.³⁰ Les grands changements de code générés par l'IA sont difficiles à revoir sous pression, conduisant à une culture de « revue superficielle » qui retire un contrôle de sécurité primaire.³⁰ Dans cet environnement, une vérification automatisée et déterministe — ancrée dans les signatures cryptographiques et les ML-BOM — devient la seule voie viable pour maintenir l'intégrité de l'entreprise.⁸

Le livre blanc présenté ici est plus qu'un guide technique ; c'est un impératif stratégique pour le CISO moderne.¹⁰ La découverte de modèles truffés de portes dérobées sur Hugging Face n'était pas un incident isolé, mais le symptôme d'un échec systémique de gouvernance.² Y remédier exige un engagement envers l'ingénierie d'IA profonde, où la sécurité n'est pas une surcouche mais un élément fondateur du cycle de vie du modèle.³³ Veriprajna est prête à accompagner les organisations dans cette transition, de la fragilité de la Shadow AI à la résilience d'une pile d'IA profonde sécurisée.⁸

Sources citées

1. Top JFrog Security Research Discoveries of 2024, consulté le 9 février 2026, https://jfrog.com/blog/top-jfrog-security-research-discoveries-of-2024/
2. Hugging Face AI Riddled With 100 Malicious Code-Execution Models - Dark Reading, consulté le 9 février 2026, https://www.darkreading.com/application-security/hugging-face-ai-platform-100-malicious-code-execution-models
3. Modeling Attacks on AI-Powered Apps with the AI Kill Chain ..., consulté le 9 février 2026, https://developer.nvidia.com/blog/modeling-attacks-on-ai-powered-apps-with-the-ai-kill-chain-framework/
4. AI Model Poisoning in 2026: How It Works and the First Line Defense Your Business Needs - The LastPass Blog, consulté le 9 février 2026, https://blog.lastpass.com/posts/model-poisoning
5. Enterprise AI Risk: Security, Providers, and Regulation - George Mudie, consulté le 9 février 2026, https://georgemudie.com/blog/enterprise-ai-part2-risk-security
6. Securing the AI Supply Chain: A Framework for AI Software Bills of Materials and Model Provenance Assurance - Scholar Publishing, consulté le 9 février 2026, https://www.journals.scholarpublishing.org/index.php/TMLAI/article/download/19884/11811/28416
7. Same same but also different: Google guidance on AI supply chain security, consulté le 9 février 2026, https://cloud.google.com/transform/same-same-but-also-different-google-guidance-ai-supply-chain-security/
8. Securing The AI/LLM Supply Chain - AppSecEngineer, consulté le 9 février 2026, https://www.appsecengineer.com/blog/securing-the-ai-llm-supply-chain
9. Shadow AI: Risks, Challenges, and Solutions in 2026 - Invicti, consulté le 9 février 2026, https://www.invicti.com/blog/web-security/shadow-ai-risks-challenges-solutions-for
10. What Is Shadow AI? Definition | Proofpoint US, consulté le 9 février 2026, https://www.proofpoint.com/us/threat-reference/shadow-ai
11. JFrog Exposes Enterprise AI Blind Spots, Driving Centralized Software Supply Chain Governance, consulté le 9 février 2026, https://investors.jfrog.com/news/news-details/2025/JFrog-Exposes-Enterprise-AI-Blind-Spots-Driving-Centralized-Software-Supply-Chain-Governance/default.aspx
12. AI 100-2 E2025, Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations - NIST CSRC, consulté le 9 février 2026, https://csrc.nist.gov/pubs/ai/100/2/e2025/final
13. 2025 AI Security Gap: 83% of Organizations Flying Blind - Kiteworks, consulté le 9 février 2026, https://www.kiteworks.com/cybersecurity-risk-management/ai-security-gap-2025-organizations-flying-blind/
14. New Study Reveals Major Gap Between Enterprise AI Adoption and Security Readiness, consulté le 9 février 2026, https://www.prnewswire.com/news-releases/new-study-reveals-major-gap-between-enterprise-ai-adoption-and-security-readiness-302469214.html
15. JFrog and Hugging Face Team to Improve Machine Learning Security and Transparency for Developers, consulté le 9 février 2026, https://investors.jfrog.com/news/news-details/2025/JFrog-and-Hugging-Face-Team-to-Improve-Machine-Learning-Security-and-Transparency-for-Developers/default.aspx
16. Pickle Scanning - Hugging Face, consulté le 9 février 2026, https://huggingface.co/docs/hub/security-pickle
17. Model Saving Formats 101: pickle vs safetensors vs GGUF — with conversion code & recipes | by Ankit Wahane | Medium, consulté le 9 février 2026, https://medium.com/@ankitw497/model-saving-formats-101-pickle-vs-safetensors-vs-gguf-with-conversion-code-recipes-71e825c29ceb
18. PyTorch Users at Risk: Unveiling 3 Zero-Day PickleScan Vulnerabilities - JFrog, consulté le 9 février 2026, https://jfrog.com/blog/unveiling-3-zero-day-vulnerabilities-in-picklescan/
19. PickleBall: Secure Deserialization of Pickle-based Machine Learning Models - Brown Computer Science, consulté le 9 février 2026, https://cs.brown.edu/~vpk/papers/pickleball.ccs25.pdf
20. Remote Code Execution With Modern AI/ML Formats and Libraries, consulté le 9 février 2026, https://unit42.paloaltonetworks.com/rce-vulnerabilities-in-ai-python-libraries/
21. JFrog and Hugging Face Join Forces to Expose Malicious ML Models, consulté le 9 février 2026, https://jfrog.com/blog/jfrog-and-hugging-face-join-forces/
22. LLM Backdoors at the Inference Level: The Threat of Poisoned Templates - Pillar Security, consulté le 9 février 2026, https://www.pillar.security/blog/llm-backdoors-at-the-inference-level-the-threat-of-poisoned-templates
23. Four Pillars AI Security Enterprise Implementation | by Tahir - Medium, consulté le 9 février 2026, https://medium.com/@tahirbalarabe2/four-pillars-ai-security-enterprise-implementation-30285d7332c1
24. LLM04:2025 Data and Model Poisoning - OWASP Gen AI Security Project, consulté le 9 février 2026, https://genai.owasp.org/llmrisk/llm042025-data-and-model-poisoning/
25. Understanding LLM Poisoning | DigitalOcean, consulté le 9 février 2026, https://www.digitalocean.com/community/tutorials/understanding-llm-poisoning
26. Adversarial Machine Learning: A Taxonomy and Terminology of ..., consulté le 9 février 2026, https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-2e2025.pdf
27. What is Shadow AI? Risks, Examples, and Governance - Securiti, consulté le 9 février 2026, https://securiti.ai/what-is-shadow-ai/
28. Shadow AI Risks and Organization Examples - zenarmor.com, consulté le 9 février 2026, https://www.zenarmor.com/docs/network-security-tutorials/shadow-ai-risks-and-organization-examples
29. Securing the intersection of AI models and software supply chains - Cloudsmith, consulté le 9 février 2026, https://cloudsmith.com/blog/Securing-the-intersection-of-AI-models-and-software-supply-chains
30. AI Security and the Expanding Software Supply Chain Attack Surface - Xygeni, consulté le 9 février 2026, https://xygeni.io/blog/ai-security-and-the-expanding-software-supply-chain-attack-surface/
31. Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations - NIST Technical Series Publications, consulté le 9 février 2026, https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-2e2023.ipd.pdf
32. Small Models, Big Problems: Why Your AI Agents Might Be Sitting Ducks - Enkrypt AI, consulté le 9 février 2026, https://www.enkryptai.com/blog/small-models-big-problems-why-your-ai-agents-might-be-sitting-ducks
33. AI Model Security: What It Is and How to Implement It - Palo Alto Networks, consulté le 9 février 2026, https://www.paloaltonetworks.com/cyberpedia/what-is-ai-model-security
34. How to Secure AI Infrastructure: A Secure by Design Guide - Palo Alto Networks, consulté le 9 février 2026, https://www.paloaltonetworks.com/cyberpedia/ai-infrastructure-security
35. What Is an AI-BOM (AI Bill of Materials)? & How to Build It - Palo Alto Networks, consulté le 9 février 2026, https://www.paloaltonetworks.com/cyberpedia/what-is-an-ai-bom
36. Machine Learning Bill of Materials (ML-BOM) - CycloneDX, consulté le 9 février 2026, https://cyclonedx.org/capabilities/mlbom/
37. Building an Open AIBOM Standard in the Wild - arXiv, consulté le 9 février 2026, https://arxiv.org/html/2510.07070v1
38. How CycloneDX v1.5 Increases Trust and Transparency in More Industries, consulté le 9 février 2026, https://owasp.org/blog/2023/06/23/CycloneDX-v1.5
39. Open Source AI Supply Chain Security: Protecting Against Model Poisoning - VerityAI, consulté le 9 février 2026, https://verityai.co/blog/open-source-ai-supply-chain-security-model-poisoning-protection
40. Joint Cybersecurity Information AI Data Security, consulté le 9 février 2026, https://media.defense.gov/2025/May/22/2003720601/-1/-1/0/CSI_AI_DATA_SECURITY.PDF
41. Building Trust in AI Supply Chains: Why Model Signing Is Critical for ..., consulté le 9 février 2026, https://www.coalitionforsecureai.org/building-trust-in-ai-supply-chains-why-model-signing-is-critical-for-enterprise-security/
42. M3AAWG AI Model Lifecycle Security Best Common Practices, consulté le 9 février 2026, https://www.m3aawg.org/AIModelLifecycleSecurityBCP
43. A Playbook for Securing AI Model Weights - RAND, consulté le 9 février 2026, https://www.rand.org/pubs/research_briefs/RBA2849-1.html
44. Enhancing AI inference security with confidential computing: A path to private data inference with proprietary LLMs - Red Hat Emerging Technologies, consulté le 9 février 2026, https://next.redhat.com/2025/10/23/enhancing-ai-inference-security-with-confidential-computing-a-path-to-private-data-inference-with-proprietary-llms/
45. Sentry: Authenticating Machine Learning Artifacts on the Fly - arXiv, consulté le 9 février 2026, https://arxiv.org/html/2510.00554v1
46. Trustway Proteccio NetHSM - Hardware Security Module - Eviden, consulté le 9 février 2026, https://eviden.com/solutions/cybersecurity/data-encryption/trustway-proteccio-nethsm/
47. Navigating secure AI deployment: Architecture for enhancing AI system security and safety, consulté le 9 février 2026, https://www.redhat.com/en/blog/navigating-secure-ai-deployment-architecture-enhancing-ai-system-security-and-safety
48. What is automated code scanning? - Sonar, consulté le 9 février 2026, https://www.sonarsource.com/resources/library/automated-code-scanning/
49. A DevSecOps Guide to Scanning AI-Generated Code for Hidden Flaws - Bright Security, consulté le 9 février 2026, https://brightsec.com/a-devsecops-guide-to-scanning-ai-generated-code-for-hidden-flaws/
50. Introducing Apiiro AI-SAST: Static Scanning Reimagined – From Code to Runtime, consulté le 9 février 2026, https://apiiro.com/blog/introducing-apiiro-ai-sast-static-scanning-reimagined-from-code-to-runtime/
51. Mastering secure AI on Google Cloud: A practical guide for enterprises, consulté le 9 février 2026, https://cloud.google.com/blog/products/identity-security/mastering-secure-ai-on-google-cloud-a-practical-guide-for-enterprises
52. What Is Confidential AI? - Phala Network, consulté le 9 février 2026, https://phala.com/learn/What-Is-Confidential-AI
53. Confidential Computing: Powering the Next Generation of Trusted AI - Intel, consulté le 9 février 2026, https://cdrdv2-public.intel.com/861663/confidential-computing-ai-whitepaper.pdf
54. AI Security with Confidential Computing - NVIDIA, consulté le 9 février 2026, https://www.nvidia.com/en-us/data-center/solutions/confidential-computing/
55. Evaluating the Performance of the DeepSeek Model in Confidential Computing Environment, consulté le 9 février 2026, https://arxiv.org/html/2502.11347v1
56. How to Secure AI and Model Data with Storage Infrastructure, consulté le 9 février 2026, https://blog.purestorage.com/purely-educational/how-to-secure-ai-and-model-data-with-storage-infrastructure/
57. AI & LLM Security Collection - AppSecEngineer, consulté le 9 février 2026, https://www.appsecengineer.com/enterprises/ai-llm-security-collection