Mythos (Anthropic) : que penser de l’avis du CSA ?

« Le tooling sans la gouvernance, c’est de la sécurité théâtrale. »

Executive Summary :

Le Cloud Security Alliance (CSA) vient de publier un document de référence sur les implications de Claude Mythos pour les équipes de sécurité. Le rapport est sérieux, bien construit, et porté par des signatures de premier plan.

Il pose les bons problèmes :

• Asymétrie attaquant/défenseur ;
• Submersion par le volume de vulnérabilités ;
• Obsolescence des modèles de risque.

Il propose aussi un cadre opérationnel utile, notamment le concept de VulnOps.

Mais il reste prisonnier d’une vision techno-centrée qui sous-estime les enjeux métier, la dynamique de l’attaquant rationnel, et le paradoxe stratégique que crée la supply chain.

Rappel : pourquoi Mythos change quelque chose

Mythos[1] n’est pas un scanner de vulnérabilités amélioré. C’est un changement de régime. Là où les outils classiques appliquent des règles et des signatures, Mythos comprend l’intention du code, chaîne des primitives de corruption mémoire en exploits fonctionnels, et opère de façon également compétente sur tous les langages et frameworks, sans intervention humaine.

Le temps entre découverte et weaponisation s’est effondré à quelques heures[2]. L’asymétrie n’est plus conjoncturelle : elle est structurelle.

C’est dans ce contexte que le CSA a publié son Expedited Strategy Briefing « Mythos-ready »[3].

Ce que le CSA dit vraiment, et dit bien

Le rapport pose un diagnostic central que je partage entièrement : les organisations seront submergées par le volume.

Pas par une attaque frontale spectaculaire, mais par l’incapacité à absorber le flux continu de vulnérabilités découvertes, de patchs à déployer, d’incidents à traiter simultanément. C’est ce que j’appelle le « débordement initial »[4], le CSA le formule différemment mais l’idée est juste.

Le rapport identifie également avec clarté l’obsolescence des modèles de risque actuels : les métriques sont calibrées pour un monde où le time-to-exploit se comptait en semaines, les SOC pour un volume d’alertes humainement gérable, et les cycles de patching pour quelques CVE critiques par mois.

Rien de tout cela ne tient plus face à Mythos.

La réponse proposée s’articule autour de cinq axes :

• Accélérer par l’IA défensive (agents, automatisation) ;
• Revenir aux fondamentaux (segmentation, MFA, egress filtering) ;
• Sécuriser la supply chain ;
• Créer une fonction VulnOps ;
• Réformer la gouvernance.

Sur chacun de ces axes, le contenu est solide et opérationnel, le tableau « Priority Actions » avec des horizons « this week / 45 days / 90 days » est particulièrement utile pour préparer une présentation COMEX.

Le concept de VulnOps mérite une attention particulière.

C’est l’innovation conceptuelle la plus structurante du document : créer une fonction permanente de découverte continue et de remédiation automatisée des vulnérabilités, calquée sur le modèle DevOps.

L’idée est juste et je l’intègre dans mon propre cadre, même si elle soulève immédiatement la question de la gouvernance de triage, que le CSA effleure sans vraiment la résoudre.

Les limites réelles du document

Première limite : une vision trop patch-centric.

Le CSA raisonne encore largement en termes de vuln → patch → mitigation. C’est cohérent avec leur audience (CISO d’infrastructure), mais c’est insuffisant dans un monde où le patch arrive structurellement trop tard.

La priorité devrait être de détecter l’exploitation après qu’elle a commencé, pas seulement de réduire la surface avant. La détection comportementale, la corrélation technique et métier, la gestion de la suspicion, la fingerprinting applicatif sont mentionnés en passant mais jamais érigés en axe défensif de premier rang[5].

Deuxième limite : l’absence quasi-totale du métier.

Le CSA reste dans le registre technique : infrastructure, vulnérabilités, pipelines. La fraude financière[6], la manipulation de logique métier, le détournement de payout, tout ce qui constitue la cible réelle d’un attaquant rationnel sur une entreprise est absent. Or un attaquant qui utilise Mythos n’optimise pas pour la présence technique : il optimise pour le gain. Le pivot métier est le cœur du scénario d’attaque, pas son épilogue[7].

Troisième limite : le paradoxe patch/supply chain n’est pas résolu.

Le CSA le mentionne, d’ailleurs à juste titre, l’attaque npm citée en référence[8] montre bien que la propagation d’un patch malveillant est un vecteur réel.

Mais ils ne résolvent pas la friction stratégique : comment patcher plus vite et accepter les patchs plus lentement ? Ce paradoxe mérite une réponse explicite (délai de validation, environnement de staging dédié, gel sélectif), pas juste une note de bas de page.

Quatrième limite : les attaques « low and slow » sont sous-traitées.

