La prévention est-elle essentiellement un problème résolu ?

Empêcher le déploiement de nouvelles failles de sécurité dans du code généré par des agents est, architecturalement, un problème résolu. La prévention consiste à empêcher qu’une nouvelle vulnérabilité dans le code n’atteigne la production à quelque étape que ce soit du processus de développement et de mise en production, notamment, mais pas uniquement, en empêchant son introduction dans une branche de fonctionnalité. Le cycle de développement agentique comporte des points distincts où la sécurité peut être intégrée, chacun se prêtant à un type de contrôle différent, et la correspondance entre eux est bien comprise. Appliquer cette approche au sein d’une organisation alors que le cycle de vie du développement logiciel évolue activement la rend difficile à mettre en œuvre.

Vous ne pouvez pas tout résoudre avec des prompts

La version idéalisée de la sécurité dans le développement agentique tient en une seule instruction : demander à l’agent d’écrire du code sécurisé, placer cette instruction dans le prompt système ou la configuration du harnais, puis le laisser travailler.

Figure 1. L’instruction qui ressemble à un contrôle.

Les indications présentes dans la fenêtre de contexte modifient effectivement ce que produit un agent, et leur effet est suffisamment réel pour servir de base, mais une instruction n’est pas une contrainte. Elle modifie la probabilité de ce qui sera écrit, sans le déterminer. Cela vaut pour une règle d’une ligne comme pour une compétence soigneusement rédigée. C’est une caractéristique du fonctionnement de ces modèles (qui prennent en compte toutes les entrées et évaluent leur priorité relative), indépendamment de la qualité de votre prompt.

Le code généré par l’IA reste exposé aux mêmes catégories de vulnérabilités que le code écrit par des humains a toujours connues. Une instruction seule n’y change rien, et aucun travail sur les prompts n’y changera quoi que ce soit. La question utile est donc de savoir où placer tout le reste.

« Shift in » est le nouveau « shift left »

Trois coûts augmentent à mesure que la sécurité s’éloigne du moment où le code est écrit.

Figure 2. Les trois augmentent ensemble à mesure que la sécurité s’éloigne.

Les tokens sont le premier élément évident. Le coût d’une analyse déterministe est négligeable à côté de celui d’un appel de modèle, et l’écart se creuse chaque fois que vous demandez à un modèle de raisonner sur une plus grande partie de la base de code.

L’attention humaine est le deuxième. Un problème détecté alors qu’un agent travaille encore ne devient jamais un ticket, n’est jamais trié et n’interrompt jamais quelqu’un qui jongle entre plusieurs tâches.

Le troisième est de corriger correctement le problème. Un agent qui travaille dans les boucles internes dispose encore du prompt et de la spécification d’origine. Lorsqu’il corrige quelque chose, il peut donc confirmer que le résultat est à la fois fonctionnellement intact et sécurisé, car il sait ce que le code était censé faire. Si l’on repousse le même constat plus loin, ce contexte disparaît. Il faut alors réétablir la correction de l’extérieur, au moyen de tests unitaires, de tests de fumée et de tests d’intégration exécutés avant et pendant la CI.

Un agent qui étend une fonctionnalité existante s’appuie également sur la suite de tests dans les boucles internes, car il doit savoir qu’il n’a pas cassé quelque chose qu’il n’a pas vu. Mais il s’y fie moins, puisqu’il dispose toujours du prompt et peut raisonner sur ce que la modification était censée faire, plutôt que d’inférer l’intention à partir de ce qui réussit par hasard. Plus une correction est repoussée vers l’extérieur, plus cette charge repose uniquement sur la couverture.

Voilà pourquoi il faut rapprocher la sécurité du développement. Si cela ne se fait pas spontanément, c’est parce que la pression dans l’autre sens est plus forte.

La sécurité crée des frictions

Rien de tout cela n’est nouveau. La sécurité coûte du temps, et intégrer cette dépense dans le flux de travail des développeurs a toujours été la partie la plus difficile de ce métier. C’est pourquoi Snyk a été un pionnier du shift left dans le DevSecOps avec succès, dès son lancement il y a dix ans.

L’ère agentique amplifie ce phénomène au lieu de le modifier. Les organisations fondent l’adoption de l’IA sur des multiples de productivité des développeurs. Et lorsque l’on attend un changement radical du débit de production, tout ce qui ralentit la boucle ne fait pas l’objet d’un arbitrage. On le supprime.

La question n’est donc pas de savoir s’il faut ajouter des contrôles de sécurité, mais plutôt où chacun peut être placé sans coûter plus qu’il ne permet d’économiser.

