Sécuriser l'usine logicielle à la vitesse machine

J'ai rejoint GitLab à une période où la manière dont les équipes développent et sécurisent leurs logiciels évolue à toute vitesse. Bill Staples, PDG de GitLab, a récemment dressé ce constat dans L'ère de l'abondance du code. Lorsque le code n'est plus le goulot d'étranglement, la confiance se raréfie, et cette limite se manifeste d'abord en production.

En tant que responsable de la sécurité des systèmes d'information (RSSI), je suis convaincu que le développement logiciel agentique est digne de confiance uniquement lorsque la sécurité, la gouvernance et les garde-fous s'inscrivent dans le chemin de la planification à la production. Les dirigeants doivent connaître en permanence la surface d'attaque, limiter l'exécution et refermer la boucle entre la vulnérabilité et la correction vérifiée, à la vitesse machine. Plutôt que le nombre de scans, de tickets ou de revues, l'indicateur essentiel est le temps écoulé entre la détection et la correction vérifiée.

Cet indicateur gagne en pertinence à mesure que les paramètres économiques des attaques changent. Les risques eux-mêmes sont connus : un serveur ouvert, un identifiant avec une portée trop large ou un chemin de déploiement exposé. Les modèles d'IA accélèrent la détection de ces conditions et diminuent le coût associé aux connexions entre ces conditions et à leur exploitation. Ce scénario est plus préoccupant qu'une nouvelle vulnérabilité zero-day, car l'exposition existait déjà dans notre environnement : sa difficulté de détection faisait partie de notre protection.

Anthropic et OpenAI ont tous deux décrit publiquement ce changement, tout comme chaque équipe de sécurité à laquelle j'ai parlé cette année, quel que soit le secteur : les modèles avancés et les systèmes agentiques compriment le temps et le coût nécessaires pour découvrir et exploiter les failles. Les modèles à poids ouverts rattrapent rapidement les systèmes de sécurité les plus performants disponibles aujourd'hui, ce qui signifie que des capacités jusqu'ici réservées à un petit nombre de laboratoires vont devenir accessibles à un ensemble bien plus large d'acteurs malveillants.

Je constate cette accélération au sein même de GitLab. Nous avons publié 317 vulnérabilités ou expositions communes (CVE) depuis le début de 2026, contre 181 sur l'ensemble de 2025 et 170 en 2024. Notre programme de bug bounty a reçu un peu plus de 3 600 signalements au cours des 90 derniers jours, contre 1 440 sur l'ensemble de l'année 2024.

Une évolution similaire à l'échelle du secteur

GitLab n'est pas l'exception. En avril, le National Institute of Standards and Technology (NIST) a cessé d'enrichir la plupart des CVE et a reconnu qu'une année record en volume ne suffisait toujours pas. Cette année, le Verizon Data Breach Investigations Report a placé l'exploitation des vulnérabilités devant l'usurpation d'identifiants comme premier vecteur d'accès initial, une première en 19 éditions, le délai médian de résolution passant de 32 à 43 jours. Le Forum of Incident Response and Security Teams (FIRST) a fait le même constat cet été.

Les avis publiés et les signalements reçus ne mesurent pas les mêmes éléments, mais ils créent la même pression opérationnelle : le volume des vulnérabilités augmente trop rapidement pour que les équipes puissent vérifier, prioriser et corriger ce qui compte vraiment.

Les modèles de gravité continuent de partir du principe qu'une vulnérabilité est isolée, mais les agents peuvent enchaîner une faille de faible gravité, une autorisation trop large et un chemin exposé pour construire une attaque bien réelle. Une file d'attente triée par CVSS passe de plus en plus à côté de ce contexte, tandis que le backlog grossit plus vite que les équipes ne peuvent le résorber avec leurs outils et processus traditionnels.

Le modèle opérationnel doit évoluer avec les paramètres économiques des attaques. Les contrôles de sécurité doivent s'inscrire dans le chemin d'exécution, avec une boucle de correction refermée derrière chaque vulnérabilité significative. Ce chemin gouverné à travers votre cycle de développement logiciel (SDLC), avec vos propres garde-fous, votre contexte et vos workflows, constitue le socle d'une usine logicielle d'entreprise.

