Le mythe est réel. L'environnement de production n'est pas un code.

TL;DR: Mythos est une véritable avancée dans la recherche de bugs dans le code, mais le code n’est pas le problème de production.
L'exploitation précède désormais systématiquement le correctif, ce qui signifie que ce qui compte, c'est ce qu'un
une charge de travail compromise est autorisée une fois que quelqu'un est à l'intérieur. C'est une couche différente de
celui sur lequel Mythos opère, et il a besoin d'une application d'exécution et d'un contexte opérationnel, pas d'un
chercheur plus rapide.

L'aperçu du projet Glasswing d'Anthropic a déjà fait apparaître des milliers de vulnérabilités graves
sur les principaux systèmes d'exploitation et navigateurs, y compris les failles qui sont restées indétectables pendant 17 à 27
années. Microsoft et AWS intègrent Mythos dans leurs flux de travail de sécurité logicielle. C'est
une véritable avancée, et elle doit être prise au sérieux.

Il convient d’être précis sur ce que fait et ne fait pas le Mythe. Ce qu'il fait, c'est trouver des bugs
code avant que le code ne soit expédié. Ce qu'il ne fait pas, c'est protéger un environnement une fois qu'un bug a été détecté
exploité. Ce n’est pas un coup porté à l’outil. C'est une description de l'espace problématique. Mythe
fonctionne sur le code source. Sa compétence prend fin lorsque le logiciel atteint la production.

Si l'exploitation précède régulièrement la remédiation, la
période pendant laquelle la protection à l'exécution est la seule chose qui se dresse entre un attaquant et vos
données est exactement la période que Mythos ne couvre pas.

Golan Ben-Oni, DSI chez IDT, mettez-le proprement dans un article récent: “Assez rapide, la détection est une prévention.
Trop lent, la détection est une autopsie.” Son argument le plus important est que l’industrie a construit une décennie de
architecture de sécurité autour des vitesses et des modèles de confiance que l'attaquant ne respecte plus. Tu ne le fais pas
il faut être d'accord avec chaque ligne de cette pièce pour remarquer le point sous-jacent. Un smash-and- moderne
la saisie se ferme en quelques secondes. Si votre boucle défensive se déroule en quelques minutes, vous rédigez un rapport médico-légal
produit, pas un produit de sécurité.
Le problème de production n'est pas “pouvons-nous trouver le bug.” C'est “que peut faire cette charge de travail si quelqu'un
est à l'intérieur de toute façon.”

Récolte d'identifiants. Coquilles inversées. Escalade des privilèges. Mouvement latéral. Ce ne sont pas
défauts de code. Ce sont des comportements d’exécution. Aucun scanner, aussi performant soit-il, ne les attrape, car
le code n'a jamais été le problème. Le problème est ce que le processus compromis essaie de faire
une fois qu'il fonctionne et si l'environnement le permet.

Trois points de données qui méritent d’être réunis.
Premièrement, les attaquants ne pensent pas dans les CVE. Ils pensent en chemins, enchaînant les faiblesses jusqu'à ce qu'elles atteignent
quelque chose de précieux. Un seul composant non corrigé est rarement le problème. Le fait est qu'un
composant et une identité et un flux réseau, combinés, permettent à un attaquant d'aller quelque part où il
n'étaient pas censés le faire. Une découverte plus rapide des bugs ne réduit pas le nombre de chemins. Il élargit le
carte.

Ce modèle n’est pas nouveau. Il y a des années, chez RedSeal, j'ai conçu le produit autour du chemin d'attaque
analyse, graphiques montrant comment un attaquant pourrait enchaîner des erreurs de configuration sur un segment
réseau pour atteindre leur cible. Mon hypothèse à l’époque était que les chemins utiles seraient au nombre de cinq à
dix sauts de long. En pratique, la plupart des réseaux se sont effondrés en deux. Une fois un attaquant
après quelques pivots, tous les actifs atteignables étaient atteignables. Le meilleur scanner de points du
le monde pourrait signaler un problème dans un pare-feu. Uniquement un outil combinant des données de vulnérabilité avec des données réelles
La configuration du réseau pourrait vous indiquer si ce problème est important dans son contexte. L'ère du Mythe
reproduit ce modèle à l’échelle du nuage. Des chercheurs plus rapides et meilleurs. Même couche manquante.

