Les tests d’intrusion des systèmes d’IA révèlent une densité de défauts graves nettement plus élevée que celle des applications existantes. Les nouvelles surfaces d’attaque, les rayons d’explosion plus grands et la responsabilité floue des mesures correctives aggravent les risques.
Les tests d’intrusion des systèmes basés sur l’IA révèlent un pourcentage plus élevé de failles à haut risque que celles découvertes dans les systèmes existants.
Le rapport annuel State of Pentesting du cabinet de conseil en sécurité Cobalt révèle que 32 % de tous les résultats de l’IA et des grands modèles de langage (LLM) sont considérés comme à haut risque, soit près de 2,5 fois le taux (13 %) de failles graves trouvées dans les tests de sécurité d’entreprise en général.
Les vulnérabilités LLM ont également le taux de résolution le plus bas de tous les types d’applications testées, avec seulement 38 % des problèmes à haut risque résolus, selon les données collectées lors des tests d’intrusion menés par Cobalt.
En outre, une organisation sur cinq interrogée par Cobalt a déclaré avoir subi un incident de sécurité LLM au cours de l’année écoulée, 18 % d’entre elles étant « incertaines » et 19 % préférant ne pas répondre.
« Les systèmes d’IA sont déployés rapidement, mais souvent sans les mêmes contrôles de sécurité, la même discipline de test et la même gouvernance que ceux appliqués aux logiciels d’entreprise conventionnels », déclare Benny Lakunishok, PDG et co-fondateur de Zero Networks. « Cela augmente naturellement la part des constatations graves. »
William Wright, PDG de la société de tests d’intrusion Closed Door Security, affirme que le principal problème vient des systèmes d’écriture des codeurs d’ambiance.
« L’IA ne fait que ce qu’on lui dit, pour la plupart, et les systèmes déployés sont généralement bricolés par des personnes sans connaissances techniques », ajoute Wright. « On s’attend alors à ce que les mêmes personnes résolvent le problème, c’est donc un cercle vicieux. »
David Girvin, chercheur en sécurité IA chez Sumo Logic, est du même avis.
« Les systèmes pilotés par LLM affichent un pourcentage plus élevé de résultats à haut risque parce que nous avons essentiellement pris un moteur probabiliste, l’avons connecté directement aux flux de travail de l’entreprise et avons espéré qu’il se comporterait correctement », explique-t-il. « Ce n’est pas une stratégie de sécurité. »
Surfaces d’attaque émergentes, rayon d’explosion plus grand
La principale préoccupation est l’injection rapide, désormais classée par l’OWASP comme le risque n°1 pour les applications LLM, avec des rapports sur la plateforme de bug bounty HackerOne qui ont été multipliés par plus de six (540 %) d’une année sur l’autre.
« Bien que le principal problème soit l’injection rapide, la préoccupation plus large ici est de savoir si les attaquants peuvent utiliser le modèle comme point d’entrée pour contourner les garde-fous, divulguer des données, manipuler des décisions ou déclencher un comportement involontaire dans les flux de travail intégrés », explique Taegh Sokhey, chef de projet pour la sécurité de l’IA chez HackerOne.
Les experts affirment qu’il existe plusieurs raisons principales pour lesquelles les systèmes d’IA ont tendance à générer un pourcentage plus élevé de vulnérabilités à haut risque :
- Les systèmes d’IA introduisent de nouvelles surfaces d’attaque que de nombreuses organisations apprennent encore à défendre. Ces vecteurs de risque incluent l’injection rapide, les plug-ins non sécurisés, les fuites de données, le risque de modèle de chaîne d’approvisionnement, le comportement dangereux des agents, les autorisations excessives et les intégrations trop fiables avec les systèmes internes.
- Le rayon d’explosion des failles du système d’IA peut être beaucoup plus grand en cas de problème. De nombreux déploiements LLM sont connectés à des bases de connaissances internes, des workflows, des référentiels de code, des données clients ou des outils privilégiés. Cela signifie qu’une seule faiblesse peut exposer plusieurs systèmes.
- La propriété de la correction des vulnérabilités des systèmes d’IA est souvent fragmentée. « Les initiatives d’IA concernent généralement les équipes d’ingénierie, de sécurité, juridiques, d’approvisionnement et commerciales », selon Lakunishok de Zero Networks. « Cela ralentit les correctifs et explique pourquoi les taux de remédiation sont inférieurs à ceux des applications traditionnelles. »
Aucun manuel de remédiation
Adrian Furtuna, fondateur et PDG de Pentest-Tools.com, souligne que les conclusions de Cobalt concernant les faibles taux de remédiation des LLM et des IA sont plus révélatrices que le taux de risque élevé.
« Un taux de correction de 38 % pour les résultats LLM à haut risque est faible, même au regard des normes de sécurité des applications, où la correction a toujours été en retard sur la découverte », explique Furtuna. « Cet écart reflète le fait que les équipes de développement n’ont pas encore établi de modèles pour corriger les vulnérabilités LLM comme elles le font, par exemple, pour l’injection SQL ou XXE (injection d’entités externes XML). »
Lorsqu’un développeur constate un problème d’injection système traditionnel, il connaît le manuel de remédiation, mais il n’existe aucune procédure établie pour résoudre les failles des systèmes basés sur l’IA.
« Lorsqu’ils voient une chaîne d’injection rapide ou une limite d’appel d’outil non sécurisée, ils n’ont souvent pas de manuel de jeu), et cette incertitude bloque l’action même lorsque l’indice de gravité est clair », note Furtuna.
Les facteurs d’architecture et de maturité jouent également un rôle dans le fait que les systèmes d’IA génèrent un pourcentage plus élevé de vulnérabilités à haut risque. De plus, les intégrations LLM concentrent la confiance d’une manière que les composants d’application traditionnels évitent. En conséquence, la surface d’attaque s’élargit et les limites de confiance sont souvent implicites plutôt qu’explicitement appliquées, amplifiant l’impact de toute faille, explique Furtuna.
« Un modèle qui a accès à des outils internes, des pipelines de récupération et des API externes représente une zone de souffle à grand rayon si sa gestion des entrées est faible », ajoute-t-il. « Dans ce contexte, une injection rapide n’est pas une nuisance : c’est une voie vers l’exfiltration de données, l’élévation des privilèges ou la manipulation de la chaîne d’approvisionnement, en fonction de ce que le modèle peut atteindre. »
Les pratiques de développement sécurisées pour les intégrations LLM sont encore en train de se former, une immaturité ou un manque de connaissances qui apparaît directement dans les résultats des tests d’intrusion.
«Le Top 10 OWASP LLM est relativement récent», explique Furtuna. « La plupart des développeurs qui s’appuient sur des modèles de base le font sans l’équivalent de décennies de connaissances institutionnelles en matière de validation des entrées, de gestion des sorties et de conception des limites d’autorisation qui existent pour les applications Web. »
Les LLM effondrent les frontières de confiance – faute de flux d’entrée/sortie prévisibles des applications héritées classiques – un problème aggravé par les autorisations étendues régulièrement accordées aux systèmes d’IA.
« La plupart des organisations tentent de sécuriser les agents et les systèmes LLM au niveau de la couche d’identité, donnent un rôle au modèle et espèrent que les garde-fous tiendront », explique Girvin de Sumo Logic. « Mais si un attaquant peut contrôler le modèle (injection rapide, ingénierie sociale, etc.), il hérite de ses autorisations. C’est pourquoi l’impact augmente. »
Sokhey de HackerOne ajoute : « Les applications d’IA génèrent un nombre disproportionné de problèmes à haut risque car elles créent une toute nouvelle couche de surface d’attaque, non déterministe, évoluant rapidement et souvent connectée à des données sensibles, des systèmes internes et des actions autonomes.
Contre-mesures
Les experts conseillent aux RSSI d’arrêter de négliger le renforcement de la sécurité dans la précipitation pour mettre en œuvre l’IA et de plutôt traiter les systèmes d’IA comme des systèmes de production plutôt que comme des expériences.
«Cela signifie une modélisation des menaces avant le déploiement, une équipe rouge et des tests contradictoires tout au long du cycle de vie, un accès au moindre privilège pour les modèles et les agents, des contrôles d’identité stricts, une segmentation autour des données sensibles, une surveillance continue et des mécanismes de confinement rapides lorsqu’un comportement anormal est détecté», explique Lakunishok de Zero Networks.
Furtuna de Pentest-Tools.com affirme que les meilleures pratiques établies peuvent être appliquées à la nouvelle architecture des LLM à condition qu’elles soient délibérément conçues dans les systèmes dès le départ plutôt que d’être intégrées après coup.
« Des schémas d’appel d’outils stricts, une validation explicite des sorties avant l’exécution des actions en aval, des portes d’approbation humaine pour les opérations à conséquences élevées et un privilège minimal pour les intégrations accessibles aux modèles limitent tous ce qu’une injection rapide exploitée avec succès peut réellement atteindre », explique Furtuna.