Les capacités agentiques donnent l'avantage aux acteurs attaqués

Les équipes de sécurité ont toujours été en sous-effectif, et notre propre flux entrant tourne aujourd'hui à environ six fois le rythme de 2025. Mais des modèles performants changent d'abord la donne en faveur des acteurs attaqués.

Les équipes attaquées ont accès au code, à l'infrastructure, aux chemins de déploiement, à la configuration, aux systèmes d'identité et au contexte opérationnel. En pointant la même capacité sur la même cible, nous profitons d'une bien meilleure visibilité, à condition de l'utiliser d'abord sur notre propre surface. Les modèles peuvent transformer ce contexte plus large en découverte, priorisation et correction à la vitesse machine. Cela n'avait jamais été le cas auparavant.

Le processus de build devient lui aussi observable. Pendant des années, une grande partie du travail réalisé sur un ticket n'était pas capturée dans des systèmes que les équipes de sécurité pouvaient inspecter. Celles-ci se contentaient d'examiner les diffs, les builds et les applications en production.

Lorsqu'un agent construit un logiciel, cette construction peut devenir un flux d'événements : lectures de fichiers, appels d'outils, commandes, identifiants émis, systèmes consultés et approbations accordées. Cette trace nous permet de gouverner la manière dont le logiciel est construit.

Cet avantage architectural existe dès lors que les agents s'exécutent dans un environnement où leurs actions peuvent être identifiées, limitées et enregistrées. Une fois cette infrastructure en place, chaque amélioration des capacités des modèles renforce le dispositif de défense.

Je suis d'avis qu'une défense à la vitesse machine repose sur trois niveaux, qui se renforcent à mesure que les capacités des modèles et le volume de commits augmentent tout au long du SDLC.

Niveau 1 : faites le point sur votre situation

Il s'agit de la phase de découverte qui conditionne tout ce qui suit. En partant du principe qu'un attaquant dispose déjà des mêmes modèles que vous, utilisez-les de manière proactive sur votre propre surface (code, infrastructure et chemins de déploiement). L'objectif est d'obtenir une image vérifiée de votre situation actuelle.

Les laboratoires de pointe se trouvent au plus près de la courbe de capacité, là où les nouvelles capacités des modèles d'IA apparaissent d'abord, aussi bien en attaque qu'en défense. Leur contribution élève le niveau de posture défensive sur lequel le reste du secteur peut s'appuyer : une découverte assistée par des modèles pointée sur des systèmes réels et des corrections rédigées par des agents que votre équipe approuve. C'est ce que nous menons avec Anthropic dans le cadre du Project Glasswing, en utilisant leurs modèles sur l'ensemble de nos systèmes et produits critiques, et en répétant ce scénario à chaque nouveau modèle plus performant.

Nous utilisons ensuite GitLab Duo Agent Platform pour classer par ordre de priorité et corriger ces vulnérabilités en continu, réduire l'introduction de nouveaux tickets et livrer un logiciel déjà vérifié avant même d'atteindre la production. Nous sommes le client zéro des exigences que nous imposons au secteur du logiciel et avons pour objectif de transformer cette approche en confiance dans ce que vous construisez sur notre plateforme.

Niveau 2 : renforcez vos bases

Une base de référence indique où vous en êtes. Le plus difficile est de la maintenir alors que le volume de code, les capacités des agents et celles des attaquants continuent d'augmenter.

Cette base doit répondre à six exigences.

