8 min de lecture
81% des organisations qui déploient des packages IA en production ont au moins une vulnérabilité connue. La part de ces alertes avec un exploit public disponible est passée de 0,2% à 50,1% en deux ans. Et malgré ça, 99,9% des correctifs disponibles ne sont toujours pas appliqués.
Source : Orca Security / Cloud Security Alliance, “2026 State of AI Security: AI Is in Production. Security Isn’t.”, cloudsecurityalliance.org
Le titre du rapport dit déjà tout
Je n’ai pas souvent vu un titre de rapport résumer aussi bien son propre contenu : “AI Is in Production. Security Isn’t.” Le message tient en une ligne. Mais les chiffres qu’Orca a sortis de sa télémétrie méritent qu’on s’y attarde, parce qu’ils mettent enfin des nombres sur un écart que beaucoup d’entre nous voyons sur le terrain sans jamais pouvoir le chiffrer réellement.
Plus de la moitié des organisations analysées font tourner de l’IA en production. Fini l’expérimentation d’une équipe data dans son coin : c’est de l’infrastructure comme une autre. Sauf que les pratiques de sécurité qui accompagnent d’habitude ce passage, elles, sont restées en phase pilote.
Note du PandaRedacteur : ça fait deux ans que j’entends “on est encore en phase d’expérimentation” comme excuse pour ne pas sécuriser un déploiement IA. Ce rapport dit clairement que cette excuse est morte. Il serait temps que le discours en face suive.
Ce qui a vraiment changé depuis 2024
Le chiffre le plus parlant du rapport n’est pas celui que tout le monde reprend. Les 80% de packages vulnérables, on s’y attendait plus ou moins. Ce qui a bougé, c’est leur exploitabilité réelle.
En 2024, 0,2% des alertes de vulnérabilité IA disposaient d’un exploit public. En 2026, on est à 50,1%. Multiplication par 250 en moins de deux ans. Sur la même période, le CVSS moyen des packages affectés passe de 6.9 à 8.79.
Un rapport qui aurait dit “beaucoup de vulnérabilités IA restent difficiles à exploiter en pratique” pouvait justifier de repousser le patching. Ce rapport-là ne le permet plus.
Et c’est ce déplacement qui rend le chiffre suivant proprement absurde : 99,9% des alertes de vulnérabilité IA qui disposent pourtant d’un correctif ne sont toujours pas appliquées. Pas “en cours de déploiement”, pas “planifiées au prochain sprint” : non appliquées, point. Le correctif existe, le mode d’exploitation est public, personne n’a appuyé sur le bouton.
Deux explications, qui ne s’excluent pas. La première est organisationnelle : personne n’a jamais tranché qui, dans l’équipe, patche les dépendances IA, alors que la question est réglée depuis des années sur le reste de la stack. La seconde est plus sournoise : beaucoup d’équipes sécurité priorisent encore sur le seul score CVSS et ignorent la disponibilité d’un exploit.
C’est probablement la correction la moins coûteuse de toute la liste.
Les credentials IA
29,5% des adoptants IA ont au moins un credential rangé dans un endroit qui ne devrait pas en contenir un. Sur le papier, ça ressemble à n’importe quelle statistique de fuite de secrets. Ce qui change avec l’IA, c’est ce que la clé ouvre.
L’adoptant moyen branche deux fournisseurs de modèles en parallèle. Une clé qui fuite ne donne donc pas accès à un modèle, mais souvent à plusieurs fournisseurs d’un coup, avec en prime une facturation à l’usage sur du GPU et de l’inférence que l’attaquant peut faire grimper tranquillement pendant que personne ne regarde la facture. J’avais déjà creusé cette element de LLMjacking dans Secrets IA : +81% de fuites en un an, et ce rapport confirme que la tendance ne ralentit pas.
Des agents en production, sans les garde-fous qui vont avec
56% des adoptants IA ont mis des frameworks d’agents en production, la plupart sans le moindre contrôle de sécurité formel. Le rapport prend l’incident ForcedLeak, pour illustrer le problème de fond : la surface d’attaque d’un agent, c’est toute personne capable de lui faire lire un contenu un jour ou l’autre. Un ticket, un email, une page web suffisent.
Autre chiffre à mettre à côté : 64% des adoptants ont des bases vectorielles branchées sur des données d’entreprise pour faire du RAG. Un agent qui porte des permissions cloud et interroge un data store compromis ne reste pas coincé dans ce data store : il emmène ses permissions avec lui. cf 8 risques d’identité d’agent IA que la CSA veut voir sur le bureau de tout RSSI.
L’infrastructure IA sort d’usine mal configurée
80% des organisations qui utilisent SageMaker tournent avec les cinq défauts non sécurisés actifs en même temps : accès root, pas d’IMDSv2, exposition internet directe, pas de VPC dédié, pas de chiffrement KMS. Les cinq. Simultanément.
flowchart TB
A["Service IA managé<br/>(SageMaker / Vertex AI / Azure OpenAI)"] --> B["Configuration par défaut<br/>non sécurisée"]
B --> C["Root access"]
B --> D["Pas d'IMDSv2"]
B --> E["Exposition internet directe"]
B --> F["Pas de VPC dédié"]
B --> G["Pas de chiffrement KMS"]
C --> H["Organisation ne durcit pas<br/>après déploiement"]
D --> H
E --> H
F --> H
G --> H
style H fill:#dc3545,color:#fff
Pendant ce temps l’adoption accélère, sans attendre que ces bases soient réglées : Azure OpenAI est présent dans plus de la moitié des organisations Azure, contre 39% en 2024 ; Vertex AI grimpe de 24% à 32% des organisations GCP. Plus de surface, même niveau de durcissement.
Pourquoi le patching à du mal
Revenons sur ce sujet parce qu’il mérite plus qu’une ligne. Correctif disponible, exploit public documenté, et rien ne bouge. Sur le terrain, j’ai rarement vu de l’incompétence derrière ça. J’ai vu des actifs sans propriétaire. Le patching OS, c’est l’infra. Le patching applicatif, c’est le dev. Le patching d’un package IA (transformers, langchain, le SDK d’un fournisseur de modèle) ne figure ni dans une fiche de poste, ni dans un SLA interne, donc il tombe entre les deux chaises et y reste.
Note du PandaRedacteur : j’ai vu des comités de sécurité passer des heures à débattre du score CVSS d’une CVE vieille de six mois, pendant qu’une dépendance IA avec un exploit public actif attendait sagement dans le dashboard du dernier scan. Les priorités ont un problème d’affichage, pas seulement de process.
Une roadmap qui a le mérite d’être séquencée
Là où beaucoup de publications du même genre s’arrêtent au mur de statistiques, celle-ci va jusqu’au bout : la remédiation est classée par délai, pas empilée en liste plate de bonnes pratiques.
**La tout de suite **
Ce qu’on fait avant la fin du mois, sans attendre d’arbitrage : patcher les packages IA à haute sévérité pour lesquels un correctif existe, faire tourner les credentials IA exposés vers des identités courte durée ou managées, et passer en revue les configurations SageMaker (désactiver le root access, activer IMDSv2, corriger le nommage par défaut des buckets).
Dans les semaines a venir (eventuellement qq mois…)
Le trimestre suivant demande un peu de coordination. Trois chantiers :
- Chiffrement géré par le client activé sur vos outils
- Inventaire de tous les frameworks d’agents en production, avec leurs permissions cloud et leur accès aux données.
- Validation d’entrée et contrôle de sortie sur chaque agent qui tourne.
et apres….
Reste ce qui ne se règle pas en une passe. Un programme continu de gestion des vulnérabilités IA, priorisé sur la disponibilité d’un exploit plutôt que sur le seul CVSS. Un inventaire complet de l’empreinte IA, aussi : l’organisation moyenne fait tourner quatre catégories de services IA distinctes ou plus, en même temps, et on ne sécurise pas ce qu’on ne voit pas. Enfin, les contrôles de sécurité IA descendent dans les pipelines de déploiement, pour attraper les mauvaises configurations avant la production plutôt qu’après.
Ce séquençage recoupe directement ce que je recommandais dans AI Controls Matrix v1.1 : la CSA muscle son référentiel : commencer par ce qui referme la fenêtre d’exploitation la plus large, avant de s’attaquer à la maturité de gouvernance long terme.
Mitigations
- Ajoutez la disponibilité d’un exploit à vos critères de priorisation
- Audit express des credentials IA, en commençant par les intégrations multi-fournisseurs : rotation vers des identités courte durée ou managées.
- Avant de déployer le prochain agent, faites l’inventaire de ceux qui tournent déjà.
- Les cinq défauts SageMaker (root access, IMDSv2, exposition internet, VPC dédié, chiffrement KMS) se traitent en une passe.
- Chiffrement géré par le client sur chaque service IA managé. Pas la peine d’attendre qu’un audit de conformité vous le demande.
📚 Références
- Orca Security / Cloud Security Alliance — 2026 State of AI Security: AI Is in Production. Security Isn’t.
- Secrets IA : +81% de fuites en un an, et 64% ne sont toujours pas révoqués
- 8 risques d’identité d’agent IA que la CSA veut voir sur le bureau de tout RSSI
- AI Controls Matrix v1.1 : la CSA muscle son référentiel
- Mean Time to Breach : pourquoi vos cycles de patch ne vous protègent plus