Sécuriser votre usine logicielle

GitLab Security
Standard

Les organisations évoluent vers un monde où les agents développent des logiciels sans qu'un humain intervienne à chaque étape. GitLab Security Standard montre comment y parvenir en toute sécurité : des fondements de sécurité qui renforcent l'usine logicielle, et des étapes qui permettent aux agents de mériter leur autonomie.

v1.0Publié le 6 octobre 2026

Le contexte a changé

Le code est abondant. La confiance est rare. Les modèles d'IA permettent aux agents d'écrire et de livrer du code à la vitesse de la machine. Mais ces mêmes modèles permettent aussi de repérer, d'enchaîner et d'exploiter les failles existantes plus vite et à moindre coût. Le volume de découvertes augmente désormais plus vite que la capacité des équipes à vérifier, prioriser et corriger ce qui compte.

Faites confiance à vos agents

Pyramide de cinq étapes, Autoriser, Isoler, Vérifier, Publier et Répondre, sur un fondement de politiques, d'audit et de responsabilité, avec l'autonomie au sommet et une boucle détecter, corriger, apprendre qui renvoie les échecs vers le fondement.

Notre approche pour instaurer la confiance dans une flotte d'agents commence par l'usine logicielle dans laquelle ils travaillent. La sécurité est intégrée à chaque étape, de sorte que les agents opèrent sous des contrôles qu'ils ne peuvent pas contourner. L'autonomie n'est pas accordée, elle se mérite, une étape à la fois.

Cinq étapes, bâties sur un fondement de politiques, d'audit et de responsabilité, définissent ce que chaque agent doit prouver. Plus un agent fait ses preuves, plus il gagne en autonomie.

Fondement · Là où la confiance commence

Politiques, audit, responsabilité

Des règles à appliquer, une trace de ce qui s'est passé et un humain responsable en cas d'échec. Sans ce fondement, aucune étape ne peut être prouvée.

  • Politiques

    Les humains définissent ce que les agents peuvent faire : quels outils ils utilisent, à quoi ils peuvent accéder et quelles actions nécessitent une approbation. Ces politiques sont définies et approuvées avant l'écriture du moindre code, puis appliquées automatiquement.

  • Audit

    Une piste d'audit immuable de chaque agent et de chaque modèle, jusqu'à chaque prompt, étape de raisonnement, appel d'outil et action, reliée de la tâche au déploiement.

  • Responsabilité

    Un humain est responsable de chaque agent, de chaque compte de service et de chaque contrôle.

  1. 01Autoriser

    Objectif

    Qui et quoi peut agir, et dans quelles limites ?

    Chaque personne, agent et service possède une identité connue ou composite, un responsable désigné et un accès limité à la tâche en cours.

    Exemples de contrôles

    1. Inventaire des agentsChaque agent, intégration et compte de service est connu et a un responsable.Catalogue d'IA
    2. Identité des agentsChaque action d'un agent est rattachée à l'agent et à l'humain qui l'a déclenchée.Identité composite
    3. Gestion des secretsCentralisée, selon le principe du moindre privilège, avec rotation et révocation possibles, ainsi qu'une portée et une durée de vie définies pour chaque identifiant.GitLab Secrets Manager

  2. 02Isoler

    Objectif

    Une entrée ou un outil compromis peut-il aller au-delà de la tâche ?

    Le travail s'exécute dans un environnement cloisonné dont les limites tiennent même lorsque l'agent suit une instruction malveillante.

    Exemples de contrôles

    1. Exécution isoléeEspace de travail éphémère avec stockage et réseau restreints.Environnement d'exécution de GitLab Duo Agent Platform
    2. Dépendances fiablesLes paquets passent par un proxy contrôlé et sont vérifiés avant d'atteindre le build.GitLab Dependency FirewallVersion bêta fermée
    3. Outils et chemins d'accès autorisésLes agents n'utilisent que des outils, connexions et serveurs MCP approuvés.Gouvernance de l'IAVersion bêta

  3. 03Vérifier

    Objectif

    La modification est-elle sûre, vérifiée par des contrôles que l'acteur ne peut pas modifier ?

    Chaque modification, humaine ou issue d'un agent, passe des contrôles de sécurité appliqués de manière centralisée, qui ne peuvent être ni modifiés ni contournés.

    Exemples de contrôles

    1. Politiques dans le chemin d'exécutionLes scans, approbations et contrôles de déploiement sont appliqués de manière centralisée, et non projet par projet.Politiques d'exécution des pipelines
    2. Contrôles protégésL'acteur ne peut pas modifier le pipeline ou la politique qui l'évalue.Branches protégées
    3. Séparation des tâchesL'auteur, humain ou agent, ne peut pas être le seul approbateur.Politiques d'approbation des merge requests

  4. 04Publier

    Objectif

    La production reçoit-elle exactement ce qui a été vérifié ?

    Les décisions de déploiement sont liées à l'artefact exact qui a passé la vérification, identifié par son empreinte et sa provenance, et non par son nom ou son libellé de version.

    Exemples de contrôles

    1. Provenance et signatureChaque artefact comporte une preuve signée de sa source, de ses entrées et de son build.Génération de provenance SLSA
    2. Vérifier avant de déployerL'empreinte déployée doit correspondre à l'empreinte approuvée.Vérification de l'attestation des artefacts
    3. Références immuablesLes tags et les images ne peuvent pas être modifiés après approbation.Tags de conteneur protégés

  5. 05Répondre

    Objectif

    Pouvons-nous arrêter, tracer et rétablir une tâche ?

    Les activités suspectes et les résultats vulnérables déclenchent une réponse capable d'arrêter la tâche, de tracer ce qu'elle a touché et de vérifier le correctif.

    Exemples de contrôles

    1. Arrêt d'urgence testéUne tâche peut être interrompue, son accès révoqué et ses releases suspendues.Blocage des comptes de service
    2. Suivi de l'impactChaque modification et chaque release touchées par un agent peut être identifiée.Événements d'audit
    3. Surveillance des actions à fort impactL'utilisation des outils, l'accès aux identifiants, les changements d'autorisations et les déploiements sont visibles.Streaming des événements d'audit

