Sécurité de GitLab CI/CD : Le Guide Définitif

GitLab CI/CD est devenu la colonne vertébrale du DevSecOps moderne : il offre une plateforme intégrée où le code, les pipelines, l’analyse de sécurité et les déploiements convergent dans une seule interface. Mais cette intégration profonde est une arme à double tranchant : un pipeline mal configuré peut exposer des secrets, autoriser des déploiements non autorisés ou donner à des attaquants un point d’ancrage dans votre infrastructure.

Ce guide définitif couvre toutes les surfaces pertinentes pour la sécurité de GitLab CI/CD — des variables protégées et du périmètre des runners à la fédération OIDC et à la sûreté des pipelines de merge request. Que vous durcissiez une installation GitLab existante ou que vous construisiez une pratique DevSecOps à partir de zéro, cet article vous donne les connaissances et les checklists concrètes dont vous avez besoin.

Pourquoi la sécurité de GitLab CI/CD est importante

GitLab se présente comme la « One DevOps Platform », et à juste titre. Contrôle de version, suivi des tickets, CI/CD, container registry, package registry, analyse de sécurité et gestion des déploiements vivent tous sous le même toit. Cette consolidation simplifie l’outillage — mais elle concentre aussi le risque. Un seul job de pipeline compromis peut potentiellement lire le code source, voler des identifiants, pousser des images malveillantes et déclencher des déploiements en production.

Les récentes attaques de la chaîne d’approvisionnement ont démontré que les pipelines CI/CD sont des cibles de grande valeur. Les attaquants qui parviennent à injecter des étapes dans un pipeline — que ce soit via une dépendance empoisonnée, un runner partagé compromis ou une merge request malveillante — peuvent exfiltrer des secrets, altérer des artifacts de build ou se déplacer latéralement vers des environnements cloud. GitLab fournit un riche ensemble de contrôles pour prévenir ces scénarios, mais uniquement si vous les comprenez et les activez.

Comprendre le modèle de sécurité de GitLab CI

Avant de plonger dans les contrôles individuels, il est utile de comprendre les quatre piliers du modèle de sécurité de GitLab CI :

Runners — la couche de calcul qui exécute les jobs. La sécurité dépend de l’isolation, du niveau de confiance et du périmètre.
Variables — la configuration et les secrets injectés dans les jobs. La protection et le masquage déterminent qui peut y accéder et comment.
Environnements — des cibles de déploiement logiques (staging, production). Les règles de protection et les portes d’approbation contrôlent qui peut déployer et où.
Tokens — des identifiants de courte durée (CI_JOB_TOKEN, OIDC id_tokens) qui authentifient les jobs auprès d’autres services. Le périmètre limite leur rayon d’impact.

Chaque mesure de durcissement de ce guide se rattache à un ou plusieurs de ces piliers. Maîtrisez les quatre, et vous obtiendrez une posture de défense en profondeur capable de résister aussi bien aux erreurs internes qu’aux attaques externes.

Variables protégées et masquées

Les variables CI/CD sont le principal mécanisme d’injection de secrets — clés API, identifiants cloud, mots de passe de bases de données — dans les jobs de pipeline. GitLab propose deux protections orthogonales : la protection et le masquage.

Variables protégées

Lorsqu’une variable est marquée comme protégée, GitLab ne l’expose qu’aux jobs s’exécutant sur des branches protégées ou tags protégés. C’est un contrôle essentiel : cela signifie qu’un développeur qui ouvre une merge request depuis une branche de fonctionnalité ne peut pas écrire une étape de pipeline qui affiche vos identifiants AWS de production. La variable n’existe tout simplement pas dans l’environnement du job pour les références non protégées.

Bonnes pratiques pour les variables protégées :

Marquez chaque secret de production comme protégé. Il n’existe aucune raison valable pour qu’un job de branche de fonctionnalité accède aux identifiants de production.
Limitez qui peut pousser ou fusionner dans les branches protégées (rôle Maintainer ou supérieur). Cela crée une porte humaine avant que les secrets ne soient accessibles.
Utilisez des variables à portée d’environnement lorsque le même nom de secret diffère entre staging et production. GitLab injectera la valeur correcte en fonction du mot-clé environment: présent dans la définition du job.
Renouvelez régulièrement les variables protégées. Même les variables protégées peuvent fuiter via une journalisation mal configurée ou des runners compromis.

Variables masquées

