Un ingénieur sécurité a monté en 7 jours un serveur MCP qui met la pression à un agent IA sur les vulnérabilités

Un spécialiste de la sécurité informatique s'est construit un assistant IA légèrement paranoïaque : AppSecGate, un serveur MCP local qui lance des scanners, tient une base de findings et oblige l'agent à traiter les vulnérabilités au lieu de les balayer d'un revers de main. La première version a demandé 7 jours, environ 210 millions de tokens et à peu près 3000 roubles, soit environ 14 roubles le million de tokens. Le dernier passage sur OWASP Juice Shop a duré environ 50 minutes et coûté de l'ordre de 15 roubles. L'agent, basé sur deepseek-v4-flash, a traité 200 findings et en a corrigé 56, dont 8 critical et 45 high.

Pourquoi l'AppSec devient un goulot d'étranglement

Le SSDLC classique se déroule ainsi : le développeur écrit son code dans l'IDE, le code arrive dans Git, le CI/CD lance SAST, SCA et DAST, puis les rapports partent vers l'ASOC/ASPM, où ils sont dédupliqués et enrichis. Ensuite, un responsable sécurité trie les findings et crée les tâches dans le tracker. Le principal défaut de ce schéma : la vitesse de correction est imprévisible. Un scanner tombe en panne, aucune alternative n'existe pour une bibliothèque vulnérable, ou l'AppSec est en congé, et un correctif peut attendre très longtemps. Son principal atout : une répartition claire des responsabilités, et il est facile d'expliquer à l'entreprise pourquoi la sécurité doit être financée.

Les LLM mettent ce schéma sous pression. Les développeurs ont d'abord appuyé sur TAB, puis demandé à un agent d'écrire une méthode, et ils lui donnent maintenant en pâture un cahier des charges rédigé par le modèle lui-même à partir d'une tâche, elle aussi rédigée par un modèle. Le code devient plus abondant et plus embrouillé, le volume de triage augmente et le test manuel se complique. Ajoutez les vibe coders, qui montent leurs projets en solo et croient que le modèle ne confond pas dev et prod.

Si l'on se contente d'installer un agent dans chaque rôle, on obtient une longue boucle où tout est « clos » et où les tokens sont dépensés, sans que le processus soit pour autant optimal. Le dialogue direct entre agents est lui aussi risqué. L'auteur ironise : ils pourraient d'abord découvrir qu'il est plus rapide de s'entendre par prompt injection. La seule question est de savoir si le budget de tokens ne sera pas épuisé avant.

Moins d'agents, plus de structure

La variante systémique proposée par l'auteur est plus simple :

• TaskTracker sort du traitement des findings, car les agents échangent mieux des données structurées. Le tracker peut rester pour le suivi du temps et la comptabilisation des tokens.
• Dans le CI/CD, il reste un seul agent autonome, qui reçoit le contexte des findings depuis l'ASOC. Il n'est pas obligatoire : il peut être remplacé par un agent lancé par le responsable sécurité.
• L'ASOC/ASPM passe d'un système pour les humains à un système pour les agents.
• Le scan se décale vers la gauche (shift-left) : l'agent lance lui-même les scanners pendant l'écriture du code, comme un formateur ou des tests unitaires. Le push n'est pas bloqué, le problème est remonté à l'AppSec ou au Lead. Ne scanner que le diff économise des tokens, puisque l'agent travaille de toute façon sur ce fichier. Le triage local est enregistré sur le serveur central, ce qui permet de démontrer l'efficacité de l'approche à la direction.

Comment fonctionne AppSecGate

Le MVP est un serveur MCP local dans un Docker isolé, avec un ensemble de scanners et une base SQLite ; l'architecture laisse la porte ouverte à un serveur central. L'agent travaille via Cline : l'auteur a abandonné Continue pour cet outil et a écrit un fichier AGENTS.md. Voici les outils dont dispose l'agent :

• get_config — vérification de la configuration ;
• scan_project — lancement du scan et résultat agrégé ;
• query_findings_db — accès SQL à la base de findings (l'agent le préfère, on ne sait trop pourquoi, alors que des alternatives existent) ;
• get_fix_context_batch — contexte des détections pour la correction ;
• verify_fix_batch — vérification du correctif ou suppression du finding en tant que FALSE_POSITIVE.

À la demande « Vérifier la sécurité du projet » en mode planification, l'agent a suivi cette chaîne et conclu qu'il ne fallait rien corriger, car Juice Shop est vulnérable à dessein. Il a fallu lui expliquer qu'il s'agissait de tester les outils. Une fois passé en mode Act, il a commencé le triage, s'est régulièrement référé à la base et a fini par produire un rapport.

L'auteur a testé des modèles locaux avec un benchmark de sept variantes sur une seule RTX 4060 Ti 16GB. Aucun vainqueur net ne s'est dégagé, mais il en a tiré des conclusions.

Pour les équipes, l'enseignement pratique est le suivant. Une couche MCP structurée entre les scanners et l'agent fait de la sécurité une étape ordinaire du cycle de développement. Le coût d'un passage, 15 roubles sur un modèle cloud bon marché, est nettement inférieur à une heure de travail d'un ingénieur AppSec sur du triage de routine.

Les détails comptent aussi : un AGENTS.md avec des règles claires, la séparation entre Plan et Act, le marquage explicite FALSE_POSITIVE assorti d'une vérification. Cette combinaison ne remplacera pas l'AppSec.

La routine ira à l'agent, tandis que l'architecture sécurisée et la recherche de vulnérabilités logiques resteront aux humains. Effet secondaire : un outil prêt à l'emploi pour les vibe coders solo, qui ont besoin de TimeToMarket et ne veulent pas finir en illustration des échecs de l'IA dans l'actualité.