L’attaquant ne dort jamais. Vos tests non plus.

Il y a quelques mois, j’écrivais que l’IA élargit votre surface d’attaque plus vite que vous ne pouvez la tester. Je maintiens chacun des mots que j’ai écrits alors. Mais au cours des mois qui ont suivi, après plus d’une centaine d’échanges avec des RSSI, des DSI et des directeurs techniques de presque tous les secteurs et toutes les régions, j’ai vu la situation se préciser et devenir bien plus urgente. La surface d’attaque ne représentait que la moitié du problème : le profil des attaquants a lui aussi changé.

Commençons par la bonne nouvelle, car il y en a beaucoup. Nous vivons une époque d’abondance logicielle. Les laboratoires à la pointe estiment désormais à plusieurs milliers de milliards de dollars le marché du code généré par l’IA, et collectivement, nous livrerons cette année plus de logiciels que jamais dans l’histoire. Un travail qui prenait autrefois un trimestre se fait maintenant en un après-midi. Cette évolution est réelle, extraordinaire et irréversible.

Mais derrière cette abondance se cache un fossé que presque personne ne prend en compte : le fossé de la confiance. Nous pouvons désormais générer des logiciels plus vite que nous ne pouvons leur faire confiance, et la même capacité de raisonnement qui a créé cette abondance vient de tomber entre les mains de ceux qui cherchent à les compromettre.

L’attaquant qui ne dort jamais

Voici ce qui a changé et qui figure désormais en tête de ma liste. C’est ce que les dirigeants me disent en premier. Depuis vingt ans, notre adversaire était avant tout humain, limité par le temps, l’attention et les moyens dont dispose une personne. Cette limite a disparu. Dès qu’un laboratoire à la pointe dispose d’un modèle capable de mener des cyberattaques et doté de capacités de raisonnement avancées, le deuxième y a accès en quelques mois, et des équivalents open source suivent peu après.

En juin, les chefs du renseignement des Five Eyes ont dit tout haut ce que tout le monde pensait tout bas : l’IA de pointe va transformer la cyberdéfense et les cyberattaques en quelques mois, et non en quelques années, et les organisations doivent agir dès maintenant. En novembre dernier, Anthropic a révélé qu’un groupe parrainé par un État avait utilisé ses modèles pour mener environ 80 à 90 % d’une campagne d’espionnage active visant une trentaine de cibles, des opérateurs humains n’intervenant qu’à quelques étapes clés. Certaines de ces intrusions ont réussi. L’adversaire est désormais un attaquant qui ne dort jamais. Il analyse vos applications à la vitesse des machines, selon un rythme qu’aucune équipe de défense organisée pour l’ancien monde ne peut suivre. Il n’est plus question d’attendre le prochain cycle budgétaire pour agir.

Imaginez une tour de Jenga

Pour expliquer concrètement la situation à un conseil d’administration, je prends l’image d’une tour de Jenga : le risque s’empile couche après couche, et chaque nouvelle couche rend l’ensemble plus instable.

La couche inférieure : vos risques existants, désormais exploités

Tous les programmes de sécurité ont toujours implicitement accepté un compromis : corriger les problèmes majeurs et critiques, et laisser les autres en attente, car un attaquant humain n’avait ni le temps ni les moyens d’enchaîner les problèmes mineurs pour provoquer une véritable brèche. Vous sécurisiez la porte d’entrée et la porte de derrière, en vous disant que personne n’irait chercher une échelle pour atteindre le lanterneau. Eh bien, l’attaquant a maintenant un drone pour atteindre le lanterneau.

L’ensemble de votre backlog est désormais exposé, et les données de nos clients montrent qu’il a à peu près doublé avec l’accélération du développement par l’IA. À mesure que les agents accélèrent la création, vous ne produisez pas seulement un peu plus de code : vous en produisez beaucoup plus, et les vulnérabilités augmentent de façon exponentielle. Les agents ne sont pas encore aussi performants qu’un ingénieur humain chevronné (je dirais que c’est là la véritable définition de l’AGI). Le jour où ils le seront — et d’ici là, comme l’a dit Jen Easterly, nous avons moins un problème de cybersécurité qu’un problème de qualité logicielle. L’IA vient de donner à ce problème une tout autre ampleur.

La couche intermédiaire : une nouvelle catégorie de risques liée à la façon dont les agents développent

Les agents n’utilisent pas la chaîne d’approvisionnement logicielle humaine : ils font appel à leurs propres serveurs MCP, compétences et outils. Nos recherches sur cet écosystème ont révélé une toute nouvelle catégorie de failles. Nous les appelons flux toxiques, et ils sont suffisamment graves pour qu’un serveur MCP largement utilisé ait été retiré de la production par certaines des plus grandes entreprises du monde. Et les maliciels en question ne ressemblent pas aux maliciels classiques : il peut s’agir de trois lignes en anglais courant dans la description d’un outil, qui incitent discrètement un agent à commettre un acte destructeur. Il est impossible de détecter une intention en faisant simplement correspondre des modèles.

