CI/CD : sécurité des pipelines DevSecOps

Les pipelines CI/CD (Continuous Integration / Continuous Delivery) automatisent la compilation, les tests et le déploiement du code source vers les environnements de production. Dans un contexte de sécurité des pipelines DevSecOps, ces chaînes d'automatisation constituent une surface d'attaque critique. Un pipeline CI/CD typique orchestre des runners (agents d'exécution), des dépôts de code, des registres d'artefacts et des connexions directes aux environnements cloud ou on-premise. Cette position centrale en fait une cible de choix pour les attaques de type supply chain : compromettre un pipeline revient à compromettre l'ensemble du cycle de livraison logicielle. Les secrets d'authentification (tokens, clés API, credentials cloud) sont souvent injectés comme variables d'environnement dans les jobs, ce qui les expose à toute étape malveillante insérée dans le workflow. Les outils concernés incluent Jenkins, GitLab CI, GitHub Actions, CircleCI et ArgoCD. La compromission d'un pipeline permet à un attaquant d'exécuter du code arbitraire, d'exfiltrer des secrets, de modifier des artefacts binaires avant leur déploiement ou d'injecter des dépendances malveillantes directement dans les builds livrés aux utilisateurs finaux.

La détection d'activités malveillantes dans un pipeline CI/CD repose sur plusieurs niveaux de supervision. Côté logs SCM (Source Code Management), surveiller les modifications inattendues de fichiers de configuration de workflow (.github/workflows/*.yml, .gitlab-ci.yml, Jenkinsfile) constitue un premier signal fort. Les événements d'accès aux secrets (AWS CloudTrail, GCP Audit Logs, Azure Monitor) doivent déclencher des alertes lorsqu'une clé est utilisée depuis une IP inhabituelle ou un agent runner non référencé. Les SIEM comme Splunk ou Elastic doivent ingérer les logs des runners CI pour détecter des appels réseau sortants anormaux (curl, wget, nc) depuis les jobs de build. L'utilisation de solutions de secrets scanning en temps réel (Trufflehog, Gitleaks, Semgrep) sur chaque commit permet de détecter des credentials exposés avant leur propagation. Côté EDR, surveiller les processus enfants anormaux lancés par l'agent runner (par exemple un shell inattendu depuis un processus Java Jenkins). Les indicateurs de compromission incluent des artefacts dont le hash SHA256 diffère entre le build log et le registre, des modifications de dépendances non tracées dans le lockfile, et des connexions sortantes vers des domaines externes depuis l'environnement de build isolé.

En Red Team, l'exploitation des pipelines CI/CD suit plusieurs axes documentés. Le pipeline poisoning consiste à modifier un fichier de workflow dans une branche de pull request pour exécuter du code arbitraire dans le contexte privilégié du runner, technique exploitée via des forks malveillants sur GitHub Actions (vecteur pwn-request). L'injection de dépendances (dependency confusion) abuse des registres privés mal configurés : un package public portant le même nom qu'une dépendance interne sera résolu en priorité par npm, pip ou Maven si le scope n'est pas verrouillé. Le vol de secrets d'environnement est réalisable dès qu'un attaquant peut injecter une étape dans le pipeline : un simple appel curl vers un serveur C2 suffit à exfiltrer toutes les variables d'environnement du runner. Côté durcissement, les contre-mesures essentielles incluent : l'épinglage des actions tierces par hash de commit plutôt que par tag, la segmentation des runners avec des permissions IAM minimales (least privilege), l'activation de l'approbation obligatoire pour les workflows déclenchés par des forks externes, le chiffrement des secrets via des vaults dédiés (HashiCorp Vault, AWS Secrets Manager) plutôt que des variables CI natives, et l'audit régulier des permissions OIDC accordées aux pipelines sur les providers cloud.