Hardening CI/CD Pipeline

Définition

Le hardening CI/CD pipeline désigne l'ensemble des mesures techniques et organisationnelles visant à réduire la surface d'attaque des chaînes d'intégration et de déploiement continus. Il repose sur cinq piliers : l'exécution des tâches par des runners au moindre privilège, la centralisation des secrets dans des coffres dédiés, la signature cryptographique des artefacts, l'intégration de scans SAST/DAST dans le flux de build, et la protection des webhooks déclencheurs. Un pipeline durci garantit qu'aucun code, dépendance ou binaire non vérifié ne peut atteindre la production.

Pourquoi le pipeline est une cible de choix

Un serveur CI/CD concentre un pouvoir considérable : il détient les identifiants de déploiement vers le cloud, les clés de signature, les jetons d'accès aux registres d'images et souvent des droits d'écriture sur le dépôt source. Compromettre le pipeline revient à obtenir un accès administrateur sur toute la chaîne logicielle sans avoir à attaquer chaque environnement individuellement. C'est la logique des attaques sur la supply chain logicielle : injecter une modification en amont pour qu'elle soit distribuée légitimement, signée et déployée en aval.

La difficulté vient du fait que le pipeline exécute par conception du code non fiable : celui des développeurs, celui des dépendances tierces, et celui des fichiers de configuration eux-mêmes (.gitlab-ci.yml, Jenkinsfile, workflows GitHub Actions). Une pull request externe peut suffire à faire exécuter une commande arbitraire sur un runner privilégié.

Fonctionnement technique du durcissement

• Runners éphémères et isolés : chaque job s'exécute dans un conteneur ou une machine virtuelle créée pour l'occasion et détruite ensuite. On évite les runners partagés persistants, où un job malveillant peut lire le cache, les couches Docker ou les variables d'un job voisin. Le mode privileged de Docker et le montage de /var/run/docker.sock sont proscrits ; on leur préfère des builders sans démon comme kaniko ou buildah.
• Gestion des secrets : les identifiants ne sont jamais stockés en clair dans le dépôt ni dans les variables d'environnement du projet. Ils proviennent d'un coffre (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) ou, mieux, d'une fédération d'identité OIDC qui délivre un jeton de courte durée lié au dépôt, à la branche et à l'environnement cible. Cette approche supprime les secrets statiques à long terme.
• Signature et traçabilité des artefacts : chaque binaire, image de conteneur ou paquet est signé (Sigstore/cosign, GPG, Notary) et accompagné d'une SBOM au format CycloneDX ou SPDX. Une attestation de provenance conforme au référentiel SLSA documente qui a produit l'artefact, à partir de quel commit et avec quel builder. Les admission controllers Kubernetes refusent alors toute image non signée.
• Scans intégrés : analyse statique du code (SAST), analyse des dépendances (SCA) pour détecter les CVE connues, détection de secrets commités (gitleaks, trufflehog), scan des images de conteneurs (trivy, grype), et tests dynamiques (DAST) sur l'environnement de préproduction. Les résultats deviennent bloquants au-delà d'un seuil de criticité défini.
• Protection des webhooks : les points d'entrée déclenchant les builds sont authentifiés par signature HMAC (en-tête X-Hub-Signature-256), filtrés par liste d'adresses IP autorisées, exposés en HTTPS uniquement et protégés contre le rejeu. Un webhook non signé permet à un tiers de déclencher des builds arbitraires ou de saturer l'infrastructure.

Exemples concrets

L'attaque contre SolarWinds reste la référence : les attaquants ont modifié le processus de build pour injecter la porte dérobée Sunburst dans un binaire ensuite signé légitimement et distribué à des milliers de clients. Dans le cas de Codecov, un script d'upload altéré a exfiltré pendant plusieurs mois les variables d'environnement — donc les secrets — de tous les pipelines qui l'exécutaient. Plus récemment, la compromission d'actions GitHub populaires a montré qu'une référence à une action par tag mutable (@v3) plutôt que par empreinte de commit (@sha256:…) suffit à exécuter du code modifié rétroactivement.

Liens avec les autres concepts de sécurité

Le hardening CI/CD s'inscrit dans la démarche DevSecOps du shift left, qui déplace les contrôles de sécurité au plus tôt dans le cycle de développement. Il prolonge le principe de moindre privilège et l'architecture Zero Trust appliquée aux machines. Il touche également à la sécurité de la chaîne d'approvisionnement logicielle, exigence désormais formalisée par la directive NIS 2 et le Cyber Resilience Act européen, ainsi qu'aux contrôles de gestion des changements de l'ISO 27001 (annexe A.8.25 à A.8.32).

Bonnes pratiques

• Épingler toutes les dépendances et actions tierces par empreinte cryptographique, jamais par tag mobile.
• Séparer les pipelines de build et de déploiement : seul le second détient les droits sur la production, et il exige une validation manuelle.
• Restreindre les jetons GITHUB_TOKEN ou équivalents en lecture seule par défaut, en élargissant les permissions job par job.
• Interdire l'exécution de workflows privilégiés sur les pull requests issues de forks.
• Protéger les branches principales : revue obligatoire, commits signés, interdiction du force push.
• Journaliser l'intégralité des exécutions vers un SIEM et alerter sur toute modification d'un fichier de configuration de pipeline.
• Auditer régulièrement les runners auto-hébergés, souvent les maillons les plus faibles car rarement patchés.