Le rapport insiste sur le volume et la vitesse, ce qui est juste. Mais il passe trop rapidement sur la catégorie d’attaques la plus dangereuse pour une entreprise : les attaques basse intensité, délibérément lentes, comportementalement normalisées, calibrées pour rester sous les seuils de détection.

C’est précisément là que la corrélation technique/métier devient non pas un atout mais une nécessité absolue, et c’est précisément là que le CSA est le plus silencieux.

Cinquième limite : le risque d’illusion de maîtrise par le tooling.

Le CSA pousse fortement vers les agents, l’automatisation, les outils. C’est juste.

Mais il sous-estime le risque inverse : croire qu’on est protégé parce qu’on a déployé des agents de détection.

La baseline comportementale prend du temps à construire, peut être apprise par l’adversaire, et ne doit jamais être le seul vecteur de défense[9]. La gouvernance de crise, qui décide quoi, avec quelle autorité, à 2h du matin, est plus déterminante que le nombre d’agents déployés.

Ce que le CSA apporte qui est fondamental et à mettre en place

Trois points méritent d’être intégrés sans réserve.

Premier apport : le risque RH et le burnout

Ces points sont traités avec une honnêteté rare dans ce type de document. La pression sur les équipes de sécurité est réelle, préexistante à Mythos, et va s’intensifier. Ignorer cette dimension dans la planification capacitaire, c’est créer un risque opérationnel direct.

Deuxième apport : la défense collective,

ISACs, CERTs, coordination sectorielle, est particulièrement pertinente dans un contexte réglementaire européen (DORA, NIS2, Recyf[10]) qui pousse précisément dans cette direction. Les attaquants opèrent déjà en syndicats. Les défenseurs doivent en faire autant.

Troisième apport : l’urgence opérationnelle

La présentation du tableau d’actions (« this week », « 45 days ») est un outil de communication COMEX que tout RSSI/CISO devrait exploiter. La traduction du risque technique en plan d’action daté est ce qui fait bouger les budgets.

Conclusion

Le document CSA est une lecture obligatoire pour tout CISO ou responsable produit qui doit briefer sa direction sur Mythos. Il pose le bon cadre, propose des actions concrètes, et introduit le concept de VulnOps qui structurera probablement les organigrammes sécurité dans les 18 prochains mois.

Mais il reste une réponse d’infrastructure à une menace qui est, en profondeur, une menace métier.

Mythos ne change pas la nature des risques, il change leur vitesse et leur échelle. Ce qui était gérable avec du temps devient ingérable sans automatisation défensive et sans gouvernance de crise.

Le tooling sans la gouvernance, c’est de la sécurité théâtrale.

---

[1] Anthropic, Claude Mythos Preview & Project Glasswing, avril 2026 : https://red.anthropic.com/2026/mythos-preview/

[2] Sergej Epp, Zero Day Clock, mars 2026 : https://zerodayclock.com, le temps moyen d’exploitation est passé à moins de 24h en 2026.

[3] CSA CISO Community, SANS, OWASP Gen AI Security Project, The « AI Vulnerability Storm »: Building a « Mythos-ready » Security Program, v0.9, 14 avril 2026 : https://labs.cloudsecurityalliance.org/wp-content/uploads/2026/04/mythosreadyv9.pdf

[4] Voir mon article précédent : Mythos, un game-changer pour les éditeurs de logiciels : https://radical-ssi.fr/mythos-un-game-changer-pour-les-editeurs-de-logiciels/

[5] Sur la détection comportementale et la gestion de la suspicion, voir également la conférence de Vincent Strubel à l’IFRI, 26 mars 2026 : https://radical-ssi.fr/conference-de-vincent-strubel-dg-anssi-la-france-face-aux-nouveaux-defis-de-la-cybersecurite-26-mars-2026/

[6] Bien souvent quand même la finalité souhaitée n°1, même si je sous-estime pas les attaques APT.

[7] La notion d’attaquant rationnel optimisant pour le gain métier plutôt que pour la présence technique est développée dans mon scénario d’attaque fintech en 6 phases, op. cit.

[8] GitLab, Widespread npm Supply Chain Attack, 2025 : https://about.gitlab.com/blog/gitlab-discovers-widespread-npm-supply-chain-attack

[9] Sur les limites de la baseline comportementale face aux attaques IA-driven, voir : Nicholas Carlini, Anthropic, https://nicholas.carlini.com/

[10] ANSSI, Recyf, Référentiel d’exigences : https://lab.cyber.gouv.fr/les-actualit%C3%A9s-du-lab-anssi/recyf–publication-du-r%C3%A9f%C3%A9rentiel-dexigences-et-du-comparateur/ , et ENISA, Good Practices for Supply Chain Cybersecurity : https://www.enisa.europa.eu/publications/good-practices-for-supply-chain-cybersecurity