Deuxièmement, vulnérable n’est pas la même chose qu’exploitable. Certains CVE critiques ne peuvent pas être atteints dans un
environnement spécifique. Certains problèmes de faible gravité deviennent à fort impact lorsqu’ils sont combinés avec
autres. Un modèle peut évaluer brillamment la gravité technique. Il ne peut pas vous dire quelle charge de travail
gère les informations personnelles identifiables, quel service est connecté à Internet ou quel conteneur fonctionne avec plus de privilèges
que ce dont il a besoin. Ce contexte vit dans l’environnement et doit y être appliqué.

Troisièmement, l’IA offensive s’accélère également. Le rapport sur les menaces mondiales 2026 de CrowdStrike a suivi un taux de 89 %
augmentation d’une année sur l’autre des attaques assistées par l’IA. L'avantage de l'attaquant n'est pas que quelqu'un
l'adversaire est plus intelligent. C'est que des attaquants moyennement compétents, dotés d'un effet de levier d'IA, peuvent opérer
efficacement à grande échelle sur des milliers de cibles. La réponse à l’automatisation en attaque ne peut pas être
un humain dans une file d'attente pour les billets en défense.

Deux choses suivent. Il ne s’agit pas non plus d’un produit spécifique.

1. Le premier est l'application à l'exécution. Cela signifie la couche la plus proche de l'endroit où l'attaquant est réellement
en opération : le noyau, la limite des appels système, la connexion sortante, l'arborescence des processus.
L'application signifie le blocage, pas l'alerte. L'alerte dépend du nombre d'employés. Le blocage dépend de la
politique. Dans un monde où l'on suppose la compromission, seule l'une de ces options suit le rythme.

2. Le deuxième est le contexte opérationnel. Savoir quelle charge de travail gère les données sensibles. Lequel
le service est orienté vers Internet. Quel conteneur fonctionne avec plus de privilèges qu’il ne le devrait. Comment
ces faits sont liés les uns aux autres. Une découverte sans ce contexte est un ticket dans une file d’attente. Une découverte
ancrée dans ce contexte se trouve une décision de risque.

Aucun de ces deux éléments n’est le travail de Mythos, et c’est là le problème. Mythos trouve des bugs dans le code. Le post-
question de déploiement, ce qu'un attaquant qui a déjà dépassé le code peut et ne peut pas faire, est une
couche différente et un problème différent.

KubeArmor, un moteur de politique open source au niveau du noyau pour les conteneurs, Kubernetes, les machines virtuelles et
sans serveur, c'est un moyen de fournir la moitié de l'application. C'est la base sur laquelle AccuKnox est construit.
Ce n’est pas la seule option dans l’espace. La propriété essentielle est l'application au niveau de la couche
l'attaquant touche réellement, lié au contexte de l'environnement dans lequel vit la charge de travail. C'est le
forme de la couche manquante, quel que soit le fournisseur.

Le mythe et l’application du temps d’exécution ne sont pas en concurrence. Ils opèrent sur différentes couches du
même problème. On trouve des bugs dans le code avant sa livraison. L'autre décide de ce qu'est une charge de travail
autorisé à le faire si quelque chose entre après l'avoir fait. Si Mythos aide les équipes à trouver plus de vulnérabilités
plus tôt, c'est une victoire. Cela rend également les garde-fous d'exécution plus importants, et non moins importants, car
la fenêtre d'exploitation devient plus courte et la boîte à outils de l'attaquant devient plus nette sur la même courbe.
Heureux de découvrir à quoi cela ressemble dans votre environnement.