Le masquage empêche la valeur d’une variable d’apparaître dans les logs des jobs. GitLab remplace toute occurrence de la valeur par [MASKED]. Le masquage est un filet de sécurité, pas une frontière de sécurité — il protège contre une exposition accidentelle (par exemple, une commande curl verbeuse qui journalise les en-têtes) mais n’empêche pas une étape de job malveillante d’encoder la valeur en Base64 ou de l’écrire dans un artifact.

Combinez protection et masquage. Une variable à la fois protégée et masquée vous offre la meilleure défense intégrée : un périmètre de branche limité plus une expurgation au niveau des logs.

Types de runners et périmètre

Les runners sont l’endroit où votre code s’exécute réellement. Comprendre les types de runners et leurs implications de sécurité est essentiel pour un environnement GitLab CI durci.

Runners partagés, de groupe et de projet

GitLab prend en charge trois périmètres pour les runners :

Runners partagés — disponibles pour tous les projets de l’instance. Pratiques mais les plus risqués : un projet malveillant peut potentiellement laisser des artifacts, des caches ou des processus qui affectent le job suivant d’un projet sans lien.
Runners de groupe — disponibles pour tous les projets d’un groupe donné. Un compromis raisonnable qui limite l’exposition inter-projets tout en réduisant la charge de gestion des runners.
Runners de projet — dédiés à un seul projet. Isolation maximale, mais coût opérationnel plus élevé. Recommandés pour les dépôts à forte exigence de sécurité qui manipulent des secrets de production ou des données clients sensibles.

Runners protégés

N’importe quel runner peut être marqué comme protégé. Un runner protégé ne prend que les jobs des branches protégées ou des tags protégés. Cela se marie naturellement avec les variables protégées : votre runner de déploiement en production ne s’exécute que sur main, et seuls les jobs sur main ont accès aux secrets de production.

Checklist de durcissement des runners :

Utilisez des runners éphémères (mis à l’échelle automatiquement, détruits après chaque job) pour éliminer la persistance des données entre les jobs.
N’utilisez Docker-in-Docker avec --privileged que lorsque c’est absolument nécessaire, et isolez ces runners dans un groupe de sécurité dédié.
Désactivez l’exécuteur shell sur les runners partagés. Utilisez les exécuteurs Docker ou Kubernetes avec des contextes de sécurité restrictifs.
Taguez les runners de déploiement en production et verrouillez-les à des projets et des branches protégées spécifiques.
Auditez les tokens d’enregistrement des runners — renouvelez-les régulièrement et révoquez immédiatement tout token divulgué.

Environnements protégés et approbations de déploiement

Les environnements GitLab représentent des cibles de déploiement telles que staging, production, ou canary. Protéger un environnement ajoute une couche d’autorisation qui va au-delà de la protection de branche.

Comment fonctionnent les environnements protégés

Lorsque vous protégez un environnement, vous précisez quels utilisateurs ou groupes sont autorisés à y déployer. Même si un pipeline s’exécute sur une branche protégée, le job de déploiement ne s’exécutera pas si l’utilisateur déclencheur n’a pas la permission requise. Cela crée une séparation des responsabilités : les développeurs peuvent fusionner du code, mais seuls les déployeurs désignés peuvent le pousser en production.

Approbations de déploiement (Premium/Ultimate)

Les éditions GitLab Premium et Ultimate proposent les approbations de déploiement — un mécanisme qui met en pause un job de déploiement et attend qu’un ou plusieurs approbateurs désignés donnent leur feu vert. C’est précieux pour les environnements réglementés où les processus de gestion des changements exigent une validation humaine avant que les changements n’atteignent la production.

Conseils de configuration :

Exigez au moins deux approbateurs pour les déploiements en production afin d’éviter une compromission par une seule personne.
Définissez les règles d’approbation au niveau du groupe pour qu’elles s’appliquent de manière cohérente à tous les projets d’une même unité opérationnelle.
Combinez les approbations de déploiement avec des runners protégés et des variables protégées pour une défense en couches.
Utilisez le mot-clé environment: deployment_tier pour classer les environnements (production, staging, testing, development) et appliquer les politiques appropriées à chaque niveau.

Périmètre du CI_JOB_TOKEN

Chaque job GitLab CI reçoit un CI_JOB_TOKEN généré automatiquement — un identifiant de courte durée qui authentifie le job auprès de l’API GitLab, du container registry et du package registry. Par défaut, ce token peut accéder à des ressources dans plusieurs projets, ce qui crée un risque de mouvement latéral.