Le cycle de vie est une superposition de boucles

Le modèle en boucles de Laurie Voss est l’une des descriptions les plus claires de la manière dont les logiciels sont désormais construits : un ensemble de boucles imbriquées, chacune se refermant sur son propre signal.

• La boucle d’exécution termine une instruction et se clôt sur un retour de l’environnement, qu’il s’agisse du résultat d’un test, d’une réponse d’API ou du contenu d’un fichier.

• La boucle de tâche termine une spécification.

• La boucle produit met le produit en production.

• La boucle système améliore l’ensemble sur plusieurs jours et semaines.

• La boucle de supervision est celle où un humain fixe les objectifs, alloue un budget et décide de ce qui compte.

Figure 3. La superposition de boucles, d’après « What the hell is a loop, anyway?

Dans les boucles d’exécution et de tâche, le travail est encore en cours, et un problème peut encore être corrigé avant la fin de la boucle, sans intervention humaine. À partir de la boucle produit, il faut accorder une confiance importante à la couverture des tests ; sinon, une revue humaine est nécessaire.

Deux réserves avant de poursuivre. Premièrement, l’adoption est inégale : le niveau d’adoption du développement agentique varie, y compris au sein d’une même entreprise. De nombreuses équipes n’exécutent pas d’agents dans chacune de ces boucles, et beaucoup ont encore des personnes qui travaillent au cœur des boucles internes plutôt qu’uniquement au niveau de la supervision. Les boucles restent valables dans tous les cas, car elles décrivent le moment où un travail se termine, et non la personne ou l’agent qui l’a terminé.

Deuxièmement, si vous retirez le vocabulaire agentique, l’essentiel de cette description correspond à la manière dont les logiciels sont construits depuis longtemps : on itère sur une modification, on termine une unité de travail, on met en production, on améliore le système, puis quelqu’un décide de ce qui mérite d’être fait ensuite. Ce qui a changé, c’est la vitesse et l’identité de celui (ou de ce qui) qui est au clavier.

Les risques que vous pouvez identifier à l’avance

Certains risques sont parfaitement prévisibles : injection SQL, cross-site scripting, secrets codés en dur, paramètres cryptographiques faibles et erreurs de configuration IaC les plus courantes. Nous savons exactement ce que nous recherchons, et nous pouvons indiquer à un agent comment les éviter avant même qu’il n’écrive une ligne.

Le contrôle consiste à fournir des indications dans le contexte de l’agent : prompts système, configuration du harnais et compétences couvrant les risques qu’une équipe souhaite le plus éviter de produire. C’est le contrôle le moins coûteux disponible, car son coût est payé une seule fois dans l’espace de la fenêtre de contexte, plutôt qu’à chaque problème vérifié. Rien n’est exécuté et rien n’est évalué ; les indications sont simplement présentes.

Une partie de ces indications est déjà en place sans que personne n’ait à déployer quoi que ce soit. Les harnais incluent par défaut des prompts système qui portent certaines de ces directives. Par exemple, Anthropic documente les prompts système de chacun de ses modèles. En outre, de nombreuses organisations créent des registres de compétences partagés, parfois avec des compétences propres aux applications qui décrivent la manière dont leurs équipes construisent leurs produits. Une compétence de sécurité n’est donc pas un nouveau type d’artefact à distribuer, mais une entrée supplémentaire dans un système qui existe déjà.

La limite, ici, est le contexte. Chaque instruction entre en concurrence avec celles qui sont déjà présentes dans la fenêtre, et charger toute la gamme des catégories de vulnérabilités dans le contexte d’un agent dilue les indications les plus importantes au profit de risques qui se manifestent rarement. Il faut rationner, ce qui signifie qu’un autre mécanisme doit détecter ce que vous laissez de côté. Et le contexte n’est que la moitié de la contrainte. Même avec un espace illimité, certains risques ne peuvent tout simplement pas être formulés dans une instruction, car personne ne savait qu’ils existaient au moment où celle-ci a été rédigée.

Les problèmes dont personne n’aurait pu informer l’agent

Lorsque des développeurs ou des agents sélectionnent un package, ils choisissent souvent la dernière version, parce qu’elle est à jour et répond à leurs besoins. Si une vulnérabilité de cette version a été divulguée la même semaine, aucun des deux ne le saura. Le modèle n’a pas été entraîné sur cette information. Aucune compétence n’aurait pu la couvrir, puisque la divulgation n’existait pas au moment de sa rédaction. Demander à la prévention par instruction de gérer ce cas n’est raisonnable pour personne.

