Une pipeline CI/CD automatise la construction, les tests et le déploiement de vos applications. C’est un gain de temps considérable… mais aussi une cible de choix : elle a accès à votre code, à vos secrets et à votre production. Voici 7 bonnes pratiques DevSecOps pour la sécuriser, avec des exemples concrets sur GitLab CI et Kubernetes.
1. Ne jamais stocker de secrets dans le code
Mots de passe, clés d’API, jetons d’accès : rien de tout cela ne doit apparaître dans le dépôt Git, même dans un fichier de configuration « temporaire ». Dans GitLab, utilisez les variables CI/CD (Paramètres → CI/CD → Variables) en les marquant masquées (elles n’apparaissent pas dans les journaux) et protégées (elles ne sont disponibles que sur les branches protégées).
2. Analyser automatiquement le code (SAST)
L’analyse statique repère les failles classiques (injections, mauvaises pratiques cryptographiques…) à chaque modification, avant même la mise en production. GitLab fournit un modèle prêt à l’emploi à inclure dans votre fichier .gitlab-ci.yml.
3. Détecter les secrets oubliés
Malgré toutes les précautions, un secret finit parfois dans un commit. La détection de secrets analyse chaque modification et alerte immédiatement. Si un secret a fuité, considérez-le comme compromis : révoquez-le et remplacez-le, le supprimer de l’historique ne suffit pas.
4. Surveiller les dépendances
Une grande partie du code d’une application provient de bibliothèques externes. Analysez-les régulièrement pour repérer les versions vulnérables, avec les outils de votre édition de GitLab ou des outils open source comme Trivy ou OWASP Dependency-Check.
5. Scanner les images Docker avant de les déployer
Une image peut embarquer des paquets système obsolètes. Faites échouer la pipeline si une vulnérabilité critique est détectée :
stages:
- test
- build
- scan
- deploy
include:
- template: Jobs/SAST.gitlab-ci.yml
- template: Jobs/Secret-Detection.gitlab-ci.yml
scan_image:
stage: scan
image:
name: aquasec/trivy:latest
entrypoint: [""]
variables:
TRIVY_USERNAME: "$CI_REGISTRY_USER"
TRIVY_PASSWORD: "$CI_REGISTRY_PASSWORD"
script:
- trivy image --exit-code 1 --severity HIGH,CRITICAL "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA"6. Appliquer le principe du moindre privilège
Le compte utilisé par la pipeline pour déployer sur Kubernetes ne doit avoir accès qu’à ce dont il a besoin : un ServiceAccount dédié, limité à son namespace grâce à un Role plutôt qu’un ClusterRole. Côté GitLab, réservez les runners de déploiement aux branches protégées.
7. Contrôler et tracer chaque mise en production
Utilisez les environnements protégés de GitLab pour exiger une validation avant le déploiement en production, et déployez des images identifiées de façon unique (tag lié au commit ou empreinte sha256) plutôt que latest. Vous savez ainsi exactement ce qui tourne en production, et vous pouvez revenir en arrière rapidement.
En résumé
La sécurité n’est pas une étape finale : en l’intégrant dans la pipeline, chaque modification est vérifiée automatiquement, sans ralentir vos équipes. Ces pratiques sont accessibles à toutes les structures, de la TPE à la collectivité.
Vous souhaitez sécuriser vos pipelines CI/CD ou mettre en place une démarche DevSecOps ? Contactez-nous ou écrivez-nous à contact@senetech.eu.