Limiter l’accès du CI_JOB_TOKEN

GitLab 15.9+ a introduit les contrôles de périmètre du token de job CI/CD . Vous pouvez désormais configurer une liste d’autorisation des projets auxquels le CI_JOB_TOKEN d’un projet donné peut accéder. C’est un réglage indispensable à activer pour toute organisation soucieuse de sa sécurité.

Étapes pour durcir le CI_JOB_TOKEN :

Accédez à Settings > CI/CD > Token Access dans votre projet.
Activez Limit CI_JOB_TOKEN access (cela restreint le token au projet courant par défaut).
Ajoutez uniquement les projets spécifiques auxquels les jobs de ce projet ont légitimement besoin d’accéder.
Révisez la liste d’autorisation chaque trimestre et supprimez les entrées obsolètes.

Avec des tokens à périmètre restreint, même si un attaquant compromet un job de pipeline, le rayon d’impact se limite aux projets explicitement autorisés plutôt qu’à l’ensemble de l’instance GitLab.

Fédération OIDC avec id_tokens

Les identifiants cloud codés en dur dans les variables CI sont un risque de sécurité persistant. La prise en charge d’ OIDC (OpenID Connect) par GitLab élimine entièrement ce risque en permettant aux jobs de pipeline de s’authentifier auprès des fournisseurs cloud à l’aide de tokens de courte durée, signés cryptographiquement.

Comment ça fonctionne

Lorsque vous définissez un bloc id_tokens dans votre .gitlab-ci.yml, GitLab génère un JWT signé pour chaque job. Le JWT contient des claims sur le job — chemin du projet, nom de la référence, environnement, source du pipeline — que le fournisseur cloud peut évaluer par rapport à sa politique de confiance.

deploy_production:
  id_tokens:
    GITLAB_OIDC_TOKEN:
      aud: https://aws.example.com
  script:
    - |
      export AWS_WEB_IDENTITY_TOKEN_FILE=$(mktemp)
      echo "$GITLAB_OIDC_TOKEN" > $AWS_WEB_IDENTITY_TOKEN_FILE
      aws sts assume-role-with-web-identity \
        --role-arn arn:aws:iam::123456789012:role/gitlab-deploy \
        --web-identity-token file://$AWS_WEB_IDENTITY_TOKEN_FILE

Du côté cloud (AWS, GCP, Azure), vous configurez une politique de confiance qui n’accepte que les tokens provenant de projets, de branches et d’environnements spécifiques. Cela signifie :

Aucun identifiant statique à renouveler ou à divulguer.
Accès à grain fin — un token provenant d’une branche de fonctionnalité peut être rejeté par le fournisseur cloud, même si le pipeline est par ailleurs valide.
Auditabilité — chaque événement d’authentification est journalisé avec l’ensemble des claims du JWT.

Pour une exploration approfondie des schémas de fédération OIDC sur AWS, GCP et Azure, consultez notre guide dédié : Identifiants de courte durée et fédération d’identité de charge de travail pour la CI/CD.

Sécurité des pipelines de merge request

Les merge requests sont le vecteur le plus courant d’injection de code malveillant dans les pipelines. Un contributeur externe (ou un compte compromis) peut soumettre une merge request qui modifie .gitlab-ci.yml pour exfiltrer des secrets ou établir une persistance.

Protections essentielles

Utilisez rules: - if: $CI_PIPELINE_SOURCE == 'merge_request_event' pour créer des pipelines de MR dédiés qui s’exécutent avec des privilèges réduits. Les pipelines de MR provenant de forks n’ont pas accès aux variables protégées par défaut.
Exigez la réussite du pipeline avant la fusion. Cela garantit que les analyses de sécurité (SAST, analyse des dépendances, détection de secrets) s’exécutent sur chaque MR.
Limitez les include: aux sources de confiance. Des MR malveillantes peuvent ajouter des directives include: remote: qui importent du YAML contrôlé par l’attaquant. Utilisez une liste d’autorisation des domaines d’include permis ou épinglez à des références précises.
Activez « Pipelines must succeed » et « All threads must be resolved » dans les paramètres de merge request de votre projet.
Examinez les modifications de .gitlab-ci.yml avec soin. Toute MR qui modifie la configuration du pipeline devrait exiger l’approbation d’un réviseur sensibilisé à la sécurité.