Il y a ensuite tout ce que vous avez rationné à l’étape précédente. Le vaste ensemble des risques qui ne peuvent pas entrer dans un prompt système ou une compétence sans polluer le contexte, mais qui sont parfaitement réels et parfaitement détectables. Du point de vue de l’agent, ces deux catégories de risques constituent le même problème : on ne lui a jamais demandé de s’en méfier.

Les deux nécessitent un test qui s’exécute de manière exhaustive plutôt que sélective, se déclenche tant que le travail est encore en cours et renvoie ses résultats suffisamment vite pour que l’agent soit encore présent et puisse agir. Et il ne devrait pas s’arrêter à la détection. Si l’agent peut corriger ce que le test révèle, puis relancer celui-ci, la boucle se referme sans faire intervenir un humain, ce qui est la seule version de cette approche capable de résister à la réalité d’une équipe qui mesure son débit de production.

Trusted Output Assurance (qui fait partie de Evo Agentic Development Security) réalise cela grâce à des hooks et à la CLI. Une analyse se déclenche à mesure que les fichiers sont écrits, puis à nouveau lorsque l’agent termine le travail prévu, afin que les problèmes nouvellement introduits soient détectés et corrigés avant la fin de la spécification, le tout dans les boucles internes. Les contrôles d’intégrité des packages, l’analyse des secrets et la protection contre le code malveillant suivent le même parcours.

Un agent qui corrige tout ce qu’on lui transmet réécrira parfois du code fonctionnel pour satisfaire un problème qui n’était pas réel. C’est notamment pourquoi cette étape doit s’appuyer sur des moteurs déterministes plutôt que probabilistes, et pourquoi le taux de faux positifs doit être évalué au moment de choisir ce qui sera exécuté. Vous devez également comprendre ce qui se passe lorsque le moteur et l’agent ne sont pas d’accord sur un problème détecté. Snyk optimise ces deux aspects. Un contrôle ne mérite sa place dans les boucles internes que s’il est assez souvent juste pour pouvoir être appliqué sans supervision. Lorsque la confiance est moindre, le problème doit être traité plus loin.

Un contrôle de ce type ne vaut que ce que vaut son adoption, et l’adoption est le point où la sécurité dans les boucles internes a toujours rencontré des difficultés, car elle dépendait de chaque développeur pour être configurée. Cette partie est désormais simple. Les organisations déploient Trusted Output Assurance via MDM sur les machines des développeurs et l’intègrent aux modèles de sandbox, de sorte qu’il soit déjà présent partout où du code est généré, et que ce qui s’exécute sur quelle machine soit visible de manière centralisée, plutôt que de devoir être simplement considéré comme fiable.

Ce qui pose problème aux moteurs rapides et déterministes

Les failles d’autorisation et de logique métier constituent un problème différent. Autorisation défaillante au niveau des objets, IDOR, défauts d’isolation entre locataires et abus en plusieurs étapes. Ces catégories sont bien comprises, et les moteurs fondés sur des règles sont réellement mauvais pour les détecter, car la faille est sémantique plutôt que syntaxique. Rien dans le code ne semble incorrect. Ce qui est incorrect, c’est la relation entre les éléments.

L’analyse fondée sur les LLM de la base de code assemblée est ce qui fonctionne ici. En pratique aujourd’hui, cela signifie qu’une organisation demande à un modèle de chercher les problèmes, manuellement ou sous la forme d’une invocation d’agent déclenchée dans un pipeline, parfois via un fournisseur et parfois en pointant directement un modèle de pointe vers le dépôt.

Exécutez cinq fois la même revue de sécurité sur le même code : près de la moitié des problèmes détectés spontanément par le modèle n’apparaissent que dans une seule des cinq exécutions. C’est ce que montre Snyk VulnBench JS 1.0, mesuré sur 300 exécutions de la même revue.

Ces rapports ponctuels ne sont pas erronés, et VulnBench en documente de nombreux qui ressemblent à de véritables lacunes de couverture plutôt qu’à du bruit. Mais une seule exécution ne suffit pas pour prendre une décision. La confiance s’acquiert par la répétition, et c’est pourquoi il s’agit du premier point où le coût par problème devient un véritable poste budgétaire plutôt qu’une erreur d’arrondi.

