Au cours des neuf derniers mois, le volume de nos PR a été multiplié par 5. Les outils de sécurité fondés sur l'analyse statique ou une attribution rigide du code restent utiles, mais ne suffisent pas à cette échelle. Nous nous sommes adaptés en utilisant Cursor Automations, ce qui nous a permis de rapidement mettre en place une flotte d'agents de sécurité qui identifient et corrigent en continu les vulnérabilités dans notre base de code.

Aujourd'hui, nous lançons quatre nouveaux modèles d'automatisation qui reprennent exactement les architectures des agents de sécurité que nous avons trouvés les plus utiles. D'autres équipes de sécurité peuvent personnaliser ces modèles pour créer des agents qui résolvent automatiquement un large éventail de problèmes de sécurité.

#L’architecture des automatisations

Pour être utiles à la sécurité, les agents ont besoin de deux fonctionnalités, toutes deux fournies par Cursor Automations.

La première consiste en des intégrations prêtes à l’emploi pour recevoir des webhooks, répondre aux PR GitHub et surveiller les changements dans la base de code. Cela permet aux agents qui opèrent en arrière-plan de savoir quand se manifester et passer à l’action.

La seconde est un environnement d’exécution riche pour les agents. Les automatisations s’appuient sur des Agents Cloud, ce qui leur donne accès à tous les outils, toutes les compétences et toute l’observabilité dont disposent les Agents Cloud.

Pour rendre les automatisations plus efficaces pour les cas d’usage propres à la sécurité, nous avons développé un outil MCP de sécurité et l’avons déployé sous la forme d’une fonction Lambda serverless, disponible juste à temps lorsque nécessaire, et inactive le reste du temps.

Le MCP, dont le code de référence est disponible ici, remplit trois fonctions :

1. Données persistantes. L’agent utilise le MCP pour stocker des données, afin que nous puissions suivre et mesurer l’impact sur la sécurité au fil du temps. Nous utilisons ces données pour affiner en continu quand et comment nous déclenchons les automatisations.

2. Déduplication. Nous exécutons plusieurs agents de revue sur chaque modification et, comme leurs résultats sont générés par un LLM, différents agents peuvent finir par utiliser des termes différents pour décrire le même problème sous-jacent. Pour éviter de dupliquer le travail, le MCP permet à l’agent de déployer un classificateur alimenté par Gemini Flash 2.5 qui détermine quand deux résultats sémantiquement distincts décrivent en réalité le même problème.

3. Sortie cohérente. Les agents signalent chaque vulnérabilité qu’ils trouvent via le MCP, qui envoie des messages Slack dans un format cohérent et gère les actions ultérieures, comme ignorer ou mettre en attente un résultat.

Une fois cette base en place, les quatre automatisations de sécurité détaillées ci-dessous ajoutent chacune leurs propres workflows et leur propre logique de déclenchement. Nous utilisons Terraform pour garantir que toutes les modifications apportées aux outils de sécurité passent par un processus standard de revue et de déploiement.

#Agentic Security Review

En interne, nous utilisions déjà Bugbot pour examiner les PR du point de vue de la qualité du code et des problèmes généraux, y compris certains résultats de sécurité. Mais un outil de revue généraliste n'est pas idéal pour la sécurité, car il ne peut pas être adapté par prompt à notre modèle de menace spécifique, et parce que nous avions besoin de pouvoir bloquer la CI spécifiquement sur les résultats de sécurité, sans bloquer sur chaque problème général de qualité du code.

Partant de ce constat, nous avons mis au point une automatisation dédiée que nous appelons Agentic Security Review. Au départ, nous l'avons configurée pour transmettre ses résultats à un canal Slack privé surveillé par notre équipe de sécurité.

Une fois que nous avons été convaincus qu'il identifiait de vrais problèmes, nous avons activé les commentaires sur les PR, puis mis en place un contrôle bloquant. Au cours des deux derniers mois, Agentic Security Review s’est exécuté sur des milliers de PR et a empêché des centaines de problèmes d'atteindre la production.

#Vuln Hunter

Après le succès d’Agentic Security Review sur du nouveau code, nous avons mis des agents sur la base de code existante. Vuln Hunter est une automatisation qui divise le code en segments logiques et recherche des vulnérabilités dans chacun d’eux. Notre équipe fait le tri des résultats et les corrige généralement, souvent en utilisant @Cursor depuis Slack pour générer des PR.

#Anybump

La mise à jour corrective des dépendances est tellement chronophage que la plupart des équipes de sécurité finissent par abandonner et la confient aux équipes d’ingénierie, où elle s’accumule dans les backlogs. Nous avons créé une automatisation appelée Anybump qui automatise presque entièrement ce processus.

Anybump s’exécute avec une analyse d’atteignabilité pour limiter les vulnérabilités à celles qui ont un impact réel, puis parcourt les chemins de code pertinents, exécute des tests, vérifie qu’aucune régression n’est introduite et ouvre une PR une fois les tests réussis. Une fois la PR fusionnée, le pipeline de déploiement canari de Cursor fournit un dernier garde-fou avant que quoi que ce soit n’atteigne la production.

#Invariant Sentinel

Invariant Sentinel s’exécute chaque jour pour surveiller toute dérive par rapport à un ensemble de propriétés de sécurité et de conformité. Il divise le dépôt en segments logiques et lance des sous-agents pour vérifier le code par rapport à une liste d’invariants.

Après l’analyse, l’agent compare l’état actuel aux exécutions précédentes à l’aide de la fonctionnalité de mémoire des automatisations. S’il repère une dérive, il effectue une nouvelle validation pour en garantir l’exactitude, puis met à jour sa mémoire et envoie un rapport Slack à l’équipe de sécurité avec une description du changement et des emplacements précis dans le code à l’appui.

Comme cette automatisation s’exécute dans un environnement de développement complet, l’agent peut écrire et exécuter du code pour valider ses propres hypothèses, en complément des tests fonctionnels, unitaires et d’intégration traditionnels.

#D’autres automatisations à venir

La sécurité se prête à de nombreuses automatisations, et ces quatre exemples ne sont qu’un début du travail que nous prévoyons de mener. Nous les étendons déjà pour couvrir le traitement des rapports de vulnérabilité, le suivi de la conformité en matière de confidentialité, le tri des alertes d’astreinte et le provisionnement des accès.

Dans chaque cas, les agents nous apportent un niveau de couverture et de cohérence qu’il nous serait impossible d’atteindre manuellement.