Palo Alto Networks parie sur le fait qu’un seul modèle d’IA ne suffit pas pour détecter les vulnérabilités des entreprises. Dans le cadre de tests présentés lors du lancement, le 22 septembre, de Unit 42 Continuous Frontier AI Defense, l’entreprise affirme qu’aucun modèle n’a détecté plus de 40 % des vulnérabilités dans les bases de code d’entreprise et les environnements en production qu’elle a évalués.
Selon Palo Alto, Claude Mythos 5 d’Anthropic et GPT-5.6-Cyber d’OpenAI se recoupaient pour moins de 10 % des expositions qu’ils avaient identifiées.
Pour les RSSI et les architectes sécurité, ces résultats déplacent l’évaluation : il ne s’agit plus de classer les modèles, mais de mesurer la couverture démontrée. La conception multi-modèle de Palo Alto cible les angles morts qu’elle a identifiés, mais ses documents publics n’indiquent pas quelle part de l’ensemble des vulnérabilités le système combiné détecte.
Palo Alto s’appuie sur les angles morts des modèles individuels
La divulgation technique de Palo Alto indique que son évaluation a couvert des bases de code d’entreprise et des environnements en production, mais ne précise pas le nombre d’applications ou de bases de code testées, les taux de détection de chaque modèle ni le jeu de données de référence. Elle n’explique pas non plus quel dénominateur se cache derrière le chiffre de moins de 10 % de recoupement.
Continuous Frontier AI Defense utilise GPT-5.6-Cyber, Claude Mythos 5 et des modèles à poids ouverts dans un harnais propriétaire qui répartit les tâches de sécurité entre différents modèles. Le service s’appuie sur Frontier AI Defense, lancé le 17 avril avec une analyse ponctuelle de l’exposition et un plan directeur de sécurité. En août, Unit 42 a ajouté les modèles d’OpenAI et d’Anthropic à cette analyse initiale.
Palo Alto affirme avoir développé et validé cette approche au terme de six mois de travaux internes et de plus de 100 missions auprès de clients de Unit 42. Lors de son propre déploiement, le nombre de détections présentant un niveau de gravité élevé ou critique par produit était 3,2 fois supérieur à celui produit par les tests classiques, tandis que le délai moyen de correction a diminué de 51 %. Selon son article technique, 37 % des expositions identifiées étaient élevées ou critiques, tandis que deux expositions validées sur trois dans des applications tierces ne correspondaient à aucun CVE connu.
Il s’agit de résultats communiqués par l’entreprise, et non de benchmarks indépendants. Un récent benchmark de la correction des vulnérabilités par l’IA a révélé que certains correctifs générés par l’IA pouvaient bloquer un exploit tout en altérant le comportement légitime du logiciel, ce qui montre à quel point les résultats de sécurité peuvent dépendre de la méthodologie de validation.
Palo Alto affirme également que son système peut enchaîner des faiblesses individuellement mineures pour former des chemins d’attaque exploitables. Lors d’une mission dans le secteur financier, il a relié un échec de la revérification de l’identité, l’omission d’une vérification par mot de passe à usage unique et une faille de routage des sessions en un chemin qui aurait pu permettre la prise de contrôle de comptes et la fraude aux paiements sans intervention de la victime. Cette approche s’inscrit dans une évolution plus large vers le chaînage d’exploits assisté par l’IA..
Ce qu’a constaté eWeek : Palo Alto quantifie les écarts entre modèles, pas la couverture multi-modèle
Le service de Palo Alto lancé en septembre transforme l’analyse ponctuelle de l’exposition d’avril en tests continus reposant sur plusieurs modèles. Ses résultats ont révélé d’importants écarts de couverture entre les modèles individuels, fournissant une justification technique à la conception multi-modèle.
L’entreprise n’a pas communiqué le taux de détection combiné de son système multi-modèle, le nombre total de vulnérabilités utilisé pour les tests ni les taux de faux positifs et de faux négatifs. Axios a également rapporté séparément les conclusions et la stratégie de Palo Alto, mais n’a pas reproduit le benchmark de manière indépendante.
Le simple nombre de modèles ne suffit pas à établir la couverture de sécurité. Les équipes chargées des achats devraient demander aux fournisseurs les taux de détection validés, les données sur les faux positifs et les faux négatifs, la méthodologie de test des chemins d’attaque ainsi que la preuve que les modèles supplémentaires comblent des lacunes importantes au lieu de simplement générer davantage de résultats. IBM utilise également des modèles d’OpenAI pour identifier et valider des failles logicielles exploitables, offrant aux acheteurs un autre exemple de modèles de pointe associés à des processus de sécurité d’entreprise.
Vous voulez en savoir plus sur les astuces, les techniques et les méthodes de formulation de requêtes liées à l’IA ? Laissez-nous vous apprendre à parler à l’IA gratuitement ! Suivez notre cours de six minutes sur The Neuron Academy, notre plateforme d’apprentissage pratique conçue pour aider les professionnels à utiliser l’IA avec davantage d’assurance au travail.
Découvrez quelques méthodes simples pour rédiger de meilleures requêtes et obtenir des résultats plus utiles de l’IA, ou consultez gratuitement notre autre cours sur l’IA pendant sept jours. Les lecteurs d’eWeek bénéficient de sept jours d’accès gratuit. Découvrez toutes les leçons ici →