Domaine de recherche · Développement logiciel Agentic
Quand des agents de codage coécrivent le code : sécuriser code et chaîne d'outils de façon vérifiable
Les agents de codage écrivent du code, exécutent des commandes dans le terminal et intègrent des serveurs MCP et des skills. La surface d'attaque s'étend ainsi du code généré aux extensions et aux pipelines, en passant par le harness. Nous étudions où l'analyse de code assistée par IA aide de manière avérée et où elle devient elle-même vulnérable, et traduisons ces résultats en un Secure SDLC dans lequel le modèle de langage conseille, sans piloter.
- Agents de codage & harness
- Slopsquatting
- AI-SAST
- Validation d'exploitabilité
- DAST avec LLM encadré
- Secure SDLC
- Sécurité des pipelines CI/CD
- Deep Dives
- 8
- Livres blancs
- 5
- Solutions
- 2
De l'assistant à l'agent : la chaîne d'outils devient surface d'attaque
L'IA produit aujourd'hui une grande partie du nouveau code – Google indique 75 % –, et ce code introduit mesurablement plus souvent des vulnérabilités : selon Veracode, 45 % des échantillons générés par IA échouent au test de sécurité. Parallèlement, l'assistant qui propose devient un agent qui installe dans le terminal, appelle des serveurs MCP et charge des skills. Ce faisant, les modèles de langage inventent aussi des noms de paquets qui n'existent pas et que des attaquants peuvent enregistrer ; depuis 2025, on parle de slopsquatting.
Le 29 octobre 2026 a montré à quel point la chaîne d'outils est vulnérable : la marketplace de l'éditeur de code Cursor a diffusé une version manipulée de l'extension Claude Code dotée d'une porte dérobée SSH – sous l'identifiant authentique anthropic.claude-code. Notre analyse du 31 octobre 2026 indique les étapes de vérification et les mesures à prendre. Les extensions s'exécutent avec les droits de l'utilisateur connecté et accèdent au code source, aux identifiants et aux terminaux ; cette chaîne d'approvisionnement sur les postes de développement est rarement contrôlée aussi strictement que les serveurs ou les pipelines de build.
Côté analyse, la découverte se banalise : Google Big Sleep a signalé vingt zero-days réels en 2025, et les finalistes de la DARPA AI Cyber Challenge ont trouvé en août 2025, de manière entièrement autonome, 86 % des vulnérabilités injectées. Sur des zero-days réellement inédits, même les modèles de pointe échouent encore, et une classification LLM naïve sans contexte fait à peine mieux qu'un pile ou face. L'IA complète les couches de contrôle, elle ne les remplace pas – c'est selon ce principe que fonctionnent VamiAppSec et VamiDAST.
Les questions ouvertes du terrain
- 01
Comment vérifier du code écrit par des assistants IA et des agents de codage ?
Notre approche
Comme du code humain – avec revue, SAST, tests et vérification des dépendances –, mais en se concentrant sur les classes où le code d'assistant échoue de manière prévisible : autorisation, isolation des locataires, gestion des erreurs. Les code owners reçoivent pour cela un guide. Les risques liés aux agents et aux prompts dans le dépôt sont vérifiés en même temps, par exemple des fichiers de règles contenant des caractères invisibles que les humains ne voient pas en revue, mais que le modèle suit.
- 02
Un modèle de langage peut-il remplacer le SAST à base de règles ?
Notre approche
Non. Le SAST à base de règles reste l'hygiène de base reproductible sur chaque commit et la seule couche apte à servir de gate dans le build. Nous utilisons l'AI-SAST avec raisonnement sémantique de manière ciblée sur les dépôts à forte valeur, par exemple contre l'autorisation cassée et les erreurs de logique métier. Les findings issus de l'IA reçoivent une piste d'audit et des contrôles humains par échantillonnage, car les jugements des LLM varient d'une exécution à l'autre.
- 03
Comment un constat dans le code devient-il une priorité fiable ?
Notre approche
Par une chaîne de preuve : une règle ou un modèle signale un endroit du code, puis l'atteignabilité, l'exposition réelle et l'exploitabilité sont vérifiées sur le système en fonctionnement. Ce qui se trouve derrière le chemin détermine l'ordre de correction. C'est pourquoi nous convenons de SLA selon l'exploitabilité plutôt que selon le seul CVSS, et transmettons les chemins confirmés avec les étapes de reproduction aux code owners.
- 04
Quelle part de modèle de langage un test de sécurité dynamique supporte-t-il ?
Notre approche
Aussi peu que nécessaire, et jamais aux commandes. Dans VamiDAST, un moteur déterministe pilote chaque scan ; un LLM ne conseille qu'en exactement trois points délimités, et sans LLM, les détecteurs déterministes continuent de fonctionner. Chaque résultat est étayé par un payload et une preuve tirée de la réponse ; les systèmes de production ne sont testés qu'en mode passif ou sûr, et uniquement avec autorisation.
Ce que nous retenons
- 01
C'est le harness qui est attaqué, pas le modèle
Un agent de codage se compose d'un modèle et d'un harness, des fichiers de règles aux skills, aux secrets et au réseau, en passant par le terminal et les serveurs MCP. Les attaques documentées visent presque toujours ce harness ; la série de recherches IDEsaster a mis au jour plus de 30 vulnérabilités, dont 24 CVE, dans des IDE IA. Là où les éditeurs ont apporté des corrections, ils ne l'ont pas fait sur le modèle, mais dans le harness.
- 02
Compromettre le build, c'est atteindre chaque artefact livré
Les pipelines CI/CD concentrent des autorisations sur les dépôts, les registres de paquets et les environnements cloud. Avec la Poisoned Pipeline Execution, un accès au système de gestion du code source suffit pour manipuler le build. Sont efficaces : des runners isolés sans secrets pour le code non vérifié, des configurations CI issues de branches protégées et des identifiants OIDC à courte durée de vie plutôt que des secrets statiques.
Source: Sécurité des pipelines CI/CD
- 03
Le triage par LLM a fait ses preuves – mais l'analyste IA devient lui-même une cible
Placé derrière un scanner déterministe, un filtre LLM réduit les fausses alertes de façon cohérente : de 88,6 % sur l'OWASP Benchmark, pour 3,1 % de perte de rappel. Dans le même temps, le modèle traite les commentaires, README et issues comme des entrées : des commentaires adversariaux trompent les détecteurs LLM dans plus de 90 % des cas. Qui utilise l'IA dans l'analyse de code en fait donc elle-même une surface d'attaque.
Source: AI SAST
- 04
Le moment de restitution des résultats détermine l'effet du SAST
Chez Meta, le taux de correction des scans batch nocturnes était proche de zéro. Lorsque la même analyse est passée sous forme de commentaire dans la revue de code du diff, il est monté à plus de 70 % – avec le même moteur et le même taux de fausses alertes. Google n'admet en revue que les analyses dont le taux effectif de fausses alertes reste inférieur à 10 %. Les résultats ont un effet là où les développeurs travaillent de toute façon.
Source: SAST
Notre démarche
Nous séparons rigoureusement ce qui est vérifiable de manière déterministe, là où un modèle de langage conseille et là où des humains décident – du harness de l'agent de codage à l'application en fonctionnement, en passant par la pull request.
Analyse du harness des agents de codage
Recenser les fichiers de règles, entrées, terminal, serveurs MCP, skills, gestionnaires de paquets, secrets, dépôt et réseau comme relations de confiance, et les sécuriser hors du modèle.
Trois couches d'analyse de code
SAST à base de règles sur chaque commit, AI-SAST avec raisonnement sémantique sur les dépôts à forte valeur, analyse par modèles de pointe, fondée sur les risques et périodique.
Validation d'exploitabilité
Du finding à l'exploitabilité, en passant par l'atteignabilité et l'exposition : les constats sont confirmés sur le système en fonctionnement avant de fixer les priorités.
DAST avec un LLM étroitement encadré
VamiDAST : moteur déterministe, un LLM conseille en exactement trois points délimités ; tests authentifiés, BOLA/IDOR avec une seconde identité, chaque résultat étayé par une preuve tirée de la réponse.
Durcissement des pipelines
L'OWASP Top 10 CI/CD Security Risks comme grille d'audit : runners isolés sans secrets pour le code non vérifié, identifiants OIDC à courte durée de vie, artefacts signés avec provenance selon SLSA.
Standards et Security Champions
OWASP ASVS 5.0, CWE Top 25 et NIST SSDF comme référence, OWASP SAMM pour le niveau de maturité ; les Security Champions ancrent les connaissances en sécurité dans chaque équipe de développement.
Pour démarrer
- 1Inventorier la chaîne d'outilsRecenser les agents de codage, extensions, serveurs MCP, sources de paquets et pipelines, et classer les dépôts selon leur exposition et leur classe de données.
- 2Définir les couches et les gatesDéterminer pour chaque dépôt quelle analyse s'exécute à quelle cadence ; des quality gates dans GitLab, GitHub ou Azure DevOps bloquent les résultats critiques.
- 3Étayer et prouver les constatsConfirmer l'exploitabilité sur le système, transmettre les corrections aux code owners et produire, pour chaque release, des preuves pour le CRA, NIS2 et les audits clients.
Deep Dives, livres blancs et analyses
Deep Dives 8
Livres blancs 5
Slopsquatting & Coding-Agenten für CISOs — sécuriser la chaîne d’approvisionnement logicielle IA
La sécurité assistée par IA dans le pipeline CI/CD
CI/CD Pipeline Security : comment les attaquants prennent le contrôle de votre pipeline — et comment le reprendre
OWASP Top 10 CI/CD Security Risks — guide pratique avec crosswalk de conformité
Secure Coding à l'ère de l'IA : le CWE Top 25 (2025) et le Secure-by-DesignDu domaine à la mise en œuvre
Domaines de recherche connexes
Des agents de codage dans l'équipe – la chaîne d'outils est-elle sécurisée ?
Nous examinons les droits des agents, les extensions, les gates de pipeline et votre analyse de code, et vous montrons où la vérification assistée par IA offre chez vous le plus grand levier – avec des preuves traçables.