5 mythes de la sécurité que Mythos a balayés (racontés par un CISO)

On ne parle que de Mythos

Mythos prétend accélérer la découverte de vulnérabilités à un rythme tel qu'il rend obsolètes, du jour au lendemain, plusieurs principes fondamentaux de la sécurité. Mais la découverte de vulnérabilités par l'IA dépasse le cadre d'un simple modèle ou d'un nom accrocheur. Dans les mois à venir, l'IA va bouleverser radicalement certaines croyances et pratiques bien ancrées dans notre profession.

Je réfléchis aux modèles mentaux sur lesquels les équipes de sécurité se sont historiquement appuyées : les hypothèses ancrées dans nos processus, nos choix d'outils, notre approche philosophique de l'acceptation du risque. La plupart d'entre elles étaient tout à fait raisonnables lorsque les humains étaient limités par la vitesse humaine. L'avenir est tout autre.

Voici cinq hypothèses que je vous invite à abandonner.

Mythe 1 : Vous avez le temps de corriger une vulnérabilité après sa divulgation

La logique d'antan : une nouvelle vulnérabilité (CVE) est publiée, et vous disposez de quelques jours, voire de semaines, pour en évaluer la gravité, tester un correctif et le déployer avant que les attaques ne commencent dans la nature. Cette fenêtre de tir a toujours ressemblé à une course contre la montre. Des modèles tels que Mythos réduisent ce délai à néant.

Les chiffres sont désormais officiels. Selon le Zero Day Clock, un ensemble de 3 529 paires de CVE et d'exploits tiré des bases CISA KEV, VulnCheck KEV et XDB, le délai moyen d'exploitation est passé de 2,3 ans en 2018 à environ 20 heures en 2026. Ce chiffre a été cité dans un briefing conjoint de la communauté CSA CISO, de SANS et du projet OWASP GenAI Security. La propre équipe Frontier Red Team d'Anthropic a documenté que Mythos Preview peut prendre un identifiant CVE et un hachage de commit git pour produire un exploit fonctionnel en moins d'un jour pour moins de 2 000 dollars. Une reproduction indépendante de l'exploit FreeBSD NFS (CVE-2026-4747) a pris environ quatre heures.

Le modèle de détection et de correction repose sur l'existence d'un décalage entre la divulgation et l'armement de l'exploit. Ce décalage se compte désormais en heures. Si votre posture de sécurité consiste à réagir avant que les attaquants n'agissent, vous pariez sur une fenêtre qui n'existe plus de manière fiable. La solution ne réside pas dans des corrections plus rapides. L'élimination proactive garantit que la vulnérabilité n'atteint jamais la production.

Mythe 2 : Les failles zero-day sont trop rares pour qu'on s'en préoccupe

Les failles zero-day coûtaient autrefois relativement cher. Elles exigeaient des compétences et des connaissances poussées pour être découvertes, ce qui en faisait historiquement l'apanage d'acteurs malveillants dotés de ressources importantes : services de renseignement étatiques, officines de mercenaires informatiques et groupes criminels d'élite. La rareté des failles zero-day constituait en soi une forme de défense pour la plupart des organisations.

Des modèles comme Mythos bouleversent cette économie. L'équipe Frontier Red Team d'Anthropic a documenté le fait que Mythos Preview a identifié des milliers de failles zero-day jusqu'alors inconnues dans tous les principaux systèmes d'exploitation et navigateurs, y compris des failles qui avaient survécu à des décennies de révision humaine et à des millions de tests automatisés. Une campagne de découverte ciblant OpenBSD a coûté environ 20 000 dollars pour près de 1 000 exécutions de scripts. Selon la description d'Anthropic : le coût, l'effort et le niveau d'expertise requis pour trouver et exploiter des vulnérabilités logicielles ont tous chuté de manière spectaculaire. L'entreprise estime également que des capacités comparables se généraliseront dans d'autres laboratoires d'IA d'ici six à dix-huit mois. Et inévitablement, les capacités des modèles open source suivront.

Le modèle de menace qui supposait que les failles zero-day étaient réservées aux États et aux groupes criminels d'élite doit être revu dès maintenant, et non dans 18 mois. Votre surface d'attaque inclut toutes les dépendances open source que vous utilisez. Si ces dépendances contiennent des vulnérabilités latentes, les outils assistés par IA peuvent les trouver plus rapidement que n'importe quelle équipe d'attaque (red team) humaine.

Mythe 3 : Vous pouvez continuer à accepter sans conséquence le risque de milliers de vulnérabilités moyennes et faibles en production

Maintes et maintes fois, j'ai écouté des CISO chargés de protéger des environnements sensibles truffés de vulnérabilités ouvertes se livrer à des acrobaties mentales pour justifier leur situation : « L'entreprise accepte le risque, je ne fais qu'animer la prise de décision » ou « Je ne suis qu'un conseiller en risques pour l'entreprise ». Abstraction faite du fait que je doute de la sécurité de l'emploi pour le simple rôle de « conseiller en risques » de nos jours, décider d'exploiter des environnements sensibles comportant des milliers de vulnérabilités ouvertes dans le monde de Mythos ne relève pas de « l'acceptation du risque », mais de la négligence.

