GitLab 18.10, passkeys sans mot de passe, Duo Agent et SAST, 2 nouveautés sécurité qui surprennent les équipes DevOps

GitLab 18.10 ajoute deux briques qui ciblent un point de friction récurrent dans les équipes logicielles: l’authentification et le bruit des outils de sécurité. La version met en avant la connexion sans mot de passe via passkeys et une capacité de détection des faux positifs dans l’analyse de code, portée par la GitLab Duo Agent Platform. L’objectif affiché est double: réduire l’exposition aux attaques liées aux identifiants et rendre les résultats de sécurité plus actionnables pour les développeurs.

Le contexte est connu. Les mots de passe restent une cause majeure d’incidents, entre réutilisation, phishing et compromission de bases d’identifiants. Dans le même temps, les pipelines DevSecOps se heurtent à un autre phénomène: des alertes d’outils d’analyse statique (SAST) qui s’accumulent sans correspondre à des failles exploitables. Quand le volume d’alertes augmente, la capacité à trier diminue, et la sécurité se transforme en charge opérationnelle.

GitLab choisit donc une approche pragmatique: supprimer une partie de la surface d’attaque en remplaçant le mot de passe par un mécanisme cryptographique, et diminuer la fatigue liée aux alertes en identifiant des vulnérabilités SAST signalées à tort. Cette combinaison vise un même résultat, une chaîne de livraison plus fiable, avec moins de temps perdu sur des tâches à faible valeur.

Les détails fonctionnels et les conditions d’activation dépendent des environnements (GitLab. com, instances auto-hébergées, politiques d’entreprise), mais la direction prise est claire: renforcer l’authentification et améliorer la qualité des signaux de sécurité au plus près du cycle de développement.

Les passkeys dans GitLab 18.10, une connexion sans mot de passe basée sur FIDO2

L’ajout des passkeys dans GitLab 18.10 s’inscrit dans le mouvement de fond porté par l’écosystème FIDO Alliance et les grandes plateformes. Le principe n’est pas un mot de passe amélioré, mais un couple de clés cryptographiques: une clé privée conservée sur l’appareil de l’utilisateur (ou dans un gestionnaire compatible), et une clé publique enregistrée côté service. La connexion repose sur une preuve cryptographique, souvent déverrouillée par biométrie ou code local, sans transmission de secret réutilisable.

Sur le plan de la sécurité, l’intérêt est immédiat face au phishing. Même si un utilisateur saisit une information sur un site frauduleux, le mécanisme de passkey est lié au domaine et ne produit pas une preuve valide pour un autre site. Cela réduit la valeur des campagnes d’hameçonnage, qui ciblent historiquement les comptes à privilèges et les accès aux dépôts de code.

Dans un contexte DevSecOps, le compte GitLab est un point central: accès aux dépôts, aux variables CI/CD, aux jetons, aux environnements de déploiement. La compromission d’un compte peut ouvrir la voie à l’injection de code malveillant, au détournement de pipeline ou à l’exfiltration de secrets. En remplaçant le mot de passe par une authentification basée sur une clé privée non exportée, GitLab réduit un risque structurel, celui de l’identifiant qui circule, se réutilise, se vole ou se devine.

Il reste un enjeu de déploiement. Les organisations doivent arbitrer entre adoption rapide et exigences de parc: compatibilité des navigateurs, gestion des appareils, politiques de récupération de compte, et coexistence avec des méthodes existantes comme le SSO. Dans les entreprises, l’authentification est rarement un sujet purement technique, elle touche à la gouvernance et à la conformité. Le choix de GitLab d’intégrer les passkeys en natif vise à rendre cette transition plus accessible, en limitant les contournements et les exceptions.

Cette évolution intervient dans un marché où les attaques sur la chaîne logicielle se multiplient. D’après le rapport Verizon DBIR 2024, l’usage d’identifiants volés reste l’un des vecteurs les plus fréquents dans les intrusions. Le passage aux passkeys ne supprime pas tous les risques, mais il retire une classe d’attaques particulièrement rentable pour les adversaires, en réduisant la dépendance aux secrets partagés.

GitLab Duo Agent Platform vise les faux positifs SAST pour réduire le bruit dans les pipelines

Le second axe de GitLab 18.10 touche à un problème moins visible du grand public, mais quotidien pour les équipes: les alertes de SAST qui ne correspondent pas à une vulnérabilité exploitable. Les analyses statiques sont utiles pour détecter des motifs à risque, mais elles produisent aussi des faux positifs. Quand ces alertes s’accumulent, elles saturent les tableaux de bord, ralentissent les revues et finissent par être ignorées.

GitLab met en avant la capacité à reconnaître des faux positifs SAST via la GitLab Duo Agent Platform. L’idée est de mieux qualifier les résultats, en distinguant ce qui relève d’un signal pertinent de ce qui est une alerte erronée. Pour les équipes, l’enjeu n’est pas de réduire artificiellement le nombre d’alertes, mais d’augmenter la précision, afin que les correctifs portent sur des risques réels.

La question du bruit est aussi une question de coût. Chaque alerte déclenche un cycle: triage, reproduction, discussion, priorisation, parfois création de ticket, et revue. Si l’alerte est fausse, ce temps est perdu. Les études sectorielles convergent sur ce point: la dette d’alertes de sécurité devient vite une dette opérationnelle. Selon le rapport State of DevOps 2024 (DORA, Google Cloud), les organisations performantes cherchent à intégrer la sécurité sans dégrader le flux de livraison. Une sécurité qui génère trop de friction finit par être contournée.

