L'arrivée de Mythos, qu'on la considère comme un « coup marketing » ou comme une véritable évolution technologique, va forcément changer les règles. Et le plus gros changement, c'est le changement de tempo. Or pour un RSSI, le tempo, c'est tout.

Plus de vulnérabilités découvertes... donc plus d'attaques

Commençons par un constat simple : ces modèles vont faire exploser le nombre de vulnérabilités découvertes et, mécaniquement, le nombre d'attaques.

Pourquoi plus de vulnérabilités ? Parce que les grands acteurs technologiques, qu'ils soient membres du projet Glasswing ou autorisés à utiliser cette classe de modèles, analysent aujourd'hui leur propre code source pour y débusquer les failles. C'est exactement ce qu'on a observé chez Mozilla : 22 bugs de sécurité et 271 défauts supplémentaires identifiés. Par une seule campagne d'analyse... et beaucoup, beaucoup de tokens. Cloudflare et Daniel Stenberg, le créateur de curl, ont fait des retours d'expérience similaires.

Pourquoi plus d'attaques ? Pas à cause de Mythos directement. Mais chaque fois qu'une vulnérabilité est corrigée, le correctif lui-même peut être rétro-analysé pour retrouver la faille sous-jacente. C'est une vieille technique (le patch diffing), mais l'IA la rend industrielle. Historiquement, environ 28 % des vulnérabilités exploitées le sont dans les 24 heures suivant leur divulgation, une proportion en hausse constante selon les données de VulnCheck (près de 29 % en 2025, contre 23,6 % en 2024). Ce délai de « militarisation » d'une faille fraîchement publiée va encore se réduire.

Ajoutons un angle mort : les mêmes capacités entre les mains d'acteurs étatiques qui, eux, ne communiquent pas sur leur usage. Résultat : un stock croissant de vulnérabilités zero-day. Le risque inhérent de cyberattaque augmente, tout simplement.

En parallèle, si le malware reste un vecteur d'attaque important, il faut s'attendre à une hausse des attaques sur la chaîne d'approvisionnement logicielle, en particulier sur les composants open source. C'est d'ailleurs, aujourd'hui, ce qui est principalement observé sur le terrain.

Deux garde-fous naturels (et une fenêtre de risque)

Faut-il céder à la panique ? Non, pour deux raisons.

D'abord, ces modèles sont non déterministes : deux analyses du même code ne donnent pas nécessairement le même résultat, et leurs conclusions exigent toujours une validation humaine. Ensuite, ils sont très coûteux à faire tourner.

C'est pourquoi je pense que nous entrons dans une fenêtre de risque élevé d'environ 16 mois. Passé ce cap, l'effet devrait s'atténuer : les grands acteurs auront terminé de passer leurs bases de code au peigne fin et chercheront à réduire leurs coûts d'exploitation. Le pic, puis le plateau.

Que faire concrètement ? Trois chantiers

Face à ce constat, voici les trois axes qui me semblent prioritaires, et sur lesquels toute organisation devrait travailler dès maintenant.

1. Repenser la gestion des vulnérabilités et des correctifs

Le modèle classique (scanner, évaluer, assigner, corriger, recommencer) est un processus discret, cadencé, cyclique. Il n'est plus adapté à un monde où une faille peut être exploitée en quelques heures.

Il faut basculer vers une approche continue, où l'évaluation des vulnérabilités prend en compte l'exposition réelle au risque, par exemple via le catalogue KEV de la CISA, plutôt que de s'appuyer uniquement sur un score statique comme le CVSS. À noter aussi, deux outils open source développés au Luxembourg qui vont dans ce sens : Vulnerability-Lookup et MISP. L'objectif : être capable de corriger une vulnérabilité critique à tout moment, pas au prochain cycle de patching.

2. Renforcer la détection et le renseignement sur la menace

La prévention seule ne compensera pas le raccourcissement du délai de militarisation. Il faut donc muscler la détection en parallèle.

Concrètement : surveiller les signaux d'exploitation après les publications majeures des éditeurs (activité de patch diffing, publication de preuves de concept, ajouts au catalogue KEV), pour pouvoir déclencher une remédiation d'urgence avant l'exploitation de masse. Et revoir ses cas d'usage SIEM pour couvrir les comportements post-exploitation, en partant du principe, réaliste, que certaines failles seront exploitées avant qu'un correctif ne puisse être déployé.

3. Se préparer au SBOM

Contre les attaques sur la chaîne d'approvisionnement, l'un des meilleurs outils d'anticipation et de remédiation reste le SBOM (Software Bill of Materials) : l'inventaire détaillé des composants logiciels qui composent vos applications.

Mais un SBOM ne se décrète pas. Le prérequis, c'est une gestion du cycle de vie des actifs solide, avec une définition claire des actifs immatériels (les composants logiciels en font partie). Une fois en place, le SBOM devient aussi un outil de détection : il permet d'identifier immédiatement si un composant open source compromis est présent quelque part dans votre parc.

En résumé

L'IA ne change pas la nature du jeu, elle en change la vitesse et exige de nous une rapidité de réponse inédite. Pour reprendre les mots de Maxime Verac (Deloitte Luxembourg) dans son article sur la gestion des vulnérabilités à l'ère de l'IA : « la gestion des vulnérabilités devient une discipline du risque opérationnel, et non plus un simple exercice d'énumération technique » (traduction libre).

Et vous, votre processus de patching est-il prêt à passer du cycle mensuel au temps réel ?

Références