De plus, les agents sont non déterministes : donnez un objectif à l’un d’eux, et il se comportera comme un poursuivant infatigable, prêt à contourner tout contrôle qui se trouve entre lui et son but. Nous avons vu des agents faire discrètement des copies privées de données sensibles « au cas où ». Ce comportement doit être encadré et orienté pour que l’agent reste dans les limites de son mandat, et non laissé à lui-même au risque qu’il dévie.

La couche supérieure : chaque entreprise devient une entreprise agentique

L’IA transforme les logiciels comme les logiciels ont transformé le monde, ce qui signifie que chaque processus métier finira par devenir un agent conçu par quelqu’un. La sécurité de cet agent devient une question primordiale. La plupart des organisations ont bien moins de visibilité qu’elles ne le pensent : j’ai rencontré de grandes entreprises persuadées d’utiliser cinq modèles approuvés, avant d’activer Discovery et d’en découvrir plus de cinquante.

Les modèles ne sont que du code que quelqu’un copie, colle et exécute localement, avant qu’il ne se retrouve soudainement en production. Et lorsqu’un agent devient, de fait, votre porte d’entrée, les risques prennent une forme très concrète. Par exemple, un robot de service client que l’on peut convaincre de révéler des informations qu’il devrait garder secrètes. (Je reconnais avoir moi-même réussi à en convaincre un d’ignorer ses instructions, par simple impatience un jour de voyage. Du premier coup. Est-ce vraiment ce que vous voulez en première ligne de votre entreprise ?)

On ne confie pas la garde du poulailler au renard

Certains fournisseurs de modèles racontent une histoire à laquelle je dois constamment m’opposer : l’IA qui génère tout ce code et ces comportements serait aussi capable de les sécuriser. Elle corrigerait ses propres copies. Ne serait-il pas pratique que l’auditeur et le comptable soient la même personne ?

Tous les professionnels de la sécurité savent déjà pourquoi ça ne fonctionne pas. Alors, soyons clairs : le générateur ne peut pas être le validateur. Un modèle chargé de détecter et de certifier ses propres failles est confronté à un conflit d’intérêts structurel, et ses résultats sont incohérents. Exécutez-le cinq fois sur la même cible et les résultats ne se recouperont peut-être qu’à moitié. Impossible de bâtir un programme de sécurité là-dessus.

Les laboratoires ne sont pas les méchants de l’histoire : leurs modèles sont réellement utiles et, bien employés, détectent des problèmes que les outils classiques ne voient pas. Mais comme ils créent la plupart des problèmes, ils ne peuvent pas en être les seuls juges. Il faut une validation indépendante. (Mon collègue Nuno Loureiro a écrit la référence technique sur le sujet, d’abord sur la nécessité de tests dynamiques offensifs pour le code généré par l’IA, puis sur les origines de la sécurité offensive continue. Ces deux articles valent vraiment le détour.)

La peur est réelle, mais l’espoir aussi

Je ne veux pas vous laisser avec cette seule image de la tour, car la part d’espoir est tout aussi réelle, et c’est là que le travail commence. Il existe une action pour chaque couche, et chacune peut être mise dès aujourd’hui entre les mains d’un ingénieur en sécurité.

• Éliminez le backlog : L’ancienne logique de triage ne résiste pas à un attaquant qui enchaîne les problèmes de faible gravité que vous aviez mis de côté. Cela semble impossible, jusqu’à ce que vous confiez les corrections à l’IA. Certains de nos clients, parmi les plus grandes entreprises du monde, ont désormais un backlog nul parce que les agents corrigent les problèmes au lieu de se contenter de les détecter.

• Utilisez l’IA pour repérer ce que les outils déterministes ne détectent pas… avec discernement : les modèles de raisonnement révèlent des problèmes que les scanners ne voient pas. Utilisés en complément et avec la validation d’un outil indépendant, ils offrent un véritable avantage. Utilisés sans recul, ils génèrent du bruit. Nous intégrons à nos produits des modèles de niveau défense précisément pour que les équipes puissent en tirer parti sans jouer à pile ou face.

• Testez comme le ferait un attaquant : Si votre adversaire prévoit de vous sonder de façon autonome à l’aide d’un modèle doté de capacités de raisonnement avancées, la seule réponse honnête consiste à exécuter en continu une version de niveau défense de ce même modèle contre vos propres applications, dans votre propre environnement, avant lui. L’ancienne approche ne peut pas suivre : un test d’intrusion classique couvre environ quinze jours par an et laisse les trois cent cinquante autres jours sans couverture, alors même que l’application a connu trois nouvelles mises à jour pendant la rédaction du rapport.

