GitLab Duo Security Review : l'IA traque les failles logiques dans vos MR

Le 16 juillet 2026, GitLab a annoncé la disponibilité en beta publique de Security Review Flow, une nouvelle capacité de GitLab Duo Agent Platform. Son objectif : analyser le contexte complet d'une merge request pour repérer les failles de logique métier, un type de vulnérabilité que les scanners de sécurité automatisés classiques ne voient tout simplement pas.

Concrètement, cet agent ne cherche pas un motif connu dans votre code. Il raisonne sur l'intention derrière chaque changement, comme le ferait un ingénieur sécurité en revue de code. On regarde ce que ça change pour vos merge requests, comment l'activer, et ce que ça implique si vous gérez la sécurité applicative d'une équipe ou d'une PME française.

Pourquoi les scanners classiques ratent ces failles

Un scanner SAST ou un outil d'analyse de dépendances excelle sur les vulnérabilités qui suivent un motif reconnaissable : une entrée SQL non filtrée, un secret codé en dur, une désérialisation non sécurisée. Ces failles se voient dans la syntaxe.

Le problème, c'est que les failles les plus coûteuses en production ressemblent souvent à du code parfaitement correct, ligne par ligne. Elles violent un contexte que le code lui-même ne contient pas : votre modèle d'autorisation, la sensibilité de vos données, l'ordre attendu de vos workflows. GitLab cite trois familles concernées :

• Accès et autorisation. Savoir si un utilisateur peut lire ou modifier une ressource dépend de votre modèle métier, pas d'une construction du langage. La faille de type BOLA (accéder aux données d'un autre utilisateur en changeant un identifiant) occupe la première place de l'OWASP API Security Top 10 depuis 2019.
• Exposition de données. Sérialiser un objet et le renvoyer est du code ordinaire et correct. Savoir s'il fuite dépend de quels champs sont sensibles et de qui les reçoit, des faits liés à votre domaine métier, pas à votre syntaxe.
• Contrôle de flux et workflow. Les erreurs de logique métier et les race conditions surviennent quand des opérations valides s'exécutent dans le mauvais ordre, se répètent de façon inattendue, ou sont manipulées. Exemple donné par GitLab : un checkout accessible sans paiement, un état ré-entré sous une race condition, un paramètre trafiqué pour changer un prix.

Jusqu'ici, détecter ces failles imposait une revue de sécurité manuelle, difficile à faire tenir à l'échelle de chaque MR, ou des tests d'intrusion et du bug bounty, qui arrivent trop tard dans le cycle. D'où un écart croissant entre la vitesse de développement et la capacité à y appliquer une expertise sécurité.

Comment fonctionne Security Review Flow

Le principe : vous demandez une revue à Duo Security Review exactement comme vous le feriez avec un collègue. L'agent analyse le diff en contexte : les fichiers d'origine, les lignes modifiées, la discussion de la MR, et le code associé. Son raisonnement est optimisé pour la précision, et une passe de validation indépendante examine chaque trouvaille pour filtrer les faux positifs probables.

Les résultats apparaissent sous forme de threads directement sur les lignes concernées, accompagnés d'un résumé dans une note interne. Sur les projets publics, les détails restent confinés à la note interne pour ne pas exposer publiquement une faille de sécurité.

Chaque trouvaille arrive avec un contexte exploitable :

• Un type de vulnérabilité, avec une référence CWE.
• Une sévérité : critique, élevée, moyenne ou faible.
• Un tier : Tier 1 (exploitable), Tier 2 (faille logique) ou Tier 3 (problème de conception).
• Une explication en langage clair.
• Une correction suggérée, quand elle est disponible.

La sévérité détermine l'état donné à la revue : une trouvaille critique ou élevée bascule la MR en « Demande de changements », une trouvaille moyenne ou faible reste en simple commentaire. Point important à retenir : le flow n'approuve jamais une MR, même quand il ne trouve rien à signaler. La décision finale reste toujours humaine.

Vous pouvez ensuite mentionner le compte de service Duo Security Review de votre organisation dans un fil de discussion pour poser une question, discuter d'une remédiation ou contester une trouvaille. Chaque finding se résout de trois façons : appliquer le correctif suggéré comme une suggestion MR classique, le rejeter comme faux positif, ou accepter le risque. Après avoir committé vos correctifs, il suffit de redemander une revue pour vérifier ce qui a changé.

Disponibilité et coût

Security Review Flow est en beta publique pour les clients GitLab Ultimate, disponible sur GitLab.com, GitLab Self-Managed et GitLab Dedicated. Si vous êtes déjà abonné Ultimate, il suffit d'activer Duo Agent Platform et d'utiliser les crédits GitLab inclus dans votre abonnement. Sinon, un essai gratuit de GitLab Duo Agent Platform donne accès à la fonctionnalité.

Le coût varie selon la complexité du diff analysé et le modèle sélectionné. GitLab recommande explicitement de tester l'outil sur quelques MR avant de le déployer largement, et prévient que la tarification pourra évoluer à la disponibilité générale.

Notre lecture chez CZSyn

Ce que GitLab propose ici comble un angle mort réel. Sur les projets que nous accompagnons, la majorité des incidents de sécurité qui arrivent en production ne viennent pas d'une injection SQL oubliée : ils viennent d'un contrôle d'autorisation mal placé, d'un endpoint qui expose un champ qu'il ne devrait pas, ou d'un enchaînement d'actions que personne n'avait anticipé. Ce sont exactement les failles qu'un scanner ne peut pas voir, parce qu'elles dépendent de la connaissance de votre métier, pas de la syntaxe de votre code.

Pour une PME française qui n'a pas les moyens d'avoir un ingénieur sécurité dédié en revue de chaque MR, un outil qui raisonne sur l'intention du code et qui ne remplace pas le regard humain (il ne peut jamais approuver seul, rappelons-le) représente un filet de sécurité supplémentaire réel, pas un gadget marketing. Le fait que ce soit intégré directement au flux de revue existant, plutôt qu'un outil à part qu'il faut encore apprendre à faire vivre, compte beaucoup dans l'adoption réelle sur le terrain.

Notre réserve porte sur le coût, volontairement flou à ce stade de la beta, et sur la nécessité de rester sur GitLab Ultimate pour y accéder, ce qui exclut de fait les équipes sur des formules moins complètes. Si vous évaluez cet outil, notre conseil : testez-le d'abord sur des MR à fort enjeu métier (paiement, gestion des droits, données personnelles), là où une faille de logique coûte le plus cher à corriger une fois en production.

Sources primaires

• GitLab, « GitLab Duo Security Review spots logic flaws scanners miss », 16 juillet 2026.
• Page produit officielle, GitLab Duo.
• Documentation officielle, docs.gitlab.com.