Executive Summary

L’émergence de LLM de type Mythos marque une rupture dans le paysage des menaces cyber. Non pas parce que les vulnérabilités sont nouvelles, mais parce que, comme pour l’IA Agentique, leur découverte et leur exploitation deviennent industrielles, automatiques et orientées métier, à un coût marginal pour l’attaquant.

Pour la plupart, le risque principal n’est pas une attaque frontale sur le code propriétaire. C’est la compromission indirecte via la supply chain open source : des dépendances tierces, souvent transitives, que Mythos peut scanner, cibler et exploiter sans jamais toucher directement notre infrastructure. Un code fermé n’est plus protégé par son opacité dès lors qu’il repose sur des librairies publiques. Un scénario d’attaque plausible est donné en 6 phases.

Face à cette menace, trois priorités s’imposent parallèlement :

• La première est la réduction de surface : SBOM dynamique, limitation des dépendances, audit de la verbosité des API et transformation du CI/CD en CI/CV/CD. L’objectif n’est pas l’inviolabilité – c’est de rendre l’attaque plus coûteuse[1].
• La deuxième est la détection comportementale : établir tant que possible des corrélations techniques et métiers via des dispositifs permettant d’enregistre les notions de suspicion (qui pourront être explorées et corrélées a posteriori), logs enrichis tant WAF qu’applicatifs. Un SIEM classique est aveugle aux attaques IA-driven basse intensité. Seule la corrélation avec les événements métier permet la détection – avec la limite que cela exige une baseline fiable et ne doit pas être le seul vecteur de défense.
• La troisième est la gouvernance de crise : pré-autoriser les quatre décisions critiques -coupure d’endpoint, gel des dépendances, containment métier, notification aux régulateurs – avec un RACI nominatif et des seuils de déclenchement définis avant l’incident. Dans un régime d’exploitation IA-driven, chaque heure de délai décisionnel est une heure d’exploitation supplémentaire.

La conclusion est simple : Mythos ne change pas la nature de nos risques. Il change leur vitesse et leur échelle. Notre réponse doit faire de même.

Problématique

Nicholas Carlini[2] d’Anthropic résume bien l’enjeu[3] : l’équilibre entre attaquants et défenseurs qui tenait depuis 20 ans est en train de basculer. Les LLM abaissent drastiquement le niveau technique, le temps et le coût nécessaires pour trouver des failles, ce qui représente une menace existentielle pour les petites structures et les projets open source.

Il faut avant tout retenir deux points fondamentaux :

• Les capacités de Mythos en production réelle restent partiellement inconnues. Les annonces d’Anthropic portent sur des exemples et des conditions contrôlées avec des partenaires sélectionnés ;
• La détection comportementale par les défenseurs peut également bénéficier des capacités de Mythos, ce qui signifie que l’avantage offensif n’est pas permanent : il dépend de qui déploie le plus vite.

Assomptions décrivant les capacités Mythos retenues ci-après :  

On parle d’hypothétique. Quand même, 3 assomptions fortes :

• Compréhension sémantique du code à grande échelle : un scanner classique applique des règles et des signatures. Mythos est censé comprendre l’intention du code, détecter des interactions non triviales entre composants, et identifier des vulnérabilités qui n’ont aucune signature connue. C’est ce qui explique la faille Linux vieille de 27 ans trouvée [4]: elle n’était pas détectable par pattern matching ;
• Adaptation en boucle fermée : un exploit classique est statique, mais Mythos est décrit comme observant les réponses du système cible, inférant son comportement interne, et pouvant adapter le vecteur d’attaque en temps réel sans intervention humaine ;
• Généralisation cross-stack : un attaquant humain expert est spécialisé. Mythos tel que décrit opère de façon également compétente sur une multitude de langages, sur n’importe quel framework applicatif, et peut appliquer ses résultats sur des milliers de cibles.

Au niveau risque

Présentation générale :

Mythos (et consorts qui ne manqueront pas d’arriver à court terme) ne menacent pas seulement les systèmes exposés (sauf dans le cas de systèmes open source, mais leurs vulnérabilités sont les mêmes que celles des librairies, même si l’impact devient métier), mais surtout les dépendances invisibles, donc la supply chain logicielle. Car un projet propriétaire n’est plus protégé par son opacité, sa gestion rigoureuse des secrets dès lors qu’il dépend d’open source.