1. Connaissez et scannez en continu l'intégralité de la surface d'attaque. Les tests statiques de sécurité des applications (SAST), l'analyse des dépendances, des conteneurs, des secrets, des API et les tests dynamiques de sécurité des applications (DAST) doivent fonctionner comme un seul modèle de couverture. Les scanners tiers doivent alimenter un système de gestion des vulnérabilités commun. Une organisation ne peut pas raisonner sur le risque à partir d'inventaires partiels, avec des identités, des niveaux de gravité, des chemins d'attaque, des propriétaires et des états de correction différents.
2. Éliminez les secrets exposés et à longue durée de vie. La gestion centralisée des secrets, le principe de moindre privilège, la rotation, la révocation et la détection des secrets doivent être appliqués par défaut dans les chemins qui créent et déploient le logiciel. Chaque identifiant doit disposer d'une identité, d'une portée, d'une durée de vie et d'un chemin de révocation définis.
3. Transformez la découverte des vulnérabilités en correction continue. Éliminez les faux positifs, priorisez les vulnérabilités réelles en fonction du contexte et utilisez des agents pour générer, tester et valider les correctifs. Une faille de sécurité reste ouverte jusqu'à ce que le changement proposé soit prouvé sur le code, la configuration et le chemin de déploiement concernés.
4. Appliquez la politique dans le chemin d'exécution. Les scans, les approbations, la séparation des tâches et les contrôles de déploiement doivent être appliqués de manière centralisée là où le travail s'exécute. Les équipes de développement et les agents ne devraient pas avoir à se souvenir de la politique applicable ni à gérer les bons transferts.
5. Traitez les agents comme des acteurs privilégiés. Chaque agent a besoin d'une identité explicite, d'autorisations minimales, d'outils et d'identifiants limités, de chemins d'accès autorisés et d'actions auditables. Les opérations à haut risque nécessitent un point d'approbation attribuable, d'autant plus que les agents passent de la simple suggestion de code à l'action directe sur les dépôts, les systèmes CI/CD, l'infrastructure cloud et la production.
6. Mesurez le temps écoulé entre la détection et la correction vérifiée. Suivez la durée pendant laquelle une vulnérabilité réelle reste exposée, de sa détection jusqu'à un correctif prouvé dans l'environnement concerné. Segmentez ces données par gravité et par chemin d'attaque, puis réduisez-les en continu. Face à des attaques à la vitesse machine, cet indicateur devient l'indicateur opérationnel principal.

Ces exigences fonctionnent ensemble : une couverture continue pour que chaque faille de sécurité ait un chemin de traitement, des correctifs testés sur le chemin où ils seront livrés, une politique appliquée là où le travail s'exécute et des agents disposant de leur propre identité plutôt que du jeton d'accès d'un développeur.

Niveau 3 : protégez ce qui est déjà en production

Le logiciel et son environnement continuent d'évoluer après la mise en production. L'artefact que vous avez livré le mois dernier peut devenir vulnérable à la suite d'une divulgation le mois suivant, l'exploitation survenant parfois en quelques jours, avant même qu'un correctif ne soit disponible.

Par conséquent, une mise à niveau unique ne suffit pas : continuez à appliquer les scans après le merge, réévaluez la production à chaque nouveau modèle plus performant et déployez les correctifs dans le même workflow de développement qui a produit le changement. Contrôlez chaque merge et refermez chaque correctif afin que toute nouvelle faille avance vers sa correction.

Le modèle opérationnel consiste à faire respecter la sécurité que vous avez déjà, à mesurer le temps entre la détection et la correction vérifiée, et à conserver les vérifications d'expérience client dans le même chemin de build que la sécurité.

CE QUE DISENT MES PAIRS

Des experts en cybersécurité et des RSSI décrivent une approche opérationnelle similaire, avec pour objectif d'aligner la gouvernance et la correction sur la vitesse du développement.

« Un risque de sécurité découvert à l'échelle machine sans chemin tout aussi rapide vers une correction gouvernée n'est pas un progrès. C'est un problème d'inventaire déguisé en sécurité. Les organisations qui tiendront face au développement agentique sont celles qui traitent la détection comme le point de départ d'une boucle refermée : une politique à chaque changement, une correction dans le chemin de build et une base de référence qu'elles peuvent vérifier en continu à mesure que les modèles progressent. » Gadi Evron, CISO-in-Residence for AI, Cloud Security Alliance

