Sécurité Supply Chain & CI/CD : du commit à la production en 2 semaines

Le contexte

Le pipeline CI/CD est devenu le chemin le plus court vers la production, pour vos équipes comme pour un attaquant. Une action GitHub tierce compromise, un pull_request_target mal compris, un token GITHUB_TOKEN avec write-all, un runner self-hosted partagé entre repos publics et privés, un secret dans un log de build : chaque année, des incidents publics rappellent que la supply chain est le maillon que personne n’audite.

Côté déploiement, ArgoCD et Kubernetes ajoutent leur propre surface : un ArgoCD exposé avec l’admin local activé, des AppProject sans restriction de destination, des secrets en clair dans Git, aucune admission policy, des images latest non signées qui tournent en prod.

Cet audit couvre la chaîne complète, du dépôt au cluster, sur 2 semaines. L’objectif : qu’un compromis d’un développeur, d’une dépendance ou d’un runner ne se transforme pas en compromis de la production.

Pour qui

• Une équipe qui livre en production via GitHub Actions (ou GitLab CI) plusieurs fois par semaine
• Des clusters Kubernetes (EKS, AKS, GKE ou auto-hébergés) déployés via ArgoCD, Flux ou Helm
• Des runners self-hosted, des actions tierces non pinnées, des secrets partagés entre environnements
• Une exigence client ou réglementaire sur la traçabilité des builds (SOC2, NIS2, DORA, SLSA)
• Un doute sur ce qu’un développeur, un token ou une dépendance compromis pourraient réellement faire

Ce qui est livré

Semaine 1 — Dépôts, workflows et runners

• Inventaire des dépôts, workflows, actions tierces, runners et registries
• Revue GitHub Actions : permissions du GITHUB_TOKEN, triggers dangereux (pull_request_target, workflow_run), injection via ${{ }}, pinning par SHA, environnements et approvals
• Authentification cloud depuis la CI : migration des clés statiques vers OIDC, conditions sub strictes, rôles par environnement
• Runners : isolation, éphémérité, accès réseau, partage entre repos, secrets exposés
• Gestion des secrets : où ils vivent, qui les lit, rotation, fuites dans les logs et l’historique Git
• Protection des branches, revues obligatoires, signature des commits, règles de merge

Semaine 2 — Artefacts, GitOps et runtime

• Images : scan des vulnérabilités priorisé par exploitabilité, images de base, utilisateurs root, SBOM, signature et attestation (Sigstore/cosign)
• Registries : politiques de rétention, immutabilité des tags, accès pull/push
• ArgoCD ou Flux : exposition, SSO et RBAC, AppProject et destinations, secrets (External Secrets, Sealed Secrets, SOPS), détection de drift, permissions du service account
• Kubernetes : RBAC, admission policies (Kyverno, OPA Gatekeeper ou Pod Security Admission), network policies, secrets, service accounts et IRSA/Workload Identity
• Plan d’action 30/60/90 jours priorisé par exploitabilité, avec workflows, policies et manifests corrigés fournis en exemple

Ce qui n’est pas inclus

• L’implémentation complète des recommandations (relève du retainer ou d’une mission spécialisée)
• La revue de sécurité applicative du code lui-même (SAST approfondi, revue manuelle)
• La posture globale des comptes cloud (IAM, réseau, données), objet de l’Audit Sécurité Cloud
• La migration d’un outil CI/CD vers un autre

Format et délais

Forfait fixé après un appel de cadrage de 15 minutes, 2 semaines entre kick-off et remise du livrable. Le périmètre est indépendant du cloud sous-jacent : AWS, Azure, GCP ou on-premise.

L’accès se fait en lecture seule sur l’organisation GitHub, les clusters et les registries, révoqué le dernier jour.

Pourquoi Distribuée

DevSecOps senior, 10 ans de CI/CD et de plateformes Kubernetes en environnement régulé. 6 certifications AWS dont DevOps Engineer Professional et Security Specialty. L’angle Distribuée sur la supply chain : traiter le pipeline comme un système de production à part entière, avec les mêmes exigences d’identité, de traçabilité et de moindre privilège.