La cybersécurité entre dans une phase d’industrialisation par l’IA, où la vitesse de découverte des failles dépasse la capacité des organisations à les corriger. Avec l’IA, nos vulnérabilités ne sont plus découvertes une par une : elles sont industrialisées via notre supply chain, notre CI/CD, même lorsque notre code est fermé.

En pratique, même un code propriétaire est partiellement exposé via ses dépendances.

Dans un environnement impacté par Mythos, et en tout cas dans une phase initiale, les vulnérabilités seront exploitées plus vite qu’elles ne sont corrigées, permettant des attaques plus nombreuses, plus discrètes et surtout orientées métier (fraude, détournement).

Cela converge avec les attaques IA précédemment décrites : Mythos ne sera alors qu’une brique technique qui alimentera ces attaques, mais une brique particulièrement efficace.

Finalement, l’expression du vrai risque principal pour un éditeur n’est pas la découverte de failles internes mais l’incapacité à absorber et corriger suffisamment vite l’impact des failles découvertes dans l’environnement. Et sur ce plan il existe un vrai risque d’industrialisation des failles de type 0-day, ou en tout cas un submergement initial

Spécificités supply chain :

La supply chain devient un point d’entrée privilégié, même pour du code fermé. Mythos pourra certainement :

• Inférer avec la stack technique ;
• Tester des vecteurs connus ;
• Adapter les « exploit » automatiquement.

Le délai de patch devient la variable critique. Mais en même temps l’attaque NPM[5] nous apprend que le délai d’acceptation des patchs doit être ralenti pour éviter la propagation. Nous sommes donc là dans un schéma de friction, avec une incohérence !

A noter : le risque ne se limite pas aux librairies open source directes, il descend jusqu’aux dépendances transitives de niveau 3 ou 4, souvent maintenues par une poignée de bénévoles sans moyens de sécurité (plusieurs exemples récents).

CI/CD !!!

Probablement l’axe le plus dangereux à moyen terme : la supply chain CI/CD est déjà un point faible structurel (et ce par principe ; Mythos agit ici comme un multiplicateur d’accès et de précision). Pourquoi ? Parce que le CI/CD devient une cible prioritaire en permettant une compromission « propre », persistante et quasi indétectable à grande échelle (pour lutter, il faut plutôt se place dans une démarche d’artisan amoureux, éloignée de la « grande échelle » !!!).

On en revient au point 3 des capacités supposées de Mythos (et futurs consorts, je le rappelle), la généralisation cross-stack des capacités de traitement. Pour un humain, les pipeline YAML ou les scripts restent lisibles mais complexes.

Se pose alors la question du comment, et on en revient aux bonnes vieilles méthodes prophylactiques : gestion radicale des secrets, rotation des mots de passe, connaissance des compte SaaS. Mais on n’évite pas avec ces méthodes la dépendance CI compromise ou la compromission d’une dépendance build-time (lib utilisée uniquement au build, voir l’attaque npm pré-citée). En gros, l’IA ne crée pas le point d’entrée, mais rend chaque point d’entrée beaucoup plus exploitable, pour chacun des trois « acteurs » cibles que sont les humains, les dépendances ou la configuration.

Au niveau protection

Le bon vieux plan de sécurisation

L’idée est de voir l’attaque, même si la faille est inconnue. On en revient à la nécessité d’une posture organisationnelle :

• Fingerprinting des interactions utilisateur-application et corrélation métier : indispensable pour récupérer les infos permettant de détecter les exploitations post-vulnérabilité ; l’idée n’est pas d’assurer une inviolabilité mais de parer les tentatives ;
• La gestion de la suspicion est parfaite pour gérer les signaux faibles issus d’exploitation, qui pourront être exploités et corrélés par IA ; attention, il faut établir une baseline comportementale fiable, qui n’est pas simple à générer du jour au lendemain… le système était plutôt vu comme une protection raisonnable contre les attaques « low and slow », plutôt qu’un risque potentiellement submergeant ;
• Logs enrichis (WAF + applicatif) en lien avec le fingerprinting : critique pour voir et exploiter les attaques IA-driven.