« Un programme de sécurité durable pour le développement logiciel agentique maintient chaque agent sur des rails légitimes : une identité explicite, des autorisations limitées et un chemin autorisé de la planification à la production. Un agent qui opère hors de ces rails est hors de contrôle : pas d'identité, pas de trace, aucun moyen de gouverner ce qu'il a touché. Cette discipline doit tenir bon à mesure que les modèles progressent et que le volume des agents augmente. » Bill Shields, CISO, Workday

« La confiance dans ce que vous livrez dépend du durcissement continu des modèles et des plateformes de développement sur lesquels vous vous appuyez, ainsi que de la gouvernance de chaque changement dans votre cycle de vie logiciel. Ces deux couches se renforcent mutuellement, et aucune ne remplace l'autre. » Sam Curry, Chief Security Officer, Zscaler

L'usine logicielle fantôme, un problème d'architecture

À mesure que les agents produisent une part croissante du code, votre SDLC se divise en deux. Le premier chemin passe par des dépôts gouvernés, des systèmes CI/CD, des contrôles d'identité, des approbations et des outils de sécurité. Le chemin fantôme passe par des ordinateurs personnels, des identifiants locaux, des outils non gérés et des sessions d'agents en dehors de ces contrôles. Il peut produire du code valide, mais sans trace fiable de la manière dont ce code et les changements d'infrastructure qui l'accompagnent ont été réalisés.

Un commit indique quel identifiant a été utilisé, mais il révèle peu de choses sur l'agent, les outils, les autorisations, les commandes et les systèmes externes à l'origine du changement. Capturer cette preuve exige un environnement d'exécution gouverné qui relie identité, autorisations, outils, politique et approbations. Sans cela, les équipes de sécurité inspectent des artefacts après que les actions importantes ont déjà eu lieu.

Capturer les événements n'est qu'un début. À l'échelle agentique, une transcription complète devient elle-même un nouveau backlog. Les systèmes de sécurité doivent transformer ces événements en politiques applicables, en décisions attribuables et en résultats vérifiés. Les appels d'outils constituent la preuve ; l'explication que donne un agent de son propre raisonnement n'est que secondaire.

En pratique

Cette architecture devient concrète sur GitLab. La politique s'inscrit dans le chemin d'exécution. Le scan s'exécute là où les équipes de développement et les agents travaillent déjà, suffisamment tôt pour que la correction reste peu coûteuse. Les risques de sécurité découverts par des outils tiers convergent vers un système de gestion des vulnérabilités unique, et les agents transforment les failles validées en merge requests testées, porteuses du contexte applicatif nécessaire pour les corriger. Les secrets sont, par défaut, à courte durée de vie, à portée limitée et révocables. Les actions d'agent à haut risque s'arrêtent à un point d'approbation attribuable. Si le pipeline ne peut pas prouver un élément, le pipeline ne le livre pas.

La capacité de production de code devient élastique, tandis que la capacité de revue humaine reste limitée. Lors d'une release récente, nous avons exécuté une revue de sécurité agentique sur 969 des 997 merge requests éligibles, soit 97 %. Il y a un an, un tel niveau de couverture était inconcevable. Aujourd'hui, il s'agit de la norme attendue.

GitLab réunit ces contrôles à l'échelle de la plateforme. GitLab Duo Agent Platform referme les boucles de classement et de correction agentiques sur le même chemin gouverné que la gestion du code source, la sécurité, le CI/CD et le merge. Si vous êtes client GitLab, appliquez ces contrôles dans le chemin d'exécution et mesurez s'ils réduisent votre temps d'exposition entre la détection et la correction vérifiée.

La véritable question architecturale est de savoir si le travail agentique passe par le même socle gouverné pour votre usine logicielle. Lorsque c'est le cas, les équipes et les agents partagent un plan de contrôle commun. Lorsque ce n'est pas le cas, l'usine logicielle fantôme persiste, quelle que soit la quantité d'outils de sécurité qui entoure le pipeline en aval.

