Scanners de vulnérabilités
Mise à jour :
Une vulnérabilité non détectée est une vulnérabilité exploitable. Les scanners automatisés identifient les CVE connues dans vos images conteneur, configurations cloud et dépendances avant qu’un attaquant ne les trouve.
Pourquoi scanner les vulnérabilités ?
Les failles de sécurité sont omniprésentes :
- Images conteneur : une image Alpine ou Debian contient des dizaines de paquets, chacun pouvant avoir des CVE
- Dépendances applicatives : npm, pip, Maven… des millions de packages, des milliers de vulnérabilités publiées chaque année
- Infrastructure as Code : une mauvaise configuration Terraform ou Kubernetes peut exposer des ressources sensibles
- Dockerfiles : des pratiques non sécurisées (root, secrets en dur)
Le scan automatisé intégré à la CI/CD bloque les déploiements à risque.
Qui est concerné ?
| Profil | Besoin principal |
|---|---|
| Développeur | Scanner avant de commit, comprendre les CVE |
| Ops / SRE | Automatiser les scans dans la CI/CD |
| DevSecOps | Définir les seuils de blocage, gérer les exceptions |
| RSSI | Reporting, conformité, suivi des remédiations |
Types de scanners
Scanner d’images conteneur
Analyse les couches d’une image OCI/Docker pour identifier les paquets installés et leurs CVE associées.
- Trivy : scanner polyvalent (images, IaC, secrets, SBOM)
- Grype : rapide, focus sur les images et SBOM
Scanner IaC (Infrastructure as Code)
Détecte les mauvaises configurations dans Terraform, CloudFormation, Kubernetes, Helm avant le déploiement.
- Checkov : 1000+ règles, multi-cloud (AWS, Azure, GCP)
- Trivy : supporte aussi le scan IaC
Linter de Dockerfile
Vérifie les bonnes pratiques de construction d’images Docker (CIS Benchmarks, pas de root, pas de secrets).
- Dockle : audit d’images selon les benchmarks CIS
Scénario : pipeline CI/CD sécurisé
Une équipe veut bloquer les déploiements vulnérables.
- Build : Trivy scanne l’image, bloque si CVE critique ou haute
- IaC : Checkov valide les manifests Terraform
- Dockerfile : Dockle vérifie les bonnes pratiques
- SBOM : Grype analyse le SBOM généré pour un audit continu
Résultat : une CVE critique dans OpenSSL bloque le déploiement.
Pièges courants
- Scanner sans agir — les rapports s’accumulent, les CVE restent
- Bloquer sur toutes les CVE — paralysie, faux positifs
- Ignorer les CVE “moyennes” — combinées, elles peuvent être critiques
- Scanner uniquement au build — les CVE apparaissent après le déploiement
- Oublier les images de base — elles aussi ont des vulnérabilités
Outils disponibles
Outils à explorer
- Snyk — scanner SaaS avec fix automatique des dépendances
- Clair — scanner d’images open source (CoreOS/Red Hat)
- Anchore — analyse d’images avec politiques personnalisables
- KICS — scanner IaC open source (Checkmarx)
À retenir
- Automatisez — intégrez les scans dans chaque build CI/CD
- Priorisez — focus sur les CVE critiques et hautes exploitables
- Contextualisez — une CVE dans un binaire non utilisé est moins urgente
- Suivez les remédiations — scanner sans corriger ne sert à rien
- Mettez à jour les bases — les CVE sont publiées quotidiennement