Restrictions des pipelines de fork

Pour les projets publics ou open source, les pipelines de fork présentent des risques supplémentaires. GitLab vous permet de :

Exécuter les pipelines de fork dans un mode restreint, sans accès aux variables CI du projet.
Exiger une approbation manuelle avant d’exécuter des pipelines provenant de forks (disponible dans Premium/Ultimate).
Utiliser des runners séparés et non privilégiés pour les pipelines de fork.

Détection de secrets avec les templates SAST intégrés

GitLab est livré avec des templates SAST (Static Application Security Testing) intégrés qui incluent la détection de secrets. Les activer est simple :

include:
  - template: Jobs/Secret-Detection.gitlab-ci.yml
  - template: Jobs/SAST.gitlab-ci.yml

Le scanner de détection de secrets utilise la correspondance de motifs et l’analyse d’entropie pour identifier les identifiants divulgués, les clés API, les clés privées et les tokens dans votre base de code. Les résultats apparaissent dans le widget de sécurité de la merge request, ce qui permet aux réviseurs de repérer facilement les fuites avant qu’elles n’atteignent la branche par défaut.

Maximiser l’efficacité de la détection de secrets :

Activez la détection de secrets au niveau du pipeline (pas seulement l’analyse historique) afin que chaque commit soit vérifié.
Configurez des push rules pour rejeter les commits contenant des motifs de secrets connus (par exemple, AKIA pour les clés d’accès AWS).
Intégrez avec la gestion des vulnérabilités de GitLab pour suivre, trier et résoudre les secrets détectés.
Ajoutez des motifs personnalisés pour les formats de secrets propres à votre organisation (clés API internes, tokens de comptes de service).
Exécutez la détection de secrets à la fois sur la branche source et sur le résultat de la fusion pour détecter les secrets introduits par des conflits de fusion.

Workflows de déploiement sécurisés

Amener du code d’un pipeline vers un environnement de production en toute sécurité demande plus que simplement exécuter kubectl apply. GitLab prend en charge plusieurs stratégies de déploiement qui équilibrent rapidité et sûreté.

Portes manuelles

Utilisez le mot-clé when: manual pour créer des points d’approbation explicites dans votre pipeline. Un schéma courant consiste à déployer automatiquement en staging mais à exiger un clic manuel pour la production. Combiné aux environnements protégés et aux approbations de déploiement, cela crée un workflow de gestion des changements robuste.

deploy_production:
  stage: deploy
  environment:
    name: production
    deployment_tier: production
  when: manual
  only:
    - main

Déploiements canary

GitLab s’intègre à Kubernetes pour prendre en charge nativement les déploiements canary. En déployant d’abord sur un petit pourcentage de pods et en surveillant les taux d’erreur, vous pouvez détecter les problèmes avant qu’ils n’affectent tous les utilisateurs. C’est un contrôle de sécurité autant que de fiabilité — un build compromis qui atteint le canary peut être détecté et annulé avant de se propager largement.

GitOps avec le GitLab Agent for Kubernetes

Le GitLab Agent for Kubernetes (anciennement appelé KAS) permet un modèle GitOps de type pull. Au lieu d’accorder à votre pipeline CI un accès direct à l’API Kubernetes, l’agent qui s’exécute dans le cluster récupère l’état désiré depuis un dépôt Git. Cela élimine le besoin d’identifiants kubeconfig à longue durée de vie dans les variables CI et réduit considérablement la surface d’attaque.

Bonnes pratiques de sécurité des déploiements :

Ne stockez jamais un kubeconfig ou des identifiants cloud dans des variables CI non protégées. Utilisez la fédération OIDC ou le GitLab Agent.
Mettez en place une automatisation du rollback — si les health checks échouent après le déploiement, revenez automatiquement au dernier état sain connu.
Signez les images de conteneurs et vérifiez les signatures avant le déploiement avec Cosign ou Notary.
Utilisez des tags immuables ou des références par digest pour les images de conteneurs afin de prévenir les attaques basées sur les tags.

Erreurs de configuration courantes

Même les équipes qui comprennent les concepts de sécurité de GitLab CI tombent souvent dans ces pièges :

1. Variables non protégées contenant des secrets de production

