Intégrer la sécurité dans un pipeline CI/CD ne consiste pas à empiler des outils. Un pipeline qui remonte des centaines d'alertes dès le premier jour sera vite contourné. L'approche qui fonctionne : commencer par quelques contrôles à fort impact, régler leurs seuils, puis élargir.
Voici les cinq contrôles que nous recommandons d'automatiser en priorité, dans l'ordre.
1. Détection des secrets
Le risque : une clé d'API, un mot de passe ou une clé privée commitée par erreur. Une fois dans l'historique git, elle doit être considérée comme compromise, même si le commit est supprimé ensuite.
Le contrôle : un scanner de secrets (par exemple Gitleaks ou TruffleHog) exécuté sur chaque pull request, et idéalement aussi en pre-commit sur le poste du développeur pour bloquer le problème avant même le push.
À retenir : en cas de détection, la seule correction fiable est la révocation du secret, pas sa suppression du code.
2. Analyse des dépendances (SCA)
Le risque : la majorité du code d'une application moderne provient de bibliothèques tierces. Une vulnérabilité connue dans l'une d'elles est souvent la porte d'entrée la plus simple pour un attaquant.
Le contrôle : une analyse de composition logicielle (SCA) qui compare vos dépendances aux bases de vulnérabilités connues : Dependabot ou Renovate pour les mises à jour, Trivy, Grype ou OWASP Dependency-Check pour l'analyse.
À retenir : bloquez le pipeline uniquement sur les vulnérabilités critiques et élevées disposant d'un correctif, sinon le bruit décourage les équipes.
3. Analyse statique du code (SAST)
Le risque : injections SQL, désérialisation dangereuse, chemins de fichiers contrôlés par l'utilisateur… des erreurs détectables par simple lecture du code.
Le contrôle : un outil SAST (Semgrep, SonarQube, CodeQL…) exécuté sur les pull requests, avec des résultats affichés directement dans la revue de code.
À retenir : commencez avec un jeu de règles restreint et à faible taux de faux positifs, puis enrichissez-le.
4. Infrastructure-as-code et images de conteneurs
Le risque : un bucket de stockage public, un groupe de sécurité ouvert sur Internet, un conteneur qui tourne en root avec une image de base obsolète.
Le contrôle : analyser les fichiers Terraform, Kubernetes ou Dockerfile (Checkov, Trivy config…) et scanner les images construites avant leur publication. Par exemple avec Trivy :
# Échoue (code de sortie 1) si l'image contient des vulnérabilités élevées ou critiques
trivy image --exit-code 1 --severity HIGH,CRITICAL mon-registre/mon-app:1.4.2À retenir : les erreurs de configuration sont à l'origine d'une grande partie des incidents cloud ; ce contrôle est souvent celui qui a le meilleur rapport effort/bénéfice.
5. Tests dynamiques (DAST)
Le risque : certaines failles n'apparaissent qu'à l'exécution : en-têtes de sécurité absents, mauvaise gestion des sessions, endpoints exposés par erreur.
Le contrôle : un scan dynamique (OWASP ZAP par exemple) lancé sur un environnement de recette après chaque déploiement, en mode baseline pour commencer.
À retenir : le DAST complète les autres contrôles mais ne les remplace pas ; il ne voit que ce qui est exposé.
Comment déployer ces contrôles sans bloquer les équipes
- Mode observation d'abord : activez chaque contrôle sans faire échouer le pipeline pendant deux à quatre semaines, le temps de traiter l'existant et de régler les faux positifs.
- Bloquer sur le nouveau, pas sur l'historique : ne faites échouer que les problèmes introduits par la pull request en cours.
- Des seuils explicites et partagés : documentez ce qui bloque (secrets, vulnérabilités critiques corrigeables) et ce qui ne fait qu'alerter.
- Mesurer : suivez le nombre de vulnérabilités ouvertes et le délai de correction, pas seulement le nombre d'alertes.
Vous voulez faire le point sur la maturité de votre pipeline ? Nous proposons une évaluation gratuite de votre CI/CD.