Mythos : au-delà des alertes, le nouveau défi des RSSI

IA et chaîne de développement : les mêmes menaces, mais plus rapides, plus vastes, et plus difficiles à évaluer.

La mission des RSSI est de protéger leur organisation, ses collaborateurs et ses actifs contre les menaces. Pour cela, ils doivent composer avec un flux permanent d’alertes. Mais le volume des alertes n’est qu’une partie du problème. Le véritable défi réside aussi dans le risque non maîtrisé : celui que l’on ne voit pas, que l’on ne peut pas mesurer ou dont on ignore tout simplement l’existence.

Pour un RSSI, l'ignorance n'est jamais une option. Le véritable ennemi, c'est le manque de visibilité. Dès lors qu'une menace est comprise, que son fonctionnement est identifié et que son origine est connue, il devient possible d'y répondre efficacement. Mais dans un monde où l'innovation s'accélère sans cesse, notre capacité à identifier, comprendre et évaluer les risques doit progresser au même rythme.

Pourquoi l'IA bouleverse la sécurité de la chaîne de développement 

Un argument revient régulièrement dans la perception qu’ont les RSSI des LLMs : Mythos et les modèles similaires ne feraient qu’amplifier des menaces déjà connues, sans introduire de rupture fondamentale.

Il ne s’agit pas de céder à l’alarmisme, mais de prendre la mesure des évolutions en cours. Considérer que ces nouveaux modèles ne font qu’amplifier des menaces déjà connues risque de conduire à une erreur bien plus dangereuse : celle de ne rien changer. Car si les menaces peuvent sembler familières, les capacités disponibles, la vitesse d’exécution et l’échelle à laquelle elles peuvent désormais être exploitées ont, elles, profondément évolué.

Pendant longtemps, les équipes se contentaient d'analyser la composition des logiciels (Software Composition Analysis), d'identifier le contenu des packages puis de passer à autre chose. Elles s'intéressaient rarement aux menaces qu'ils pouvaient véhiculer. Aujourd'hui, les attaquants ciblent bien davantage que les seuls composants open source. Les attaquants ciblent désormais les propriétaires de dépôts de code, mais aussi les LLM, les MCP, les Skills, et la liste ne cesse de s'allonger. La surface d'attaque ne se limite plus à un simple périmètre : elle couvre désormais l'ensemble du cycle de développement, de la création au packaging, jusqu'à la distribution et à l'exploitation des applications.

L'aube d'une nouvelle ère

Cette nouvelle ère marque une véritable rupture, même si certains estiment qu'il ne s'agit que d'une évolution de menaces déjà connues. Jusqu'à présent, face à une vulnérabilité, la question était simple : la fonction concernée est-elle réellement utilisée ? Une fonction vulnérable ne rend pas pour autant un package entier vulnérable. Si elle n'est jamais appelée, le risque reste limité.

Les chiffres parlent d'eux-mêmes : selon le dernier rapport SSC Security State of the Union de JFrog, seulement 12 % des CVE les plus médiatisées en 2025 étaient réellement hautement exploitables dans des environnements d'entreprise, tandis que 66 % obtenaient un score compris entre 0 et 20 % sur une échelle d'applicabilité. Ces résultats montrent qu'une vulnérabilité n'est pas systématiquement synonyme de risque réel, dès lors qu'elle est analysée dans son contexte.

Avec les modèles d'IA de nouvelle génération, cette analyse devient beaucoup plus complexe. Il ne s'agit plus seulement de déterminer si une fonction est utilisée. Il faut également prendre en compte la manipulation des données, leurs flux et des faiblesses parfois profondément enfouies. Les alertes devraient donc fournir davantage de contexte, en indiquant non seulement le package concerné, mais aussi la technique de manipulation des données en cause. Les équipes de renseignement sur les menaces pourraient ainsi évaluer plus efficacement si le risque est réel.

Cette nuance est essentielle. Elle permet de distinguer les alertes réellement critiques de celles qui ne nécessitent pas d'action immédiate, et de réduire le bruit qui complique le travail quotidien des équipes de sécurité.

Le piège des solutions ponctuelles refait surface avec l'IA 

Cette évolution souligne la nécessité de consolider les outils de sécurité autour d'une source de données commune, partagée par les équipes de sécurité, DevSecOps et de sécurité produit. Dans un contexte où les flux de renseignement sur les menaces se multiplient, augmenter le nombre d’outils qui remontent les mêmes informations n'améliore pas la protection. Cela ne fait qu'accroître la complexité.

Cette prise de conscience progresse. La part des organisations utilisant sept solutions AppSec ou plus est ainsi passée de 73 % à 35 % en seulement un an. Pourtant, de nombreuses entreprises restent confrontées à une multiplication des outils qui fragmente leur visibilité et complique la gestion des risques. 

L'IA risque pourtant de faire renaître les mêmes travers. Beaucoup d'organisations investissent dans des registres MCP, convaincues d'avoir résolu le problème, alors qu'elles ne traitent qu'une partie de la surface d'attaque. Elles continuent ensuite d'ajouter de nouveaux outils pour répondre à chaque nouveau besoin, sans jamais prendre le recul nécessaire pour s'interroger sur leur véritable objectif. Au fond, le piège reste le même : seuls les outils changent. L'enjeu n'a jamais été de sécuriser un composant isolé, mais de protéger l'ensemble de l'application d'IA.