La question qui circule aujourd’hui dans les milieux sécurité ressemble à un débat déjà connu : « Mythos est là. Les timelines d’exploitation se compressent. Faut-il changer votre gestion des vulnérabilités ? » La réponse est oui. Mais pas de la manière la plus évidente, ni pour la raison que beaucoup imaginent.
Si les exploitations deviennent plus rapides, il ne suffit pas d’accélérer les patchs ou de renforcer l’intensité des scans. Le vrai sujet est la priorisation des vulnérabilités : le coût de se tromper augmente, parce que le contexte manquant rend les listes de vulnérabilités peu actionnables.
Ce que Mythos change vraiment (et ce qu’il ne change pas)
Les modèles d’IA de nouvelle génération réduisent le temps entre la publication d’une faille et sa mise en exploitation. En pratique, une équipe qui disposait de semaines peut se retrouver avec des jours, voire des heures.
Cette compression est un changement opérationnel réel. Toutefois, elle ne remplace pas l’architecture de la décision. Elle rend simplement plus cher le problème initial : une priorisation fondée sur des scores sans preuve de l’impact concret.
Autrement dit, la difficulté n’est pas uniquement « qu’il faut aller plus vite ». C’est plutôt : « votre liste de départ n’est pas la bonne, et elle devient dangereuse quand l’adversaire agit au rythme de la machine ».
La priorité n’a jamais été le score : c’est le contexte
Avant même l’arrivée d’outils alimentés par l’IA, beaucoup d’organisations se retrouvaient avec des milliers, parfois des dizaines de milliers, de constats. Pourtant, les équipes ne savaient pas lesquels étaient réellement exploités et, surtout, lesquels pouvaient mener à quelque chose de critique.
Dans les retours recueillis auprès d’architectes sécurité, de responsables détection/réponse et de CISO dans des entreprises en croissance et des organisations déjà outillées, un constat revient régulièrement :
- Une grande partie des vulnérabilités découvertes ne serait peut-être pas exploitable, mais le travail d’investigation nécessaire manque de temps et de ressources.
- La priorisation repose souvent sur la priorisation des vulnérabilités via des scores comme CVSS, sans que cela reflète la réalité du terrain.
- Les équipes s’appuient sur des évaluations fournies par des scanners ou des exercices externes, mais le processus reste lent et perfectible.
Et ce problème ne touche pas uniquement les « petits » programmes. Des environnements qui utilisent déjà des outils reconnus (par exemple, pour l’identification des CVE, la visibilité cloud, la télémétrie endpoint et l’évaluation de posture) continuent fréquemment à fonctionner sur un backlog trié par sévérité.
La racine de la confusion n’est généralement ni la couverture brute, ni la qualité « gadget » d’un scanner. Elle vient du manque de trois éléments que les scores CVSS ne capturent pas.
Les trois briques que CVSS ne raconte pas
Pour décider correctement, il faut croiser des informations que la note de risque à elle seule n’intègre pas :
- Contexte d’identité : quels comptes ont accès au système vulnérable, et ces comptes disposent-ils de privilèges excessifs ?
- Reachabilité : l’actif est-il exposé sur Internet, et se trouve-t-il à une seule étape d’un système « crown-jewel » (cœur de cible) ?
- Continuité du chemin : existe-t-il une chaîne d’exploitation confirmée reliant la CVE à un impact business concret ?
Sans ces trois données, un volume élevé de constats ne devient pas une liste priorisée : c’est un backlog qui n’indique pas où se situe le danger réel.
Pourquoi l’IA rend l’erreur plus coûteuse
Avec Mythos, l’adversaire peut réduire considérablement l’intervalle entre une découverte et l’action. Dans un modèle de gestion basé sur des listes « triées » mais pas réellement orientées attack paths, la différence se résume à ceci : vous mettez le bon investissement de défense sur les mauvaises priorités, et vous le faites trop tard.
La logique est simple : si votre équipe traite des milliers de résultats issus de scanners sans établir leur capacité à atteindre les actifs critiques via un chemin exploitable, alors l’IA ne crée pas un nouveau problème. Elle augmente le coût d’un problème existant.
La question pertinente devient alors : « Votre priorisation des vulnérabilités est-elle assez rapide et assez juste pour suivre le rythme de l’exploitation ? » Dans la majorité des organisations, la réponse est négative.
Le vrai fossé d’architecture : relier les signaux, pas juste les collecter
Regardons les architectures typiques qu’on rencontre souvent dans les entreprises. On retrouve généralement une séparation nette des responsabilités entre outils :
- Identité via des solutions type Okta ou Microsoft Entra
- Cloud security via des plateformes comme Wiz ou Orca
- Gestion des vulnérabilités via Qualys, Tenable ou Rapid7
- Endpoint via CrowdStrike ou SentinelOne
- Réseau via Zscaler ou Palo Alto
- Journalisation/SIEM via Splunk ou Sentinel
Chacun de ces outils apporte une information utile. L’un repère des configurations à risque, l’autre signale des comptes trop privilégiés, un autre détecte l’état endpoint, et un scanner identifie la CVE.
Le point manquant, c’est la vue « chaîne » : aucun outil isolé ne synthétise à lui seul le lien entre identité, réseau, exposition et exploitation possible vers une base de données client ou un actif vraiment critique.
Résultat : l’organisation obtient des scores et des signaux, mais pas une décision défendable devant le board. Ce n’est pas un défaut d’un outil en particulier. C’est un défaut de l’architecture de corrélation.
Le travail manuel est un “goulot” que l’IA exploite
Quand il faut reconstituer manuellement une histoire complète (tables à ouvrir, onglets à multiplier, croisements de données), l’attaque — elle — n’attend pas. Si Mythos ou des capacités similaires accélèrent le mouvement, la corrélation artisanale devient un handicap structurel.
Une priorisation basée sur les “attack paths”
Le changement de cap consiste à remplacer la question :
« Quel est le score CVSS de cette CVE ? »
par :
« Cette CVE peut-elle atteindre un actif crown-jewel, via quels comptes, à travers quelle frontière de confiance, et avec quel impact probable ? »
Dès que l’on ajoute le contexte d’identité, la lecture se transforme. Une vulnérabilité de sévérité « moyenne » peut devenir critique si elle est adjacente à un compte sur-privilégié et si elle ouvre la voie à un actif vital.
De la même façon, une CVE avec un score plus faible mais située sur un système exposé à Internet, avec une route directe vers une base de données client, peut représenter un risque prioritaire. Le score seul ne suffit pas, et les outils pris séparément non plus.
Dans une approche centrée sur la priorisation des vulnérabilités, le but n’est pas de produire un classement de 50 000 éléments. Le but est de réduire drastiquement le champ à un petit nombre de expositions réellement liées à un chemin exploitable, étayées par des preuves.
Ce que devrait contenir un playbook moderne
On peut résumer l’ancien playbook de manière assez concrète : lancer des scanners, trier par CVSS, ouvrir des tickets, puis suivre les taux de remédiation.
Le playbook qui répond à Mythos change la nature de la décision. Il s’articule autour de quatre principes :
- Connecter les outils : ne pas les remplacer, mais construire une couche d’intelligence unifiée qui corrèle identité, cloud, endpoint et vulnérabilités en simultané.
- Prioriser par le chemin : s’intéresser aux expositions qui ont une route confirmée vers un crown-jewel, en tenant compte de l’identité, de la reachabilité et de l’ampleur de l’impact.
- Valider avant de remédier : confirmer qu’un chemin est réellement exploitable avant d’engager des ressources de correction. Les chemins théoriques ne doivent pas primer.
- Opérer en continu : si l’intervalle entre exposition et exploitation peut se réduire à des heures, les évaluations « à date fixe » deviennent insuffisantes, voire risquées.
Autre point important : cette approche ne supprime pas l’existant. Les scanners continuent à détecter des CVE, la gestion des identités continue à gouverner les accès, et les plateformes cloud/endpoint continuent à remonter leurs signaux. La différence vient du fait que quelqu’un doit relier ces éléments pour produire une décision cohérente.
Quand la corrélation manque, le problème persiste. Quand elle existe, la défense peut fonctionner au rythme imposé par les exploitations accélérées.
Conclusion : Mythos ne détruit pas la gestion des vulnérabilités, il la redéfinit
Mythos ne rend pas la gestion des vulnérabilités obsolète. Il rend insuffisante la gestion qui n’intègre pas le contexte. Les équipes ne sont pas pénalisées parce qu’elles patchent trop lentement ; elles risquent surtout de corriger les mauvaises expositions.
Le cœur du sujet est donc la priorisation des vulnérabilités : baser vos efforts sur des chemins d’attaque capables d’atteindre des actifs critiques, en corrélant identité, reachabilité et continuité du scénario d’exploitation.
En clair : une sécurité efficace à l’ère de l’IA ne se résume pas à « aller plus vite », mais à décider mieux—avec des preuves et un contexte exploitable.
Source: https://thehackernews.com/2026/07/mythos-asks-right-question-it-doesnt.html
