« Spoiler : c’est pas gagné. »
– Un DevOps un jour, tous les RSSI depuis.
🧪 CI/CD : pour livrer plus vite… ou exposer plus vite ?
La CI/CD, c’est un peu comme une Formule 1 : ça va très vite, ça impressionne tout le monde, mais si le pilote oublie de freiner, c’est le mur assuré.
Et spoiler : en cybersécurité, le mur, c’est souvent l’exploitation d’un pipeline mal verrouillé.
Alors que les DSI investissent dans des firewalls next-gen et que les SOC traquent le moindre nmap, le vrai gruyère est parfois juste là, dans un .yml glissé dans un repo GitHub.
Bienvenue dans l’univers merveilleux des pipelines CI/CD, où :
- les tokens secrets se baladent en clair,
- les runners ont les droits d’un ministre,
- et le stagiaire peut publier en prod… par inadvertance.
📦 Petit rappel pour les nouveaux venus : CI/CD, késako ?
CI (Intégration Continue) : automatiser les tests et la construction du code dès qu’un changement est poussé.
CD (Déploiement Continu) : automatiser la mise en production de ce code validé.
🔧 Outils populaires : GitHub Actions, GitLab CI, Jenkins, CircleCI, TravisCI, etc.
🔓 Où ça pète ? (et souvent violemment)
1. Secrets dans les variables d’environnement
AWS_SECRET_ACCESS_KEY: "oh_non_pas_ca_123"
Un classique : les secrets codés en dur dans les pipelines ou dans les variables d’environnement accessibles par n’importe quel job.
➡️ Résultat : exfiltration facile, surtout via une PR malveillante.
2. Droits trop larges sur les runners
Les runners partagés qui peuvent tout faire (et le font) sont une aubaine pour un attaquant.
➡️ Jenkins exposé sur Internet ? C’est Noël avant l’heure.
3. Mauvaise gestion des dépendances
Utiliser npm install sans vérification, c’est comme laisser ta porte d’entrée ouverte avec un panneau « pas de mot de passe ici ».
➡️ Attaques par supply chain garanties.
Voir notre article : Gestion des identités non humaines
4. Repos publics avec des workflows secrets
“Mais c’est sur GitHub, donc c’est safe, non ?”
Ah, non. L’accès en lecture suffit pour reverse-engineerer les workflows et préparer une attaque ciblée.
Voir notre article : Banana Squad & Co
🧠 Le savais-tu ? (Encadré pédagogique)
Runner : machine (ou conteneur) qui exécute le pipeline (build, test, déploiement).
Secret : variable sensible (token, mot de passe, clé SSH).
Token GitHub Actions : jeton auto-généré par GitHub pour chaque job ; à manipuler comme du nitroglycérine.
☣️ Exemples d’incidents réels (pour bien dormir la nuit)
- TravisCI (2022) : fuite massive de tokens d’accès dans les logs publics.
👉 Rapport de HackerOne :
https://blog.aquasec.com/travis-ci-security-incident - CircleCI (2023) : compromission de session développeur → exfiltration de secrets → rotation forcée.
👉 Incident post-mortem officiel :
https://circleci.com/blog/january-4-2023-security-alert/ - SolarWinds (2020) : modification d’un composant dans le pipeline → backdoor massivement diffusée.
👉 Analyse technique Microsoft :
https://www.microsoft.com/security/blog/2020/12/13/analyzing-solorigate-malware-attack/ - GitHub Actions : des chercheurs ont démontré comment injecter du code malicieux via des
pull_request_targetmal configurés.
👉 Recherche de securitylab.github.com :
https://securitylab.github.com/research/github-actions-untrusted-input/
🧱 Comment sécuriser (sans tout casser)
✅ Utilise un Secrets Manager (Vault, AWS Secrets, Doppler…)
Et pas des
secrets .GITHUB_TOKENqui traînent dans tous les jobs.
✅ Active le principe de least privilege
Ton pipeline n’a pas besoin d’accéder à toute ton infra pour faire un npm build.
✅ Isole tes environnements
Un workflow de test ne devrait jamais pouvoir déployer en prod.
✅ Audite régulièrement ton pipeline
Linte ton YAML, scanne les dépendances (trivy, npm audit, snyk).
✅ Vérifie ce que tu merges
Un pull_request_target mal sécurisé peut être exploité pour injecter du code malicieux.
🧰 Outils de sécurité et bonnes pratiques CI/CD
OWASP CI/CD Security Guidelines
👉 Guide complet (en anglais, très clair) :
https://owasp.org/www-project-cicd-security-guideline/
Hardening GitHub Actions (GitHub Docs)
👉 Conseils officiels GitHub pour sécuriser ses workflows :
https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions
Snyk – Analyse des dépendances (gratuite)
👉 Audit des vulnérabilités dans le code et les libs :
https://snyk.io
Trivy (scanner open source de vulnérabilités)
👉 GitHub officiel du projet AquaSec :
https://github.com/aquasecurity/trivy
Secrets detection avec Gitleaks
👉 Super outil pour détecter les secrets dans les repos :
https://github.com/gitleaks/gitleaks
📦 Vault & gestion des secrets
HashiCorp Vault (gestion de secrets)
👉 Page officielle du projet :
https://www.vaultproject.io/
AWS Secrets Manager
👉 Documentation officielle :
https://docs.aws.amazon.com/secretsmanager/
🔐 Exemple : pipeline GitHub Actions (presque) blindé
yaml
name: Build and Deploy
on:
push:
branches: [ "main" ]
jobs:
build:
runs-on: ubuntu-latest
permissions:
contents: read
id-token: write # Pour OIDC (auth sans secret)
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: '20'
- name: Install dependencies
run: npm ci
- name: Run tests
run: npm test
deploy:
needs: build
runs-on: ubuntu-latest
environment:
name: production
url: https://monapp.exemple.com
permissions:
contents: read
deployments: write
steps:
- name: Deploy via OIDC
uses: some-deploy-action
with:
oidc_token: ${{ steps.auth.outputs.id_token }}
✅ Ce qu’on aime ici :
- Permissions minimales par job
- Secrets non exposés directement (utilisation d’OIDC)
- Déploiement conditionné à la réussite des tests
🎯 Jenkins : même combat
Jenkins est une merveille d’automatisation… et une plaie si mal sécurisée.
- Désactive les builds anonymes
- Ne stocke pas de secrets dans
credentials.xml - Évite les plugins non maintenus
- Isole les agents dans des environnements dédiés
- Évite de faire tourner Jenkins en tant que root (non, vraiment)
🖼️ pipeline sécurisé vs pipeline kamikaze
🎤 En conclusion
La CI/CD, c’est super.
Mais ce n’est pas parce que c’est automatisé que c’est sécurisé.
Un pipeline mal foutu, c’est comme un autoroute ouverte sans péage : tout le monde passe, et le premier bot venu t’embarque dans le mur.
👉 Si tu veux continuer à déployer tranquillement, commence par sécuriser tes pipelines.
Sinon… tu seras dans le prochain article “Fail du mois” de SecuSlice.