A noter que la gestion de la suspicion, une fois la baseline établie, nécessite de définir ensuite les process de traitement. Plus, dans un contexte d’attaque IA-driven, l’adversaire peut apprendre la baseline et rester intentionnellement en dessous. Ce n’est pas une raison de ne pas le faire, c’est une raison de ne pas s’y fier seul, et que c’est un vecteur de sécurité plus qu’un outil pur et dur.

Sécuriser la supply chain et le CI/CD

Concernant la supply-chain, la sécurité ne dépend plus uniquement du code, mais de la qualité globale de l’écosystème dont dépend le produit. Il est donc nécessaire de prioriser la capacité de réponse et de tenter d’offrir une surface réduite plutôt que de vivre dans l’illusion d’une prévention totale. Certes. Mais en pratique ?

Quelques remarques de bon sens :

• Moins de dépendances = moins de vulnérabilités exploitables ;
• Ne jamais exécuter du code non maîtrisé (éviter la dernière lib à la mode…).

On en arrive à quelques idées phare :

• Un SBOM[6] (rafraichi en permanence) devient obligatoire (et c’est aligné avec DORA, probablement NIS2 et Recyf[7]), avec un inventaire des dépendances effectivement chargées en runtime. Techniquement, ça ne protège pas immédiatement, mais ça permet de comprendre une éventuelle compromission. Pour que cela protège, il faut analyser l’inventaire avant chargement des dépendances, puis se demander quel est le SLA de réaction quand une dépendance du SBOM est flaggée critique…
• Un Patch management orienté risque gérant tous les composants exposés (API, identités, etc.) et toutes les librairies pour réduire la fenêtre d’exploitation. Le « tous » est crucial : la mise en place du monitoring des dépendances exposées implique l’analyse des librairies réellement utilisées en runtime, pas seulement déclarées.
• Une limitation des dépendances (éviter les dépendances peu maintenues ? intelligent mais où trouver cette info ?) mais aussi de la surface (la réduction des API et de leur verbosité est souvent une piste).

Finalement, transformer le CI/CD en CI/CV (continuous validation)/CD…

Gérer le temps

On est là face à une problématique classique : qui décide du patch en urgence à 2h du matin ou le 31 décembre à minuit ? Quel est le circuit d’escalade ? Qui a l’autorité pour couper un endpoint en production si une exploitation est détectée ?

Ce sont des questions de gouvernance que Mythos rend urgentes, et qui vont au-delà des mécanismes d’astreinte souvent en place. Dans un régime Mythos, la vitesse de réponse est une variable déterminante. Or la vitesse de réponse ne dépend pas d’abord des outils, elle dépend de la capacité à prendre des décisions sans délai, sous incertitude, y compris la nuit et le week-end.

Il me semble nécessaire d’expliciter des décisions pré-autorisées :

• Mécanisme simple de coupure d’un endpoint en production ou au moins de décision de containment métier (ce peut être insuffisant pour certaines attaques, cela dépend bien évidemment du produit) ;
• Gel des dépendances en production ;
• Communication réglementaire d’urgence.

Dans un régime d’exploitation IA-driven, chaque heure de délai est une heure d’exploitation supplémentaire. Dans ce cadre encore plus, il convient d’expliciter la gouvernance de crise : non dans un but simple de conformité, mais dans un but opérationnel.

Conclusion 

Avec des Mythos-like, la sécurité des systèmes dépend désormais encore plus de la qualité et de la maîtrise des dépendances. Il était déjà évident qu’il n’était pas possible d’éviter toutes les failles. Encore plus avec Mythos, la priorité est d’augmenter la prophylaxie, de réduire l’exposition et de réagir plus vite que les attaquants en mettant en place des systèmes de détection.

Mythos ne change pas la nature des risques, il change leur vitesse et leur échelle. Ce qui était gérable avec du temps et des ressources humaines devient ingérable sans automatisation défensive. C’est une transformation de régime, pas une évolution de degré.

Scénario possible d’attaque

Synthèse de l’attaque