La boucle de rétroaction

Détecter, corriger, apprendre

Quand une tâche échoue, tirez-en des leçons et mettez à jour la politique, afin que les règles s'améliorent avant le rétablissement de l'autonomie.

En parallèle, des agents de sécurité détectent, classent et corrigent en continu les vulnérabilités.

Correction automatisée

Ce que nous mesurons

  • Délai de confinement
  • Délai de correction vérifiée

Alignement sur les frameworks

GitLab Security Standard s'aligne sur les frameworks que vos équipes de sécurité et de conformité utilisent déjà dans leurs rapports.

ÉtapeOWASP SAMMOWASP Top 10 for Agentic ApplicationsMITRE ATLASNIST SSDF & SP 800-53
FondementPolitiques, audit, responsabilité
  • Principe de moindre autonomie (principe fondamental)
  • SSDF PO.1, PO.2, PO.3
  • SP 800-53 AU
01Autoriser
  • ASI03 Abus d'identité et de privilèges
  • ASI07 Communication inter-agents non sécurisée
  • ASI10 Agents incontrôlés
  • SSDF PS.1
  • SP 800-53 AC-2, AC-5, AC-6, CM-3, CM-5, IA, SA-11
02Isoler
  • ASI01 Détournement d'objectif de l'agent
  • ASI02 Usage inapproprié et exploitation des outils
  • ASI04 Vulnérabilités de la chaîne d'approvisionnement agentique
  • ASI05 Exécution de code inattendue
  • ASI06 Empoisonnement de la mémoire et du contexte
  • ASI08 Défaillances en cascade
  • SSDF PO.5, PW.4
  • SP 800-53 SC-7, SC-39, SR
03Vérifier
  • ASI05 Exécution de code inattendue
  • ASI09 Exploitation de la confiance humain-agent
  • SSDF PO.4, PW.7, PW.8
04Publier
  • ASI04 Vulnérabilités de la chaîne d'approvisionnement
  • SSDF PS.2, PS.3
  • SP 800-53 SI-7, SR-4
05Répondre
  • ASI10 Agents incontrôlés
  • SSDF RV.1 à RV.3
  • SP 800-53 IR, AU

MITRE ATLAS répertorie les techniques d'attaque visant les systèmes d'IA, c'est pourquoi certaines étapes n'ont pas de correspondances directes.

L'autonomie méritée

L'autonomie est accordée par workflow, et chaque workflow doit réussir les tests de chaque étape avant d'en gagner. Différents workflows peuvent fonctionner simultanément à des niveaux d'autonomie différents.

  • Ce que l'agent peut faire
    Recommander ; les humains effectuent la modification
    Exemple de workflow
    Configuration des pipelines et des politiques (modifications des contrôles eux-mêmes)

Vos agents ont-ils mérité leur autonomie ?

Demandez votre évaluation gratuite pour savoir comment atteindre le niveau d'autonomie suivant dans votre environnement.

Tous les champs sont obligatoires

GitLab applique GitLab Security Standard à sa propre usine logicielle. Il est public, en libre accès et en constante évolution. À mesure que les menaces, les modèles et nos propres capacités évoluent, nous continuerons à le mettre à jour et à indiquer ce qui a changé.