C’est l’erreur de configuration la plus courante et la plus dangereuse. Si un mot de passe de base de données de production est stocké dans une variable non protégée, n’importe quel développeur peut créer une branche, ajouter une étape echo $DB_PASSWORD et le lire depuis le log du job. Protégez et masquez toujours les secrets de production.

2. Runners partagés trop permissifs

Les runners partagés avec montage du socket Docker (/var/run/docker.sock) ou en mode --privileged donnent aux jobs le contrôle total de l’hôte. Un job malveillant peut s’échapper du conteneur, accéder aux données d’autres jobs ou compromettre le runner lui-même.

3. Périmètre du CI_JOB_TOKEN non restreint

Sans périmètre de token explicite, un job compromis dans un projet à faible valeur peut utiliser son CI_JOB_TOKEN pour accéder aux API et aux registres de projets à forte valeur. Activez les restrictions de périmètre de token sur chaque projet.

4. Absence de validation de pipeline sur les merge requests

Si la réussite des pipelines n’est pas exigée avant la fusion, les attaquants peuvent pousser du code qui contourne les analyses de sécurité. Activez le paramètre « Pipelines must succeed ».

5. Secrets codés en dur dans .gitlab-ci.yml

Cela paraît évident, mais des identifiants apparaissent encore dans les fichiers YAML de pipeline avec une fréquence alarmante. Utilisez des variables CI, des gestionnaires de secrets externes ou OIDC — n’insérez jamais un secret en clair.

6. Aucune journalisation d’audit ni surveillance

GitLab génère des événements d’audit pour les modifications de configuration CI/CD, mais de nombreuses organisations n’envoient pas ces logs vers un SIEM et ne configurent pas d’alertes. Sans surveillance, des compromissions peuvent passer inaperçues pendant des semaines.

7. Enregistrements de runners obsolètes

Des runners enregistrés il y a des mois puis oubliés peuvent avoir des configurations obsolètes, des systèmes d’exploitation non corrigés ou un accès aux projets trop large. Auditez et nettoyez régulièrement les runners obsolètes.

Checklist de mise en œuvre

Utilisez cette checklist pour durcir systématiquement votre environnement GitLab CI/CD. Priorisez les éléments en fonction de votre modèle de menace et de vos exigences de conformité.

Variables et secrets

☐ Tous les secrets de production sont marqués comme protégés et masqués.
☐ Des variables à portée d’environnement sont utilisées pour séparer les identifiants de staging et de production.
☐ Aucun secret n’est codé en dur dans .gitlab-ci.yml ou dans les fichiers du dépôt.
☐ Le calendrier de rotation des secrets est documenté et appliqué.
☐ Un gestionnaire de secrets externe (HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager) est intégré pour les identifiants les plus sensibles.

Runners

☐ Les runners de déploiement en production sont à portée de projet et protégés.
☐ Les runners partagés utilisent des exécuteurs éphémères et conteneurisés.
☐ Le mode privilégié est désactivé ou restreint à des groupes de runners dédiés.
☐ Les tokens d’enregistrement des runners sont renouvelés régulièrement.
☐ Les enregistrements de runners obsolètes sont audités et supprimés chaque trimestre.

Environnements et déploiements

☐ Les environnements de production et de staging sont protégés.
☐ Les approbations de déploiement sont activées pour la production (Premium/Ultimate).
☐ Des portes manuelles sont configurées pour les déploiements en production.
☐ Les procédures de rollback sont documentées et testées.
☐ Les images de conteneurs sont signées et vérifiées avant le déploiement.

Tokens et authentification

☐ CI_JOB_TOKEN a un périmètre restreint sur chaque projet.
☐ OIDC id_tokens sont utilisés à la place des identifiants cloud statiques.
☐ Les politiques de confiance IAM du cloud valident le chemin du projet, la référence et les claims d’environnement.
☐ Les personal access tokens ayant la portée CI/CD sont réduits au minimum et audités.

Paramètres des pipelines et des merge requests

☐ « Pipelines must succeed » est activé pour toutes les branches protégées.
☐ Les templates de détection de secrets et SAST sont inclus dans le pipeline par défaut.
☐ Les push rules rejettent les commits contenant des motifs de secrets connus.
☐ .gitlab-ci.yml — toute modification nécessite l’approbation de réviseurs sécurité.
☐ Les pipelines de fork sont mis en bac à sable ou nécessitent une approbation manuelle.

Surveillance et conformité