L’usage d’une plateforme d’agents, associée à des capacités d’assistance, suggère une évolution des outils: passer d’un scanner qui liste des problèmes à un système qui aide à qualifier et contextualiser. Pour un responsable sécurité applicative, la valeur se mesure à la réduction du temps de triage et à l’amélioration du taux de correction des vulnérabilités à fort impact.

Cette orientation pose aussi une exigence de transparence. Toute mécanique qui classe des alertes en faux positifs doit être auditable: quel critère, quel niveau de confiance, quelle traçabilité, quelle possibilité de revenir en arrière. Dans les environnements régulés, la capacité à justifier pourquoi une alerte a été écartée compte autant que la détection elle-même. GitLab joue ici sur un terrain où la confiance se gagne par la qualité des explications et la gouvernance des décisions.

Moins de phishing et moins de triage, un gain de productivité mesurable pour les équipes DevSecOps

Mettre côte à côte passkeys et réduction des faux positifs SAST n’a rien d’anecdotique. Les deux sujets touchent au temps humain, la ressource la plus rare dans les équipes de développement. D’un côté, les incidents liés aux identifiants entraînent des coûts lourds: réinitialisations, rotations de secrets, investigations, parfois arrêt de service. De l’autre, le triage des alertes consomme une part significative du temps des ingénieurs sécurité et des développeurs seniors.

La connexion par passkey vise à diminuer les événements de sécurité liés au vol d’identifiants. Dans un environnement GitLab, un compte compromis n’est pas seulement un risque d’accès au code, c’est aussi un risque d’accès aux pipelines et à l’infrastructure via les intégrations. Les passkeys réduisent l’attaque par réutilisation de mots de passe et limitent l’efficacité du phishing, ce qui réduit le volume d’incidents de type account takeover.

La réduction des faux positifs SAST vise un autre point de douleur: la priorisation. Les équipes ont besoin d’un signal clair pour savoir quoi corriger en premier. Quand le scanner se trompe trop souvent, la confiance s’érode et la sécurité perd sa place dans le cycle de livraison. Le bénéfice attendu est une meilleure concentration sur les failles réelles, avec un effet direct sur le délai de correction.

Des indicateurs permettent de mesurer cet impact. Côté authentification: taux d’adoption des passkeys, diminution des réinitialisations de mots de passe, baisse des tentatives de phishing réussies. Côté SAST: réduction du volume d’alertes requalifiées, baisse du temps moyen de triage, hausse du taux de correction des vulnérabilités critiques. Ces métriques sont celles que suivent déjà les organisations matures, qui cherchent à piloter la sécurité comme une discipline d’ingénierie.

Il existe aussi un effet culturel. Les développeurs acceptent plus facilement des contrôles de sécurité quand ils sont perçus comme fiables et peu intrusifs. Une authentification plus simple et une sécurité qui génère moins de bruit renforcent l’adhésion. À l’inverse, une sécurité vécue comme punitive ou chronophage se heurte à des stratégies d’évitement, ce qui fragilise l’ensemble.

GitLab face à Microsoft, Google et Apple, la standardisation des passkeys accélère

En intégrant les passkeys, GitLab s’aligne sur une trajectoire déjà engagée par les grandes plateformes. Microsoft pousse les connexions sans mot de passe sur ses comptes, Google a généralisé les passkeys à grande échelle, Apple les a intégrées au cur de son écosystème. Cette standardisation a un effet d’entraînement: plus les utilisateurs disposent de passkeys dans leur quotidien, plus ils s’attendent à retrouver ce mode d’accès dans les outils professionnels.

Pour GitLab, l’enjeu est aussi concurrentiel. Les plateformes de développement et de gestion de code se différencient de plus en plus par la sécurité intégrée: gestion des identités, politiques d’accès, scans, gouvernance. L’authentification est un élément de base, mais elle devient un marqueur de maturité, surtout quand les entreprises cherchent à réduire la dépendance aux mots de passe.

La question se déplace alors vers l’intégration avec les politiques d’entreprise: SSO, MFA, gestion des appareils, exigences de conformité. Les passkeys peuvent coexister avec ces dispositifs, mais leur déploiement nécessite des règles de récupération et de renouvellement. Une passkey perdue ou un appareil remplacé ne doit pas conduire à une dérive de support ou à des exceptions permanentes. Les organisations qui réussissent la transition sont celles qui traitent le sujet comme un projet d’identité, pas comme une simple option d’interface.

Sur le volet SAST, la logique est similaire: le marché attend des outils capables de réduire le bruit et d’aider à la décision. Les éditeurs de sécurité applicative multiplient les approches de corrélation, de contextualisation et d’assistance. GitLab, avec la GitLab Duo Agent Platform, se positionne sur cette promesse: faire gagner du temps en améliorant la qualité des résultats.

Le point d’attention, pour les entreprises, reste la maîtrise. Une plateforme qui reconnaît des faux positifs doit être évaluée sur des dépôts réels, avec des langages, des frameworks et des patterns internes. La performance ne se juge pas sur une démo, mais sur la capacité à réduire le bruit sans masquer des failles. Les équipes sécurité demanderont des preuves, des journaux, et une gouvernance claire, surtout dans les secteurs sensibles.