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 ?
Section intitulée « 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é ?
Section intitulée « 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
Section intitulée « Types de scanners »Scanner d’images conteneur
Section intitulée « 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)
Section intitulée « Scanner IaC (Infrastructure as Code) »Détecte les mauvaises configurations dans Terraform, CloudFormation, Kubernetes, Helm avant le déploiement.
Linter de Dockerfile
Section intitulée « 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é
Section intitulée « 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
Section intitulée « 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
Section intitulée « Outils disponibles »Outils à explorer
Section intitulée « 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
Section intitulée « À 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