À cette étape, ce qui change n’est pas la durée d’une analyse, mais ce qu’elle doit examiner. Tous les contrôles précédents sont incrémentaux. Une compétence se déclenche lorsque l’agent s’apprête à utiliser un modèle. Une analyse couvre le fichier qui vient d’être écrit, plutôt que les dizaines de fichiers modifiés au cours d’une session. Chacun de ces contrôles s’intègre à un travail qui était déjà en cours. L’analyse sémantique de la base de code assemblée ne le peut pas, car il n’y a rien à analyser tant que les éléments ne sont pas réunis. Elle s’exécute donc comme une étape distincte, et son coût s’ajoute à la boucle au lieu d’y être absorbé. Le temps déjà consacré à cette boucle correspondait au travail de l’agent, et non à une marge disponible pour attendre ; une analyse complète peut donc facilement en doubler la durée. Et cela suppose un résultat propre : tout ce qu’elle détecte doit être corrigé, puis l’analyse doit être relancée. Le coût se cumule donc au lieu de simplement s’additionner. C’est pour toutes ces raisons que cette étape intervient après le passage de l’agent.

Chacun de ces cycles s’appuie aussi davantage sur la suite de tests. L’invite a alors disparu, si bien que la couverture est la seule chose qui sépare un correctif de sécurité d’une fonctionnalité cassée, et chaque nouvelle exécution lui demande de tenir à nouveau. Dans la plupart des organisations, la couverture est loin d’atteindre le niveau nécessaire pour qu’un correctif puisse être déployé sans supervision ; une personne finit donc par l’examiner.

C’est exactement dans cette direction que Snyk fait évoluer l’avenir de l’AppSec agentique. Attendez-vous à en savoir plus à ce sujet dans un avenir proche.

Ce qui n’apparaît que sous une attaque (préproduction)

La dernière catégorie n’apparaît que lorsqu’un élément est en fonctionnement. Des chaînes d’exploitation en plusieurs étapes, des abus de workflows, une injection de prompt contre un agent déployé, des chemins d’exfiltration de données qui n’existent que parce que trois composants interagissent d’une certaine manière dans votre environnement.

Le contrôle repose sur des tests adversariaux : des tests d’intrusion et du red teaming IA contre une application réelle. Les types de failles recherchés sont connus, mais le travail est exploratoire. L’application est le point de départ et les limites ne sont pas fixées à l’avance ; ce qui émerge est donc tout ce que le système s’avère permettre.

C’est là que Evo Continuous Offensive Security intervient, et il est utile de préciser ce qui effectue le travail, car il ne s’agit pas d’un scanner auquel on aurait ajouté un modèle. Un agent de test d’intrusion orchestrateur exécute des sous-agents spécialisés contre une cible active. Un agent de validation distinct remet en question les résultats des autres et construit un exploit fonctionnel pour les prouver. Ce dernier point est essentiel, car les tests exploratoires pilotés par des modèles produisent des résultats plausibles en apparence, à moins que quelque chose ne les oblige à résister à la vérification. C’est pourquoi chaque résultat est livré sous la forme d’une preuve de concept exécutable plutôt que d’une hypothèse.

Trois de ces sous-agents — logique métier, contrôle des accès et autorisation, et chaînage d’exploits — travaillent sur les mêmes catégories sémantiques que celles dont l’étape précédente a besoin. La mise en produit de ces moteurs et de moteurs similaires au sein des workflows de l’étape précédente, à mesure que ces workflows se stabilisent, est déjà en cours.

Il peut s’exécuter en préproduction comme étape de validation avant une mise en production, ou immédiatement après une mise en production afin d’orienter les prochaines priorités. Historiquement, il s’agissait d’un exercice de conformité annuel ou semestriel. Les organisations l’exécutent désormais beaucoup plus souvent, ce qui est la bonne approche, car les adversaires ne suivent pas un calendrier d’audit.

Il n’y a rien à attaquer tant qu’un élément n’est pas en fonctionnement, ce qui explique précisément pourquoi cela ne peut pas avoir lieu plus tôt.

Ce que l’agent savait, et quand il pouvait agir

Tous les contrôles ci-dessus reposent sur les deux mêmes éléments : l’agent aurait-il pu recevoir cette information avant d’écrire le code, et la réponse arrive-t-elle alors qu’il détient encore le prompt ? Ces deux questions placent les quatre contrôles et expliquent pourquoi leur séquence n’est pas une question de préférence. Chaque contrôle se situe dans l’une des quatre cases ci-dessous.

Figure 4. Les quatre contrôles, dans l’ordre défini par les réponses aux deux questions.

Pourquoi c’est plus difficile en pratique

Le plan est simple. Le mettre en œuvre au sein d’une organisation réelle ne l’est pas, et les raisons ont très peu à voir avec la sécurité.