Donner corps au modèle opérationnel

Un programme crédible peut répondre à ces questions à partir de ses données opérationnelles :

• Quelle est la surface d'attaque complète, et quand chaque surface a-t-elle été scannée pour la dernière fois ?
• Quels risques de sécurité détectés sont réels, lesquels sont des faux positifs, et qui, ou quoi, a établi cette distinction ?
• Combien de temps chaque vulnérabilité réelle est-elle restée exposée avant qu'un correctif ne soit vérifié dans l'environnement concerné ?
• Quels secrets ont été émis, à qui ou à quoi, avec quelle portée, pour combien de temps, et comment ont-ils été révoqués ?
• Quel agent a réalisé chaque action, par quel chemin autorisé, avec quels outils et quelles autorisations ?
• Quelle politique, quelle approbation, quel contrôle de séparation des tâches ou quel contrôle de déploiement a bloqué ou autorisé l'action ?
• Un examinateur indépendant peut-il rejouer les preuves et aboutir à la même conclusion ?

Ces réponses doivent gagner en automatisation. Un programme fonctionnel maintient une couverture continue sur l'ensemble de la surface d'attaque, attribue un propriétaire et un chemin de correction testé à chaque vulnérabilité significative et élimine les secrets exposés et à longue durée de vie ou les limite dans le temps avec des contrôles compensatoires que vous pouvez justifier. Les agents opèrent avec des identités autorisées et des autorisations limitées, avec une approbation enregistrée pour les opérations à haut risque, et vous mesurez en continu le temps entre détection et correction vérifiée, par gravité et par chemin d'attaque, afin de l'aligner sur la vitesse machine.

C'est en exécutant le modèle nous-mêmes que nous découvrons les enjeux nécessaires. Dans les mois à venir, GitLab publiera un modèle d'infrastructure qui traduit ces principes en recommandations opérationnelles : les contrôles, l'architecture, les indicateurs et les pratiques permettant d'établir une base de référence. Ce modèle d'infrastructure vous aidera à maintenir votre développement logiciel agentique sur un chemin gouverné, à éliminer le travail de production fantôme et à faire avancer en continu les vulnérabilités vers une correction vérifiée.

L'objectif est concret : donner aux dirigeants de sécurité et d'ingénierie un élément tangible qu'ils peuvent mettre en œuvre et mesurer, quel que soit leur modèle de départ.

La norme a changé

J'écris ces lignes en tant que responsable de la même catégorie de décisions que vous. Quand la génération de code est abondante et que la confiance se raréfie, votre développement logiciel agentique exige une vérification et une correction à la vitesse machine. La sécurité, la gouvernance et les garde-fous doivent faire partie de vos bases, et non se limiter à un ensemble de contrôles en périphérie.

L'opportunité actuelle est inhabituelle. Les mêmes modèles qui augmentent les capacités offensives peuvent aussi étendre les capacités défensives. En tant que professionnels de la cybersécurité, nous disposons de plus de contexte que l'attaquant, d'un accès plus large à nos propres systèmes et de la possibilité de garantir l'observabilité et la gouvernance de la construction même du logiciel. Nous devons exploiter cet avantage.

Attendez-vous à un durcissement continu des plateformes sur lesquelles vous vous appuyez. Demandez des preuves de ce qu'elles détectent, de la rapidité avec laquelle elles appliquent des correctifs, et si leurs contrôles résistent à la prochaine hausse des capacités des modèles. Appliquez la même norme à votre propre développement logiciel. Les clients GitLab peuvent utiliser GitLab Duo Agent Platform pour intégrer le classement et la correction agentiques dans le même chemin gouverné que la gestion du code source, le CI/CD et le reste du SDLC.

La nouvelle norme consiste désormais à faire passer la détection à la correction vérifiée à la vitesse machine.

Participez à Transcend, notre événement diffusé en direct le 6 octobre, où nous approfondirons ce sujet et partagerons nos dernières innovations pour vous aider à sécuriser votre développement logiciel agentique.