Je comprends. Dans l'ancien monde, il fallait un grand talent à un attaquant pour enchaîner plusieurs vulnérabilités de faible gravité afin de concevoir un parcours d'attaque efficace pour atteindre sa cible. Mais aujourd'hui, même des apprentis hackers peuvent demander à des outils de test d'intrusion autonomes de combiner des exploits pour de multiples vulnérabilités moins graves afin de créer des chemins d'attaque redoutables. Et choisir d'engager sa responsabilité sur des environnements autorisés à fonctionner de la sorte n'est plus acceptable pour aucun CISO aujourd'hui.

Mythe 4 : La sécurité de vos dépendances open source est le problème de quelqu'un d'autre

"Nous allons puiser à la source, lancer un scanner et bloquer les CVE critiques." Cette posture était défendable lorsque la menace se limitait à des logiciels malveillants connus et à des vulnérabilités divulguées. Ce n'est plus suffisant aujourd'hui.

Deux problèmes s'ajoutent ici. Les scanners sont réactifs : ils détectent ce qui est déjà connu. Et les registres amont qui alimentent vos dépendances ne disposent d'aucune vérification d'intégrité intégrée. En février 2026, plus de 300 compétences malveillantes ont été identifiées dans ClawHub, le registre communautaire d'OpenClaw, incitant les agents IA à installer des logiciels malveillants de vol d'identifiants.

Au moment où la détection se déclenche, l'artéfact est déjà présent dans votre environnement. La seule solution pérenne consiste à s'assurer que ce que vous téléchargez a été construit à partir de sources vérifiées, et non d'un binaire auquel vous faites aveuglément confiance.

Chainguard Containers et Chainguard Libraries éliminent complètement ce pari. Chaque artéfact est reconstruit à partir du code source dans un environnement isolé, de sorte que les binaires malveillants absents du code source ne peuvent pas apparaître dans la version finale. Il s'agit d'une exclusion architecturale de la malveillance.

Mythe 5 : La conformité est un substitut à la posture de sécurité

Celui-ci me vaudra peut-être encore moins d'amis que le mythe 3. Beaucoup d'entre nous le savent pertinemment, mais de nombreux programmes de sécurité (et directions informatiques) confondent encore conformité et réduction réelle des risques. Réussir un audit Federal Risk and Authorization Management Program (FedRAMP), maintenir une certification SOC 2 ou cocher les cases pour la génération d'une nomenclature logicielle (SBOM) permet d'afficher une posture documentée sur le papier. Pour autant, la documentation ne signifie pas que les vulnérabilités ont disparu.

Mythos rend ce décalage dangereux. Un système d'IA capable de découvrir rapidement des vulnérabilités exploitables se moque de savoir si vous avez passé votre dernier audit. Ce qui l'intéresse, c'est de savoir si la vulnérabilité est présente. Vous vous souvenez de cette fois où votre revue trimestrielle des accès a permis de parer à une menace imminente ? Moi non plus, d'ailleurs, car cela ne s'est jamais produit. Ces cadres de contrôle semblent tout droit sortis des manuels d'instruction de la série Severance.

Les cadres de conformité n'ont pas été conçus pour faire face à des adversaires agissant à cette vitesse. La plupart ne sont d'ailleurs pas vraiment conçus pour lutter contre les cybermenaces modernes. Le référentiel SOC 2 a initialement été développé comme une norme comptable. Mon avis ? À l'avenir, les équipes qui s'en sortiront le mieux seront celles qui s'attacheront réellement à bâtir des programmes et des contrôles de sécurité efficaces, plutôt que de se contenter d'un certificat à brandir.

Le fil conducteur

Chacun de ces mythes partage un mode de défaillance commun : ils supposent un adversaire humain opérant à une vitesse humaine, avec des contraintes de ressources humaines. Des modèles comme Mythos réduisent cette hypothèse à néant à tous les niveaux.

L'architecture qui survivra à cette transformation est celle où la sécurité est intégrée à vos systèmes et processus avant même que le code n'entre dans votre environnement, et non simplement greffée par la suite. Cela implique de concevoir des applications dotées de composants intrinsèquement sûrs, construits à partir de sources vérifiées, analysés à la recherche de logiciels malveillants ou indésirables, et renforcés contre les techniques des attaquants. Il s'agit d'éliminer les vulnérabilités plutôt que de les suivre, et d'appliquer la même rigueur à chaque type d'artéfact dont dépendent vos ingénieurs et vos agents. L'ère du « livrer et corriger » est révolue. Concevoir les choses correctement dès le départ est la seule option qu'il nous reste.

En savoir plus sur la façon dont Chainguard vous aide à vous protéger contre les menaces liées à l'IA.