☐ Les événements d’audit des modifications de configuration CI/CD sont envoyés vers un SIEM.
☐ Des alertes sont configurées pour les activités suspectes (par exemple, nouveaux enregistrements de runners, modifications de variables, déploiements inattendus).
☐ Les pipelines de conformité (Ultimate) imposent des jobs de sécurité obligatoires dans tous les projets.
☐ Des revues d’accès régulières couvrent les permissions des runners, l’accès aux variables et les déploiements d’environnements.

Pour une version imprimable et synthétique de ces recommandations, consultez notre cheat sheet de sécurité GitLab CI.

Lab pratique

Lire des articles sur la sécurité est important, mais c’est la pratique qui ancre les connaissances. Notre lab interactif vous guide pas à pas dans la sécurisation d’un vrai pipeline GitLab CI — configuration des variables protégées, périmètre des runners, mise en place des approbations d’environnement, et plus encore.

👉 Lab : sécuriser les pipelines GitLab CI — variables protégées, runners et environnements

Outils et ressources

Les outils et ressources suivants peuvent vous aider à évaluer et à améliorer la posture de sécurité de votre GitLab CI/CD :

Fonctionnalités de sécurité natives de GitLab

Security Dashboard — vue centralisée des vulnérabilités de tous les projets d’un groupe ou d’une instance.
Compliance Pipelines (Ultimate) — imposent des jobs CI obligatoires (comme la détection de secrets) que les mainteneurs de projet ne peuvent ni ignorer ni modifier.
Audit Events API — accès programmatique aux logs de modifications de configuration CI/CD pour l’intégration avec des plateformes SIEM externes.
Dependency Scanning — identifie les vulnérabilités connues dans les dépendances du projet. À combiner avec la détection de secrets pour une couverture complète de la chaîne d’approvisionnement.
Container Scanning — analyse les images Docker à la recherche de vulnérabilités au niveau du système d’exploitation et du langage avant qu’elles n’atteignent un registre.

Outils tiers et open source

Cimon — agent de sécurité runtime pour la CI/CD qui surveille et restreint les accès réseau et fichiers pendant l’exécution du pipeline.
StepSecurity Harden-Runner — conçu à l’origine pour GitHub Actions, mais les concepts (filtrage des sorties réseau, surveillance des processus) s’appliquent aussi aux runners GitLab.
HashiCorp Vault — gestionnaire de secrets standard du secteur, avec une intégration GitLab native via le mot-clé vault dans .gitlab-ci.yml.
Cosign — signature et vérification d’images de conteneurs. Intégrez-le à votre pipeline pour signer les images après le build et les vérifier avant le déploiement.
Trivy — scanner de vulnérabilités complet pour les conteneurs, les systèmes de fichiers et les dépôts Git. Léger et facile à intégrer dans GitLab CI.

Documentation et références

Conclusion

GitLab CI/CD est une plateforme DevSecOps puissante et intégrée — mais sa sécurité ne vaut que ce que vaut votre configuration. Les contrôles existent : variables protégées, périmètre des runners, approbations d’environnement, fédération OIDC, restrictions du CI_JOB_TOKEN, détection de secrets et portes de déploiement. Le défi est de les activer de manière cohérente et de les surveiller en continu.

Commencez par les éléments à plus fort impact : protégez et masquez tous les secrets de production, définissez le périmètre de vos runners, restreignez l’accès du CI_JOB_TOKEN et activez la détection de secrets dans chaque pipeline. Ajoutez ensuite OIDC pour l’authentification cloud, les approbations de déploiement pour les environnements de production et les pipelines de conformité pour une application à l’échelle de l’organisation.

La sécurité n’est pas une configuration ponctuelle — c’est une discipline continue. Passez en revue la posture de sécurité de vos pipelines chaque trimestre, auditez les contrôles d’accès, renouvelez les identifiants et restez à jour avec les fonctionnalités de sécurité en constante évolution de GitLab. Avec les pratiques de ce guide, vous obtiendrez un environnement GitLab CI/CD non seulement rapide et productif, mais véritablement sécurisé.

Prêt à mettre ces concepts en pratique ? Commencez par notre cheat sheet de sécurité GitLab CI pour une référence rapide, puis parcourez le lab pratique pour acquérir des automatismes. Et pour le contexte plus large de la gestion des identifiants sur toutes les plateformes CI/CD, explorez notre guide sur les identifiants de courte durée et la fédération d’identité de charge de travail.