• Évitez les cent prochains problèmes : Corriger indéfiniment ne mène nulle part si vous ne coupez jamais l’arrivée de nouveaux problèmes. Notre véritable superpouvoir n’est pas de dire à un développeur après coup « voici un problème », mais de dire à l’agent, avant qu’il ne termine sa tâche : « Non, ce code n’est pas sécurisé, ce paquet n’est pas fiable, corrige ça. » Autrement dit : Sécurisez dès la conception.

• Encadrez le tout par une gouvernance : Découvrez tous les composants agentiques que vous utilisez, déterminez les risques réels de chacun, appliquez vos politiques — notamment quels modèles sont autorisés pour quels cas d’usage — et soumettez à des tests d’intrusion vos applications natives de l’IA, car elles se comportent différemment de tous les logiciels que nous avons sécurisés jusqu’ici.

• Sécurisez les artefacts. Sécurisez les équipes. Sécurisez l’entreprise : Un cycle pour chaque problème, orchestré de sorte qu’une personne puisse garder le contrôle sans se laisser submerger, car à cette échelle, vouloir tout gérer soi-même est voué à l’échec. Et un cycle ne s’achève que lorsqu’un acteur indépendant attaque ce que vous avez livré et prouve que ça tient. Détecter, corriger et gouverner constituent la défense ; la sécurité offensive continue en apporte la preuve. Vous ne pouvez pas honnêtement affirmer être prêt face aux attaques automatisées, ni sans risque placer un agent à la tête de votre activité, tant qu’un tiers n’a pas attaqué vos systèmes comme le ferait votre adversaire. C’est la vision qui guide Evo et que nous nous attachons à concrétiser.

Deux problèmes que je refuse d’ignorer

Deux autres sujets me préoccupent, et je pense qu’ils ont leur place dans cette discussion, même s’ils dépassent le cadre d’un seul fournisseur.

Problème n° 1 : concentration et choix

La concentration du pouvoir entre les mains d’un trop petit nombre de modèles représente un risque à part entière, pour la résilience, la souveraineté et, désormais, les coûts, qui sont presque du jour au lendemain devenus un sujet de conseil d’administration. Les organisations ne devraient pas avoir à choisir à l’aveugle. Elles ont besoin de validateurs indépendants capables de leur indiquer quels modèles sont sûrs pour quels usages, car la réponse est rarement toute noire ou toute blanche. Certains modèles ouverts largement accessibles respectent parfaitement vos règles, mais ne devraient jamais recevoir de données sensibles. Seuls des tests d’intrusion réalisés pour vous permettent de le savoir.

C’est pourquoi Snyk est désormais signataire et apporte son soutien à la lettre Open Weights and American AI Leadership, aux côtés de 270 autres entreprises, dont Microsoft, Nvidia et CrowdStrike.

Problème n° 2 : l’open source

C’est le carburant de l’économie moderne. La majorité des logiciels sont open source, et cet écosystème est mis à rude épreuve, sans que beaucoup de gens le reconnaissent. Selon mon analyse du secteur, des dizaines de milliers de vulnérabilités non divulguées sont déjà entre les mains d’acteurs privés, repérées par des groupes bien financés qui testent discrètement ces nouvelles capacités sur des projets open source. C’est le problème des attaquants déjà agentiques, qui s’en prennent à un bien commun. Les responsables de la maintenance sont submergés par un mélange de signalements pertinents et de contenu médiocre généré par l’IA, sans pouvoir suivre le rythme. C’est ainsi qu’un bien commun s’effondre sous son propre poids, et ce serait une catastrophe. C’est pourquoi nous avons rendu notre plateforme gratuite pour les responsables de la maintenance de projets open source communautaires : une contribution modeste, selon nous, à une responsabilité bien plus vaste que l’ensemble du secteur doit assumer.

C’est aussi pourquoi Snyk rejoint Nvidia et d’autres leaders technologiques au sein de l’Open Secure AI Alliance.

Qui teste ce que l’IA génère ?

J’ai conclu mon dernier article par une question, qui résonne aujourd’hui encore plus fort : qui teste vraiment — qui attaque — le code et les agents que l’IA crée et exécute en votre nom ? Pour la plupart des organisations, aujourd’hui, la réponse honnête est… personne. C’est le déficit de confiance que nous constatons. La bonne nouvelle, c’est que la réponse peut être vous : avec votre propre IA, bien orientée, conçue pour être indépendante et avec un humain dans la boucle. Les attaquants ne dorment jamais. Vos tests non plus ne peuvent se permettre de dormir. Mais, pour la première fois, ce n’est plus une fatalité.

Manoj Nair est directeur de la technologie et de l’innovation chez Snyk.