Ce scénario décrit une attaque en 6 phases ciblant une fintech via une vulnérabilité dans une dépendance open source dans le cadre d’un process d’attaque sur la base d’un Mythos-like.

L’attaquant utilise un LLM de type Mythos pour automatiser l’ensemble de la chaîne, du scan jusqu’à l’exploitation. On va se placer dans une attaque supply-chain. A noter que je n’expliciterai pas les process d’extorsion pour de nombreuses raisons.

Les 6 phases :

Phase 0 : Préparation

Un LLM de type Mythos scanne massivement les registres open source (GitHub, npm , autres) pour identifier des vulnérabilités dans des librairies très utilisées (capacités 1 et 3). La vulnérabilité ciblée est non connue (0-day ou quasi) et exploitable à distance. Cette phase est quasi-certaine aujourd’hui : même avant Mythos, les outils existent, le coût est marginal.

Probabilité relative : très élevée (> 90%) : les capacités sont disponibles aujourd’hui, à un coût marginal, et déjà observées en production (cf. Mozilla / Mythos).

Phase 1 : Ciblage automatisé

Le LLM identifie tous les projets utilisant la librairie vulnérable, puis les priorise selon des critères métier objectifs : secteur fintech, plateformes transactionnelles, volumétrie élevée. Toute fintech entre naturellement dans la cible sans action humaine directe. La priorisation est exhaustive et rationnelle.

Probabilité relative : élevée (> 75%) : cela reste conditionnée à l’usage de la lib vulnérable en production, et à la volonté d’attaquer une fintech, mais on pourrait mettre 100%…

Phase 2 : Fingerprinting attaquant applicatif

Sans aucun accès interne, l’attaquant observe le comportement public de la plateforme : headers HTTP, réponses API, messages d’erreur, formats de payload.

Le LLM infère la stack technique probable et génère des variantes d’exploit adaptées. Cette phase inclut une sous-étape d’apprentissage comportemental (phase 2.5) : l’attaquant observe quels montants passent sans friction et quels patterns ne déclenchent pas de vérification.

Probabilité relative : élevée (> 75%) : la surface publique d’une fintech est par nature exposée…

Phase 3 : Choix d’exploitation ciblée

L’attaquant teste les vecteurs identifiés sur les endpoints publics. L’exploit est adapté en temps réel par le LLM selon les réponses observées. C’est l’étape qui peut convaincre l’attaquant de continuer sans garantie de succès ou renoncer d’ores et déjà.

Probabilité relative : modérée (25 à 75% ?) : en pratique cela dépend de la présence de la librairie en runtime et de l’absence de mitigation en amont.

Phase 4 : Le pivot métier

C’est le cœur du scénario. L’objectif de l’attaquant n’est pas l’accès système brut (la gloire) mais la fraude financière directe (l’argent…). Un attaquant rationnel optimise pour le gain, pas pour la présence technique (sauf dans le cas d’APT ou de volonté industrielle, mais alors nous ne serions pas dans CE scénario). L’accès applicatif obtenu en phase 3 est immédiatement converti en actions métier frauduleuses.
Les objectifs possibles sont alors nombreux :

• Manipulation de transactions ;
• Création de comptes frauduleux : usurpation d’identité à grande échelle ;
• Détournement de payout : redirection de virements sortants ;
• Contournement des contrôles antifraude : exploitation de la logique métier.

Comme je l’ai dit, je ne vais pas exposer la probabilité de ces buts d’attaque. Mais n’oublions pas que la logique métier d’une fintech est la cible de valeur structurelle.

En tout cas, ce qu’il faut retenir, c’est que cette phase contourne MFA, WAF, sécurité périmétrique. Elle passe directement par la logique applicative et métier, là où les défenses traditionnelles sont absentes.

Phase 5 : Attaque basse intensité (stealth ou low and slow…)

Grâce au LLM, l’attaque est rendue délibérément lente, distribuée et comportementalement normalisée. Les seuils statistiques classiques ne sont pas déclenchés. C’est la phase où la corrélation technique/métier devient non plus un atout mais une nécessité absolue.

Rappel : quelques caractéristiques des attaques low and slow / stealth :

