Sécuriser votre CI/CD : au-delà des bases

De plus en plus d’incidents démarrent dans la build et le déploiement : token CI volé, workflow modifié pour exfiltrer des secrets, runner compromis, dépendance malveillante. Une CI/CD “sécurisée” n’est pas une pile de scanners : c’est la maîtrise de la chaîne qui transforme du code en production, avec une identité forte, des privilèges minimaux, et des artefacts vérifiables.

Ce que “CI/CD sécurisée” veut dire

L’objectif est de contrôler comment quelque chose arrive en prod :

• Identité forte (humains et machines)
• Moindre privilège et tokens courte durée
• Intégrité des artefacts (build une fois, promotion fiable)
• Promotions & rollbacks contrôlés
• Auditabilité : qui a changé quoi, qui a approuvé, qu’est-ce qui a été déployé

Commencer par un mini threat model (30 minutes)

Avant de changer les outils, alignez-vous sur les menaces les plus probables :

• Vol d’identifiants : token exposé dans les logs, artefacts ou workspace du runner
• Manipulation de workflow : PR qui modifie le pipeline pour récupérer des secrets
• Runner compromis : runners partagés, état persistant, image non patchée
• Dépendances : version malveillante, typosquatting, chaîne d’outils non maîtrisée
• Artefact altéré : ce qui a été construit n’est pas ce qui a été déployé

Votre but est de réduire le blast radius et d’augmenter la confiance dans chaque release.

Quick wins (souvent faisables en une semaine)

1) Éliminer les clés longue durée dans la CI

Les clés cloud statiques et partagées sont un anti-pattern classique.

• Préférez OIDC + rôles/token éphémères
• Scopez les credentials par environnement (staging vs prod)
• Auditez l’accès aux secrets et faites de la rotation régulière
• Empêchez les forks / PR non fiables d’accéder aux secrets

2) Exiger des reviews pour les changements de workflow

Votre pipeline est du code critique.

• CODEOWNERS / review obligatoire sur .github/workflows/* (ou équivalent)
• Restreindre qui peut approuver ces changements
• Empêcher l’auto-approbation sur les dépôts sensibles

3) Épingler et vérifier les actions / dépendances

Exemple GitHub Actions :

• Épingler les actions par SHA, pas par tag flottant
• Auditer les étapes à fort privilège (auth cloud, deploy, signing)
• Prioriser des composants maintenus (signaux de maintenance clairs)

4) Durcir les runners

Les runners sont souvent le point faible le plus sous-estimé.

• Utiliser des runners éphémères (nouvelle instance par job) si possible
• Minimiser la surface : outils nécessaires uniquement, images patchées
• Éviter l’accumulation de secrets sur disque / workspace
• Éviter les mounts de credentials trop larges

5) Mettre des protections d’environnement

Rendre difficile le “mauvais déploiement” :

• Séparer build et deploy
• Approvals pour prod quand c’est approprié
• Checks requis avant prod (tests, policy, scans)
• Rollback testé et documenté (pas “à l’instinct”)

Au-delà des scanners : intégrité et provenance

Les scanners aident, mais ne garantissent pas que l’artefact déployé correspond au code revu.

Provenance

Répond à : “Quel code, quels inputs, quel builder, quel résultat ?”

• SHA commit, lockfiles, image builder, configuration de build
• Attestations stockées avec l’artefact (ou dans un système dédié)

Intégrité des artefacts

Répond à : “L’artefact a-t-il été modifié ?”

• Signer les images (ou équivalent) et vérifier au moment du déploiement
• Promouvoir le même artefact entre environnements (pas de rebuild)

Checklist CI/CD sécurité (comme roadmap)

Identité & accès

• SSO + MFA pour Git et tooling critique
• Distinction claire humains vs machines
• Secrets accessibles uniquement à des rôles nécessaires
• Moindre privilège par environnement

Secrets

• Pas de clés statiques cloud dans la CI (préférer OIDC)
• Secrets jamais imprimés dans les logs
• Accès aux secrets audité et gouverné

Supply chain

• Lockfiles requis et revus
• Actions/dépendances épinglées et réévaluées périodiquement
• Mises à jour auto avec garde-fous (tests + approvals)

Build & release

• Build une fois, artefact immutable
• Promotion de l’artefact (pas de rebuild par environnement)
• Vérification d’intégrité/signature avant prod

Change control

• Revue obligatoire sur workflow et infra
• Approvals explicites pour prod + checks requis
• Rollback “first-class” et testé

Pièges fréquents

• “On a ajouté des scanners, donc c’est bon.” Non : la sécurité est un système d’exploitation.
• Tokens CI trop permissifs (écriture repo, release, accès cloud large).
• Runners partagés avec état persistant.
• Déploiements manuels qui contournent les checks en situation d’urgence.

Besoin d’un pipeline durci end-to-end ?

Si vous voulez une CI/CD robuste avec promotions fiables et rollback maîtrisé, voir Mise en place & durcissement CI/CD.