Votre pipeline CI/CD peut disposer de contrôles de sécurité hermétiques — commits signés, dépendances épinglées, analyses SAST, signature d’images de conteneurs — mais tout cela ne sert à rien si le processus de déploiement lui-même est faible. Le déploiement est le point de jonction critique où la sécurité du pipeline rencontre la sécurité de la production. Un workflow de déploiement compromis peut contourner tous les contrôles en amont que vous avez mis en place, poussant du code malveillant directement dans l’environnement dont dépendent vos clients.
Ce guide explique comment construire des workflows de déploiement sécurisés de bout en bout : choisir le bon modèle de déploiement, appliquer des portes de validation et des approbations, vérifier les artefacts au moment du déploiement, déployer les changements de manière progressive, et maintenir une piste d’audit complète du commit à la production.
Modèles de Déploiement : Push-Based vs Pull-Based (GitOps)
La première décision architecturale qui façonne votre posture de sécurité en matière de déploiement est le choix entre un modèle push-based ou pull-based.
Déploiements Push-Based (pilotés par le CI)
Dans un modèle push-based traditionnel, le pipeline CI/CD construit l’artefact puis le pousse directement vers l’environnement cible. GitHub Actions déploie sur Kubernetes via kubectl apply, ou un job GitLab CI exécute helm upgrade contre un cluster. Le pipeline lui-même détient les identifiants d’accès à l’environnement de production.
Ce modèle est simple mais comporte un risque inhérent : le runner CI dispose d’un accès direct en écriture à la production. Si un attaquant compromet le pipeline — via une dépendance empoisonnée, une pull request malveillante ou un secret volé — il hérite immédiatement de cet accès à la production.
Déploiements Pull-Based (GitOps)
Dans un modèle pull-based ou GitOps, un contrôleur dédié s’exécutant à l’intérieur de l’environnement cible — tel que Flux ou ArgoCD — surveille un dépôt Git pour détecter les changements d’état souhaités. Lorsqu’un nouveau manifeste est commité (généralement par le pipeline CI mettant à jour un tag d’image), le contrôleur récupère le changement et réconcilie le cluster pour correspondre à l’état souhaité.
L’avantage en matière de sécurité est significatif. Le pipeline CI n’a jamais besoin d’identifiants directs vers le cluster de production. La surface d’attaque se réduit car l’agent de déploiement vit à l’intérieur du cluster et ne récupère que depuis une source connue. La détection de dérive est intégrée : si quelqu’un modifie manuellement une ressource, le contrôleur la ramène à l’état correspondant à Git.
Recommandation : Pour les charges de travail de production, privilégiez un modèle pull-based GitOps. Réservez les déploiements push-based aux environnements de développement et de staging où la rapidité prime sur le contrôle d’accès strict. Même dans les configurations push-based, appliquez rigoureusement le principe du moindre privilège aux identifiants de déploiement.
Portes de Déploiement : Approbations Manuelles et Environnements Protégés
Les pipelines automatisés sont rapides, mais le déploiement en production ne devrait pas se faire sans vérification humaine pour les changements à fort impact. Les portes de déploiement introduisent des points de contrôle qui nécessitent une approbation explicite avant qu’une release ne soit exécutée.
Environnements GitHub et Réviseurs Obligatoires
GitHub Actions prend en charge les Environments avec des règles de protection. Vous pouvez exiger qu’un ou plusieurs réviseurs approuvent un déploiement avant que le job ne s’exécute. Cela est configuré dans les paramètres du dépôt et appliqué au niveau de la plateforme — le code du pipeline ne peut pas le contourner.
# .github/workflows/deploy.yml
jobs:
deploy-production:
runs-on: ubuntu-latest
environment:
name: production
url: https://app.example.com
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Verify artifact signature
run: |
cosign verify \
--key cosign.pub \
ghcr.io/myorg/myapp:${{ github.sha }}
- name: Deploy to production
run: |
helm upgrade --install myapp ./chart \
--set image.tag=${{ github.sha }} \
--namespace production
Avec l’environnement production configuré pour exiger des réviseurs, ce job se met en pause et attend l’approbation avant d’exécuter toute étape. L’approbateur voit exactement quel commit et quelle exécution de workflow a déclenché le déploiement.
Environnements Protégés GitLab
GitLab propose des environnements protégés qui restreignent quels utilisateurs ou groupes peuvent déclencher des déploiements. Combinés avec des jobs manuels, cela crée un workflow d’approbation robuste.
# .gitlab-ci.yml
deploy_production:
stage: deploy
environment:
name: production
url: https://app.example.com
rules:
- if: $CI_COMMIT_BRANCH == "main"
when: manual
script:
- cosign verify --key cosign.pub $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
- helm upgrade --install myapp ./chart
--set image.tag=$CI_COMMIT_SHA
--namespace production
resource_group: production
La directive when: manual exige qu’un utilisateur clique sur « Play » dans l’interface GitLab. Le resource_group garantit qu’un seul déploiement s’exécute à la fois, évitant les conditions de concurrence.
Approbations via Slack et ChatOps
Pour les équipes qui vivent dans Slack, l’intégration des workflows d’approbation avec le chat offre de la visibilité et des temps de réponse rapides. Des outils comme Opsgenie, PagerDuty ou des bots Slack personnalisés peuvent publier une demande de déploiement dans un canal et attendre qu’un utilisateur autorisé approuve via un bouton ou une réaction. L’exigence clé est que le mécanisme d’approbation soit auditable et ne puisse pas être falsifié — utilisez des tokens d’application Slack vérifiés et journalisez chaque décision d’approbation.
Vérification des Artefacts au Moment du Déploiement
Signer les artefacts pendant la phase de build n’est que la moitié de l’équation. Vous devez vérifier ces signatures au moment du déploiement. Sinon, un attaquant qui obtient l’accès à votre registre peut remplacer une image signée par une image non signée ou re-signée malveillante.
Vérification Cosign Avant le Déploiement
Ajoutez une étape de vérification explicite dans votre pipeline de déploiement qui s’exécute avant toute commande de déploiement. Si la vérification échoue, le pipeline doit s’arrêter immédiatement.
# Vérifier la signature de l'image avant le déploiement
cosign verify \
--certificate-identity "https://github.com/myorg/myapp/.github/workflows/build.yml@refs/heads/main" \
--certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
ghcr.io/myorg/myapp@sha256:abc123...
# Vérifier la provenance SLSA
cosign verify-attestation \
--type slsaprovenance \
--certificate-identity "https://github.com/slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@refs/tags/v1.9.0" \
--certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
ghcr.io/myorg/myapp@sha256:abc123...
Contrôleurs d’Admission : Kyverno et Sigstore Policy Controller
La vérification au niveau du pipeline est bonne, mais elle peut être contournée si quelqu’un déploie directement sur le cluster en utilisant kubectl. Les contrôleurs d’admission appliquent la vérification au niveau du serveur API Kubernetes — aucune image non signée ne peut entrer dans le cluster, quelle que soit la méthode de soumission.
Kyverno est un moteur de politiques natif Kubernetes qui peut vérifier les signatures d’images et les attestations dans le cadre de son webhook d’admission :
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: require-signed-images
spec:
validationFailureAction: Enforce
background: false
rules:
- name: verify-signature
match:
any:
- resources:
kinds:
- Pod
verifyImages:
- imageReferences:
- "ghcr.io/myorg/*"
attestors:
- entries:
- keyless:
subject: "https://github.com/myorg/*"
issuer: "https://token.actions.githubusercontent.com"
attestations:
- type: https://slsa.dev/provenance/v1
conditions:
- all:
- key: "{{ builder.id }}"
operator: Equals
value: "https://github.com/slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@refs/tags/v1.9.0"
Le Sigstore Policy Controller (anciennement cosigned) offre des fonctionnalités similaires et est maintenu par le projet Sigstore. Il s’intègre étroitement aux workflows de signature keyless et constitue un choix solide si votre organisation s’est standardisée sur l’écosystème Sigstore.
La combinaison de la vérification au niveau du pipeline et du contrôle d’admission au niveau du cluster crée une défense en profondeur : même si une couche est contournée, l’autre intercepte les artefacts non autorisés.
Déploiements Progressifs : Canary, Blue-Green et Feature Flags
Déployer une nouvelle version sur 100 % du trafic instantanément représente un risque pour la sécurité et la fiabilité. Les stratégies de déploiement progressif vous permettent de détecter les problèmes — y compris les problèmes de sécurité — avant qu’ils n’affectent tous les utilisateurs.
Déploiements Canary
Un déploiement canary achemine un faible pourcentage du trafic (par exemple, 5 %) vers la nouvelle version tandis que la majorité continue d’atteindre la version stable. Si des métriques telles que les taux d’erreur, la latence ou les signaux de sécurité (connexions sortantes inattendues, escalades de privilèges élevées) se dégradent, le canary est automatiquement annulé.
Des outils comme Flagger (pour Kubernetes), AWS App Mesh et Istio automatisent l’analyse canary. Flagger, par exemple, peut être configuré pour surveiller des métriques Prometheus personnalisées et promouvoir ou annuler automatiquement :
apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
name: myapp
namespace: production
spec:
targetRef:
apiVersion: apps/v1
kind: Deployment
name: myapp
progressDeadlineSeconds: 600
service:
port: 8080
analysis:
interval: 1m
threshold: 5
maxWeight: 50
stepWeight: 10
metrics:
- name: request-success-rate
thresholdRange:
min: 99
interval: 1m
- name: request-duration
thresholdRange:
max: 500
interval: 1m
Déploiements Blue-Green
Les déploiements blue-green maintiennent deux environnements identiques. L’environnement « blue » exécute la version actuelle ; le « green » exécute la nouvelle. Le trafic est basculé d’un coup (généralement via un load balancer ou un changement DNS) après que l’environnement green a passé les vérifications de santé et la validation de sécurité. Si quelque chose tourne mal, le retour au blue est instantané.
L’avantage en matière de sécurité est un chemin de rollback propre et prévisible. Il n’y a pas d’état partiel à analyser, et la version précédente reste pleinement opérationnelle tout au long du déploiement.
Feature Flags comme Contrôles de Sécurité
Les feature flags découplent le déploiement de la release. Le code est déployé en production mais reste inactif derrière un flag. Cela donne aux équipes de sécurité un interrupteur d’urgence : si une fonctionnalité nouvellement publiée introduit une vulnérabilité ou se comporte de manière inattendue, elle peut être désactivée instantanément sans rollback complet. Des outils comme LaunchDarkly, Unleash et OpenFeature fournissent une gestion centralisée des flags avec des journaux d’audit indiquant qui a basculé quoi et quand.
Stratégies de Rollback
Chaque plan de déploiement doit inclure un plan de rollback. Quand les choses tournent mal — et elles tourneront mal — la rapidité et la fiabilité de votre rollback déterminent directement le rayon d’impact.
Rollback Automatique en Cas d’Échec du Health Check
Kubernetes prend nativement en charge le rollback via son contrôleur de déploiement. Si les nouveaux pods échouent aux sondes readiness ou liveness, le déploiement se bloque et peut être automatiquement inversé :
# Vérifier le statut du déploiement et effectuer un rollback si nécessaire
kubectl rollout status deployment/myapp --namespace production --timeout=300s
if [ $? -ne 0 ]; then
echo "Le déploiement a échoué, lancement du rollback"
kubectl rollout undo deployment/myapp --namespace production
exit 1
fi
Dans un modèle GitOps, le rollback signifie reverter le commit Git qui a introduit le changement. Le contrôleur détecte le revert et réconcilie le cluster vers l’état précédent. Cela préserve la piste d’audit complète dans Git.
Déploiements Immuables
Les déploiements immuables traitent chaque release comme une nouvelle instance jetable. Au lieu de mettre à jour les conteneurs en place, vous déployez un ensemble entièrement nouveau de ressources et décommissionnez les anciens. Cela élimine la dérive de configuration et garantit que ce qui a été testé est exactement ce qui s’exécute en production. Combinés aux digests d’images (plutôt qu’aux tags mutables comme latest), les déploiements immuables garantissent la reproductibilité binaire.
Séparation des Identités de Build et de Déploiement
L’une des améliorations de sécurité les plus impactantes que vous puissiez apporter est de garantir que l’identité utilisée pour construire les artefacts est différente de celle utilisée pour les déployer. Cela limite le rayon d’impact d’une compromission dans l’une ou l’autre phase.
Identifiants Différents
Le pipeline de build devrait avoir des identifiants pour pousser des images vers un registre et les signer — mais aucun accès à l’infrastructure de production. Le pipeline de déploiement (ou le contrôleur GitOps) devrait avoir des identifiants pour récupérer les images et appliquer les manifestes — mais aucun accès aux dépôts de code source ou aux clés de signature.
En pratique, cela signifie utiliser des comptes de service séparés, des rôles IAM ou des claims OIDC pour chaque phase. Sur AWS, le rôle de build pourrait avoir des permissions pour le push ECR et la signature KMS, tandis que le rôle de déploiement a des permissions pour EKS et Secrets Manager mais pas pour le push ECR.
Runners Différents
Poussez la séparation plus loin en exécutant les jobs de build et de déploiement sur des runners physiquement différents. Les jobs de build s’exécutent sur des runners éphémères et polyvalents. Les jobs de déploiement s’exécutent sur des runners dédiés et renforcés qui se trouvent dans un périmètre réseau plus proche de l’environnement de production. Cela empêche un runner de build compromis de pivoter vers la production.
Pour un traitement plus approfondi de la séparation des identités et des principes de moindre privilège dans le CI/CD, consultez notre guide sur la Séparation des Responsabilités et le Moindre Privilège dans les Pipelines CI/CD.
Gels de Déploiement et Fenêtres de Changement
Chaque moment n’est pas propice au déploiement. Les gels de déploiement — des périodes durant lesquelles les changements en production sont interdits — réduisent les risques pendant les événements à fort trafic, les vacances, les transitions d’astreinte ou la réponse active aux incidents.
Implémentez les gels au niveau de la plateforme, pas seulement comme un accord d’équipe. Les Environments GitHub prennent en charge les politiques de branches de déploiement et les temporisateurs d’attente. GitLab permet les gels de déploiement configurés via l’interface ou l’API avec des planifications de type cron. Pour les workflows basés sur Kubernetes, vous pouvez appliquer les gels avec une politique OPA/Gatekeeper ou Kyverno qui rejette les déploiements pendant des fenêtres temporelles spécifiques.
# Politique Kyverno pour appliquer un gel de déploiement
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: deployment-freeze
spec:
validationFailureAction: Enforce
background: false
rules:
- name: block-deployments-during-freeze
match:
any:
- resources:
kinds:
- Deployment
namespaces:
- production
preconditions:
all:
- key: "{{ time_now() }}"
operator: GreaterThan
value: "2026-03-27T00:00:00Z" # Début du gel
- key: "{{ time_now() }}"
operator: LessThan
value: "2026-03-30T00:00:00Z" # Fin du gel
validate:
message: "Les déploiements en production sont gelés jusqu'au 30 mars. Contactez l'équipe plateforme pour les exceptions d'urgence."
deny: {}
Documentez un processus d’exception pour les correctifs de sécurité urgents qui doivent être déployés pendant un gel, incluant qui peut autoriser l’exception et comment elle est journalisée.
Piste d’Audit : Lier les Déploiements aux Commits, Approbateurs et Exécutions de Pipeline
Un workflow de déploiement sécurisé produit une piste d’audit complète et inaltérable. Pour chaque déploiement en production, vous devriez pouvoir répondre à : Qu’est-ce qui a été déployé ? Qui l’a approuvé ? Quel pipeline l’a construit ? À quel commit cela remonte-t-il ?
Journaux d’Audit au Niveau de la Plateforme
AWS CloudTrail enregistre les appels API vers EKS, ECS et Lambda, y compris qui a initié le déploiement et depuis quelle source. Les journaux d’audit GCP fournissent une couverture similaire pour GKE et Cloud Run. Assurez-vous que ces journaux sont envoyés vers un magasin de logs centralisé et immuable (tel qu’un bucket S3 dédié avec verrouillage d’objet ou un SIEM) où ils ne peuvent pas être falsifiés par un attaquant ayant compromis l’environnement de déploiement.
Traçabilité au Niveau du Pipeline
Annotez les ressources Kubernetes avec des métadonnées de déploiement afin de pouvoir remonter d’un pod en cours d’exécution jusqu’à la source exacte :
# Inclure dans votre chart Helm ou overlay Kustomize
metadata:
labels:
app.kubernetes.io/version: "{{ .Values.image.tag }}"
annotations:
deploy.example.com/commit-sha: "{{ .Values.commitSha }}"
deploy.example.com/pipeline-url: "{{ .Values.pipelineUrl }}"
deploy.example.com/approved-by: "{{ .Values.approvedBy }}"
deploy.example.com/deployed-at: "{{ now | date \"2006-01-02T15:04:05Z\" }}"
Dans GitHub Actions, transmettez ces valeurs via le workflow de déploiement :
- name: Deploy with traceability
run: |
helm upgrade --install myapp ./chart \
--set image.tag=${{ github.sha }} \
--set commitSha=${{ github.sha }} \
--set pipelineUrl="https://github.com/${{ github.repository }}/actions/runs/${{ github.run_id }}" \
--set approvedBy="${{ github.actor }}" \
--namespace production
Surveillance Post-Déploiement
Le déploiement ne s’arrête pas quand la nouvelle version est en cours d’exécution. La surveillance post-déploiement ferme la boucle de rétroaction et détecte les problèmes que les vérifications pré-déploiement ont manqués.
Détection d’Anomalies
Établissez des métriques de référence pour le comportement normal de l’application : taux de requêtes, taux d’erreurs, percentiles de latence, utilisation CPU/mémoire et modèles de connexions réseau. Après chaque déploiement, comparez les métriques actuelles avec la référence. Des outils comme Prometheus + Alertmanager, Datadog et Grafana Alerting peuvent déclencher des alertes lorsque les métriques post-déploiement dévient au-delà des seuils.
Du point de vue de la sécurité, portez une attention particulière aux connexions réseau sortantes inattendues, aux nouveaux processus lancés à l’intérieur des conteneurs, aux appels système élevés et aux augmentations soudaines des échecs d’authentification. Ceux-ci peuvent indiquer qu’un artefact compromis a traversé le pipeline.
Métriques DORA pour la Sécurité
Les quatre métriques DORA — fréquence de déploiement, délai de mise en production des changements, taux d’échec des changements et temps moyen de récupération — sont généralement utilisées pour mesurer la performance DevOps. Elles sont tout aussi précieuses pour la sécurité :
- Fréquence de déploiement indique à quelle fréquence vous pouvez livrer des correctifs de sécurité. Une fréquence plus élevée signifie une remédiation plus rapide.
- Délai de mise en production des changements mesure la rapidité avec laquelle un correctif de sécurité passe du commit à la production. Des délais longs signifient des fenêtres d’exposition prolongées.
- Taux d’échec des changements suit la fréquence à laquelle les déploiements causent des incidents. Un taux élevé suggère des tests ou une vérification inadéquats — un problème de sécurité.
- Temps moyen de récupération (MTTR) mesure la rapidité avec laquelle vous pouvez effectuer un rollback ou remédier à un mauvais déploiement. Un MTTR bas limite le rayon d’impact de tout incident, y compris une brèche de sécurité.
Suivez ces métriques par environnement et corrélez-les avec les événements de sécurité. Si votre taux d’échec des changements augmente après l’adoption d’un nouveau modèle de déploiement, enquêtez avant que cela ne devienne un risque de sécurité.
Synthèse : Un Pipeline de Déploiement Sécurisé Complet
Voici un workflow GitHub Actions complet qui intègre les pratiques discutées ci-dessus — vérification des artefacts, approbations basées sur les environnements, traçabilité du déploiement et rollback automatique :
# .github/workflows/secure-deploy.yml
name: Secure Deployment
on:
workflow_run:
workflows: ["Build and Sign"]
types: [completed]
branches: [main]
jobs:
verify-and-deploy:
runs-on: ubuntu-latest
if: ${{ github.event.workflow_run.conclusion == 'success' }}
environment:
name: production
url: https://app.example.com
permissions:
id-token: write
contents: read
steps:
- name: Checkout manifests
uses: actions/checkout@v4
- name: Install cosign
uses: sigstore/cosign-installer@v3
- name: Verify image signature (keyless)
run: |
IMAGE="ghcr.io/myorg/myapp@${{ github.event.workflow_run.head_sha }}"
cosign verify \
--certificate-identity "https://github.com/myorg/myapp/.github/workflows/build.yml@refs/heads/main" \
--certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
"$IMAGE"
- name: Verify SLSA provenance
run: |
IMAGE="ghcr.io/myorg/myapp@${{ github.event.workflow_run.head_sha }}"
cosign verify-attestation \
--type slsaprovenance \
--certificate-identity "https://github.com/slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@refs/tags/v1.9.0" \
--certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
"$IMAGE"
- name: Configure AWS credentials (deploy role)
uses: aws-actions/configure-aws-credentials@v4
with:
role-to-assume: arn:aws:iam::123456789012:role/deploy-production
aws-region: us-east-1
- name: Deploy to EKS
run: |
aws eks update-kubeconfig --name production-cluster
helm upgrade --install myapp ./chart \
--set image.tag=${{ github.event.workflow_run.head_sha }} \
--set commitSha=${{ github.event.workflow_run.head_sha }} \
--set pipelineUrl="https://github.com/${{ github.repository }}/actions/runs/${{ github.run_id }}" \
--set approvedBy="${{ github.actor }}" \
--namespace production \
--wait --timeout 300s
- name: Verify rollout
run: |
kubectl rollout status deployment/myapp \
--namespace production --timeout=300s
- name: Rollback on failure
if: failure()
run: |
echo "Le déploiement a échoué — lancement du rollback"
kubectl rollout undo deployment/myapp --namespace production
echo "::error::Déploiement annulé suite à un échec"
Et le pipeline GitLab CI équivalent avec des contrôles similaires :
# .gitlab-ci.yml
stages:
- verify
- deploy
- validate
verify_artifact:
stage: verify
image: bitnami/cosign:latest
script:
- cosign verify
--certificate-identity "https://gitlab.com/myorg/myapp//.gitlab-ci.yml@refs/heads/main"
--certificate-oidc-issuer "https://gitlab.com"
$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
rules:
- if: $CI_COMMIT_BRANCH == "main"
deploy_production:
stage: deploy
environment:
name: production
url: https://app.example.com
resource_group: production
needs: [verify_artifact]
rules:
- if: $CI_COMMIT_BRANCH == "main"
when: manual
script:
- aws eks update-kubeconfig --name production-cluster
- helm upgrade --install myapp ./chart
--set image.tag=$CI_COMMIT_SHA
--set commitSha=$CI_COMMIT_SHA
--set pipelineUrl=$CI_PIPELINE_URL
--set approvedBy=$GITLAB_USER_LOGIN
--namespace production
--wait --timeout 300s
validate_deployment:
stage: validate
needs: [deploy_production]
script:
- kubectl rollout status deployment/myapp --namespace production --timeout=300s
after_script:
- |
if [ "$CI_JOB_STATUS" == "failed" ]; then
echo "Rollback du déploiement"
kubectl rollout undo deployment/myapp --namespace production
fi
rules:
- if: $CI_COMMIT_BRANCH == "main"
Résumé et Guides Connexes
Les workflows de déploiement sécurisés nécessitent une défense en profondeur à chaque phase : choisir le bon modèle de déploiement, appliquer des portes de validation et des approbations, vérifier les artefacts à la frontière du cluster, déployer les changements de manière progressive, maintenir des chemins de rollback propres, séparer les identités de build et de déploiement, respecter les fenêtres de changement et tout journaliser. Aucun contrôle unique n’est suffisant à lui seul. La combinaison de la vérification au niveau du pipeline, de l’application par les contrôleurs d’admission, des déploiements progressifs et de la journalisation d’audit complète crée un processus de déploiement à la fois rapide et sécurisé.
Continuez à développer vos connaissances en CI/CD sécurisé avec ces guides connexes :
- Séparation des Responsabilités et Moindre Privilège dans les Pipelines CI/CD — Plongée approfondie dans la séparation des identités, les identifiants à portée limitée et le principe du moindre privilège à travers votre pipeline.
- Modèles Défensifs et Atténuations pour les Attaques de Pipelines CI/CD — Contre-mesures pratiques pour les vecteurs d’attaque les plus courants ciblant les systèmes CI/CD.