La plupart des organisations ne disposent pas encore d’un cycle de développement agentique établi. Les outils, les harnesses et l’architecture qu’elles standardisent sont encore en évolution, parfois d’un trimestre à l’autre. Le paysage des fournisseurs évolue tout aussi rapidement ; même lorsqu’un choix a été fait, il existe donc une réelle hésitation à s’engager dans quoi que ce soit qui ressemble à une décision irréversible. Tout cela se traduit par une responsabilité mal définie, car lorsque la forme du cycle de vie est encore mouvante, la question de savoir qui est responsable de quelle partie l’est aussi. Les failles d’autorisation et de logique n’appartiennent généralement à personne en particulier, jusqu’à ce qu’un incident les attribue à quelqu’un.

Rien de tout cela ne nécessite de repartir de zéro, et c’est le point important à retenir. Presque toutes les organisations disposent déjà d’une étape de sécurité avant déploiement, et cette étape joue un rôle réel. Ce n’est pas la chose à supprimer pendant que vous cherchez comment gérer le reste. Ces points d’insertion s’ajoutent à ce qui existe déjà et peuvent être adoptés un par un, dans l’ordre qui correspond à la maturité réelle de votre cycle de vie. Intégrer un scan déterministe dans la boucle ne nécessite pas d’avoir résolu la question de savoir qui est responsable des tests adversariaux.

Le deuxième point est souvent sous-estimé. Dans les boucles internes, un contrôle qui renvoie le travail à un humain a déjà échoué, tout comme celui qui produit une file de pull requests rédigées par l’IA que quelqu’un doit examiner. Tous deux transforment un contrôle de sécurité en une charge de travail pour quelqu’un d’autre, et c’est là que les contrôles finissent par être discrètement désactivés.

Plus on s’éloigne de ces boucles, plus il est difficile d’éviter l’intervention humaine. Dans la plupart des organisations, la couverture des tests est très loin du niveau auquel on pourrait faire confiance à un correctif autonome pour être déployé ; quelqu’un l’examine donc, et c’est l’état honnête des choses aujourd’hui, pas un échec des outils. Les harnesses deviennent plus performants pour exécuter la suite sans invite, et la couverture augmente également lorsque les agents écrivent les tests, mais personne ne devrait partir du principe que l’un ou l’autre est déjà arrivé à maturité. C’est une raison de plus pour détecter tout ce qui peut l’être tant que l’agent détient encore le prompt, car c’est le seul endroit où l’intervention humaine n’est pas nécessaire.

Le premier et le troisième point sont ce qui permet de commencer en toute sécurité alors que le terrain continue d’évoluer. Un contrôle que vous pouvez déployer en un après-midi, reconfigurer de manière centralisée ou supprimer entièrement est un contrôle que vous pouvez adopter avant même d’avoir défini l’apparence de votre cycle de vie. À l’heure actuelle, cette propriété vaut plus que n’importe quelle fonctionnalité individuelle.

Trusted Output Assurance se distribue lui-même via MDM et conserve sa configuration de manière centralisée ; modifier ce qui s’exécute ne signifie donc pas modifier les politiques Jamf ou Intune ni réécrire les scripts de déploiement. Continuous Offensive Security nécessite les URL de vos applications et un ensemble d’identifiants ; aucun chantier préalable ne doit donc être justifié avant qu’il ne renvoie quoi que ce soit. Aucun des deux ne vous engage dans une architecture que vous n’avez pas encore définie.

Prévention maintenant, remédiation ensuite

La prévention est résolue dans le sens qui compte. Les points d’intervention existent, les contrôles existent et l’on sait quel contrôle doit être utilisé à quel endroit. Mais sa mise en œuvre demande du travail, et l’(AI)SDLC continue d’évoluer sous nos yeux.

La remédiation est une autre histoire. Un scan déterministe intégré à la boucle vous empêche d’adopter un package dans une version connue comme vulnérable au moment où vous l’adoptez. Il ne fait rien pour le package adopté il y a huit mois (voire huit ans) qui a reçu un CVE la semaine dernière. Ce backlog s’accroît dans deux directions à la fois : des années de résultats accumulés qui n’ont jamais été corrigés, et un flux continu de nouvelles divulgations concernant du code déjà en production. Une bonne prévention ne le réduit pas, mais elle évite de l’aggraver.

Ce problème mérite une discussion à part entière. En attendant, la prévention est disponible dès maintenant, et la première étape est plus simple qu’il n’y paraît : choisissez le point de votre cycle de vie qui est le plus stable et ajoutez-y le contrôle approprié.