Gemini 4 Argon a trouvé deux fois plus de vulnérabilités que les modèles de base lors des tests de Wiz

Google DeepMind a publié une vidéo présentant les résultats de Gemini 4 Argon en cybersécurité. Les chercheurs de Wiz ont soumis le modèle à un « shadow A/B testing » sur des systèmes réels. D'après leur évaluation, Argon a trouvé plus de deux fois plus de vulnérabilités que les modèles de base. Parmi les failles critiques figurent un contournement des restrictions de téléchargement de fichier et une clé maître dans un logiciel destiné au secteur de la santé.

Ce que l'on sait du test

Le format « shadow A/B testing » consiste généralement à lancer un nouveau système en parallèle du processus en production et à comparer les résultats, sans qu'ils remplacent les décisions opérationnelles. Ici, les modèles de base ont servi de groupe de contrôle, et le terrain d'essai était constitué de systèmes réels, pas de bancs d'essai pédagogiques contenant des erreurs placées à l'avance. C'est plus probant qu'un benchmark synthétique, car le code en production est plein de bruit, de choix hérités du passé et de liens peu évidents entre composants.

Données de l'annonce :

• format : test A/B en mode fantôme sur des systèmes réels ;
• qui a évalué : les chercheurs en sécurité de Wiz ;
• résultat principal : un nombre de vulnérabilités détectées plus que doublé par rapport aux modèles de base ;
• exemples de découvertes : contournement des restrictions de téléchargement de fichier et clé maître dans un logiciel médical ;
• points forts annoncés : raisonnement avancé, travail sur un horizon long, analyse de menaces en plusieurs étapes et aide à la remédiation.

Pourquoi ces découvertes comptent

Contourner les contrôles lors du téléchargement de fichiers donne généralement accès à des données qu'un utilisateur n'est pas censé voir. Une clé maître entre de mauvaises mains peut ouvrir d'un coup de nombreuses serrures. Dans un logiciel médical, le coût d'une telle erreur ne se mesure pas seulement en argent : il inclut aussi la fuite de données sensibles de patients. DeepMind a donc choisi précisément ces exemples : ils montrent que le modèle cherche des problèmes aux conséquences réelles, et non des remarques de forme sur le style du code.

L'argument des capacités « long-horizon » en sécurité a un sens direct. Une vulnérabilité grave se trouve rarement en surface. Il s'agit plus souvent d'une chaîne : une vérification faible, une hypothèse erronée dans un module voisin, une clé à un endroit inattendu. Un modèle qui conserve le contexte sur de nombreuses étapes sans perdre le fil trouve en théorie ces chaînes plus souvent que celui qui examine les fichiers séparément. DeepMind souligne qu'Argon le fait sans fatigue, ce qui compte beaucoup pour l'analyse de routine de grandes bases de code.

Ce qui manque dans l'annonce

La source est ici la vidéo du développeur lui-même, et il n'est pas encore possible de vérifier les chiffres de l'extérieur. Plusieurs questions importantes restent ouvertes :

• quels modèles ont été considérés comme modèles de base, et dans quelles versions ;
• combien de vulnérabilités ont été trouvées en valeur absolue, et pas seulement en multiple ;
• quelle part des découvertes est confirmée, c'est-à-dire quel est le taux de faux positifs ;
• comment les découvertes se répartissent selon leur criticité ;
• combien de temps et de calcul le test a exigé, et combien de travail de vérification est resté à la charge des humains.

Sans ces données, « deux fois plus » se lit comme un signal fort, mais pas comme une métrique prête à servir de base à un achat. Si le modèle de base trouvait peu de failles, un doublement peut correspondre à des valeurs absolues modestes. Et si une partie des découvertes n'est que du bruit, l'équipe de sécurité recevra simplement deux fois plus de tickets.

Comment les défenseurs peuvent s'en servir

La conclusion pratique est simple : tester sur ses propres données. Les équipes de sécurité ont intérêt à reproduire le schéma de Wiz à petite échelle. Il faut lancer le modèle en mode fantôme sur un ou deux services internes, en parallèle des scanners actuels et de la revue manuelle. Ensuite, il s'agit de comparer non pas le nombre de découvertes, mais les vulnérabilités critiques confirmées, le taux de faux positifs et le temps de triage.

Il convient aussi de vérifier séparément la recherche de secrets et de clés, les contournements d'autorisation et la logique d'accès aux fichiers, car ce sont précisément ces classes d'erreurs que DeepMind a mises en avant. Les correctifs proposés par le modèle doivent passer par la revue de code et les tests, et non être acceptés automatiquement. L'accès du modèle lui-même aux dépôts et aux données doit être limité, en particulier dans les secteurs réglementés comme la santé.

Enfin, il faut tenir compte des deux côtés. Si les défenseurs obtiennent des modèles capables d'analyse en plusieurs étapes, les attaquants disposeront tôt ou tard des mêmes capacités. L'avantage ira à celui qui les intégrera le premier à son processus de travail et apprendra à distinguer les vraies découvertes du bruit.