• Rythme lent : requêtes espacées, mimant le comportement d’un utilisateur humain ;
• Distribution géographique : rotation d’adresses IP par l’usage d’ASN grey (facile à trouver…) ;
• Variation des payloads : chaque requête est légèrement différente (en particulier tous les « textes ») ;
• Calibration des seuils : le LLM ajuste en temps réel pour rester sous les alertes.

Seule la corrélation entre signaux techniques et événements métier (anomalies de transaction, patterns inhabituels grâce à la gestion de la suspicion) permet la détection.

Probabilité relative : élevée (> 75%) : si l’attaquant en est arrivé là, alors il adoptera un comportement rationnel pour maximiser la durée d’exploitation.

Phase 6 : Industrialisation

Une fois le vecteur validé, l’attaque est scalée automatiquement par le LLM : variation des payloads, adaptation continue, passage d’une attaque ciblée à une campagne sectorielle.

Il peut alors à la fois la rejouer sur la fintech ciblée, mais aussi distribuer (revendre) le playbook en proposant de l’adapter sur d’autres acteurs fintech.

Probabilité relative : certaine (100%) : c’est le comportement naturel face à un vecteur validé.

Synthèse des propositions (idées) de mitigations

Les contre-mesures sont ordonnées selon leur impact et leur position dans la chaîne d’attaque.

Les priorités 1 agissent avant ou pendant les premières phases ; les priorités 2 et 3 couvrent la détection et la résilience post-exploitation.

Mesures techniques spécifiques

Priorité	Mesure	Description
P1	SBOM dynamique runtime	Inventaire des librairies réellement utilisées en production (pas seulement déclarées au build). Seule mesure qui agit avant la phase 3. Aligné DORA / NIS2 / Recyf.
P1	Détection métier et gestion de la suspicion	Anomalies sur création comptes, patterns paiement, variations IP/ASN/Pays//etc… Corrélation technique ↔ métier indispensable pour détecter l’exploitation post-phase 3.
P2	Logs enrichis corrélés	WAF + applicatif + événements métier. Seul moyen de rendre visible une exploitation IA-driven basse intensité (phase 5).
P3	Sécurisation pipeline CI/CD	Surveillance des injections au moment du build. Contourne le SBOM statique. Couvre le vecteur de compromission via dépendances transitives.

Mesures politiques

Priorité	Mesure	Description
P1	Renforcement prophylactique	Enforcer une véritable politique d’inventaire : users (on/off boarding, gestion des accès par outil) ;partenaires (assessment) ;outils (SBOM, patch management).
P3	Acceptation stratégique	Prioriser la capacité de réponse plutôt que l’illusion d’une prévention totale. C’est un choix politique, celui de concevoir que certaines exploitations surviendront, et qu’alors l’objectif est de les détecter au plus vite et d’en contenir l’impact métier.

Autres idées mais plus complexes à mettre en place :

Priorité	Mesure	Description
P2	Patching priorisé par criticité métier	Boucle courte vulnérabilité → mitigation, priorisée selon l’impact réel sur les flux financiers, pas seulement sur le score CVE.

---

[1] Voir à ce sujet la conférence de Vincet Strubel à l’IFRI le 26/03/2026, et sa synthèse ici : https://radical-ssi.fr/2026/04/03/conference-de-vincent-strubel-dg-anssi-la-france-face-aux-nouveaux-defis-de-la-cybersecurite-26-mars-2026/

[2] https://nicholas.carlini.com/

[3] https://red.anthropic.com/2026/mythos-preview/

[4] https://red.anthropic.com/2026/mythos-preview/#:~:text=we%20have%20found%20so%20far%20being%20a%20now%2Dpatched%C2%A027%2Dyear%2Dold%20bug%20in%20OpenBSD%E2%80%94an%20operating%20system%20known%20primarily%20for%20its%20security.

[5] https://about.gitlab.com/blog/gitlab-discovers-widespread-npm-supply-chain-attack/

[6] Voir https://www.enisa.europa.eu/publications/good-practices-for-supply-chain-cybersecurity

[7] https://lab.cyber.gouv.fr/les-actualit%C3%A9s-du-lab-anssi/recyf–publication-du-r%C3%A9f%C3%A9rentiel-dexigences-et-du-comparateur/