Container security scanning : détection et déploiement

Le container security scanning est un processus automatisé qui analyse les images de containers et les containers en cours d’exécution afin d’identifier les vulnérabilités, les erreurs de configuration et les menaces avant le déploiement.

Renforcez votre sécurité cloud

Découvrez des pratiques avancées pour réduire les risques, améliorer votre posture et sécuriser vos environnements cloud.

Les environnements conteneurisés introduisent des risques que les scanners traditionnels n’ont pas été conçus pour traiter. Une seule image regroupe le code applicatif, des bibliothèques tierces et des composants de l’OS dans un même artefact. Une vulnérabilité présente dans une couche devient donc une vulnérabilité de l’image finale. Les containers sont aussi éphémères par nature : ils démarrent et s’arrêtent en permanence, si bien qu’une analyse effectuée une seule fois au moment du build passe à côté des menaces qui apparaissent après le déploiement. Les registres et les plateformes d’orchestration comme Kubernetes ajoutent leur propre surface de configuration et offrent aux attaquants davantage de portes d’entrée si l’analyse ne dépasse pas l’image elle-même.

Ces dynamiques expliquent pourquoi les intrusions cloud de 2025 se sont surtout appuyées sur des faiblesses anciennes, des vulnérabilités, des secrets exposés et des erreurs de configuration, plutôt que sur de nouvelles techniques d’attaque. Une analyse qui couvre tout le cycle de vie, et pas seulement l’image, répond directement aux points d’entrée dont dépendent le plus les attaquants.

Que détecte le container scanning ?

Le container scanning examine plusieurs catégories de risques distinctes, chacune introduite à un moment différent du cycle de vie du container. Comprendre ce que couvre l’analyse vous aide à évaluer si vos outils actuels répondent à votre exposition réelle. Voici un aperçu des différentes détections.

Catégorie	Ce que cela couvre
CVE connues dans les images de base et les packages de l’OS	Les scanners vérifient les packages et bibliothèques du système d’exploitation par rapport à des bases comme la National Vulnerability Database, afin de signaler les failles connues avant le déploiement.
Dépendances applicatives vulnérables	La software composition analysis (SCA) inspecte les bibliothèques open source dont dépend votre application et met en lumière les dependencies obsolètes ou exploitables.
Secrets et identifiants exposés	Les scanners repèrent les clés d’API, mots de passe et jetons intégrés dans les couches d’image, qui restent récupérables même après une suppression ultérieure.
Erreurs de configuration dans les Dockerfiles et les manifestes Kubernetes	L’analyse statique détecte les problèmes comme des containers exécutés en root, des permissions excessives ou des ports exposés avant la production.
Malwares et binaires inattendus	L’analyse détecte le code malveillant ou les exécutables introduits par une image de base compromise ou un processus de build altéré.
Risques de conformité des licences	Les licences open source imposent des obligations, et l’analyse signale les packages dont les termes pourraient créer une exposition juridique.

Savoir ce que détecte l’analyse amène la question suivante : comment les scanners procèdent-ils concrètement tout au long du cycle de vie du container ?

Comment fonctionne le container scanning

Le container scanning s’articule autour de plusieurs couches distinctes, chacune ciblant un moment différent de la vie du container. Ensemble, ces couches forment une défense qui s’étend de la première ligne d’un Dockerfile jusqu’à un container qui tourne en production.

Analyse statique des images

L’analyse statique des images examine les couches d’une image de container avant le déploiement. Elle décompose l’image en ses éléments constitutifs, à savoir l’OS de base, le code applicatif et les dependencies, puis compare chacun à des bases de vulnérabilités connues. Comme cette analyse a lieu avant l’exécution de l’image, elle détecte au plus tôt des problèmes comme des packages obsolètes ou des secrets intégrés.

Analyse du registre

L’analyse du registre vérifie les images au repos dans votre container registry et applique des règles de pull qui empêchent les images vulnérables ou non conformes d’atteindre la production. Elle sert de point de contrôle entre le build et le déploiement, et rattrape les images qui ont pu passer des analyses antérieures mais se trouvent désormais signalées à cause de vulnérabilités récemment divulguées.

Analyse du CI/CD pipeline

Intégrer l’analyse directement dans votre CI/CD pipeline intègre les contrôles de sécurité au processus de build lui-même. Une politique fail-fast arrête un build dès qu’une vulnérabilité critique est détectée et empêche les images risquées de progresser dans le pipeline. Votre équipe élimine ainsi les problèmes vite et tôt dans le flux de sécurité.

Analyse runtime

L’analyse runtime surveille les containers pendant leur exécution et observe les appels système, les processus et le comportement réseau pour repérer les compromissions que les analyses statiques, effectuées avant le déploiement, ne peuvent pas détecter. Un container qui passe tous les contrôles peut malgré tout être compromis après le déploiement, par une faille zero-day, un identifiant détourné ou un attaquant qui pivote depuis une autre ressource. Associer cette visibilité runtime à votre contexte cloud plus large transforme une alerte isolée en un résultat priorisé et exploitable.

Exemple concret : Wiz Research a découvert la CVE-2024-0132, une vulnérabilité d’évasion de container dans le NVIDIA Container Toolkit. Cette vulnérabilité permettait à une image de container malveillante d’accéder au système de fichiers root de l’hôte. Des pratiques de continuous vulnerability management comme l’analyse runtime ont aidé Wiz à prévenir ces problèmes grâce à un examen et une analyse constants des containers.

Génération de SBOM et cartographie des dépendances

Générer un software bill of materials (SBOM) crée un inventaire complet de chaque composant, bibliothèque et dépendance présent dans une image de container. Cet inventaire devient déterminant dès qu’une nouvelle vulnérabilité est divulguée. Lors de la divulgation de Log4Shell, les équipes disposant d’un SBOM ont pu identifier immédiatement les images contenant la bibliothèque touchée et prioriser la remédiation. Celles qui n’en avaient pas ont dû reconstruire ce contexte de zéro, souvent en plusieurs jours, pour évaluer leur exposition réelle.

Chaque couche joue un rôle à une étape différente du développement, ce qui soulève la question de leur correspondance avec votre workflow réel, du premier commit jusqu’à un container en production.

Le container scanning tout au long du cycle de développement

Le container scanning répartit les contrôles sur les phases de build, de registre, de déploiement et de runtime, chacune détectant différentes catégories de risques là où elles sont les moins coûteuses à traiter.

Phase de build : analyse du Dockerfile et choix de l’image de base

Pendant la phase de build, l’analyse examine votre Dockerfile et l’image de base que vous avez choisie comme point de départ. Sans ce contrôle, une image de base vulnérable extraite d’un registre public devient le socle de chaque image construite par-dessus, et intègre le risque avant même l’écriture d’une seule ligne de code applicatif. Choisir une image de base minimale et bien maintenue, puis analyser la container image tôt dans le processus de build, empêche ce risque hérité de s’accumuler en aval.

Phase de registre : application des règles avant que les images n’atteignent la production

Une fois construite, l’image arrive dans un registre, où l’application des règles détermine si elle peut aller plus loin. Sans contrôle à ce stade, une image porteuse d’une vulnérabilité critique connue peut rester dans le registre et se retrouver déployée en production par n’importe quelle équipe disposant d’un accès. Appliquer des règles ici agit comme un sas qui rattrape les images passées inaperçues ou signalées par des CVE récemment publiées.

Phase de déploiement : admission controllers et contrôles pré-déploiement dans Kubernetes

Au moment du déploiement, les admission controllers de Kubernetes évaluent si une image entrante répond à vos exigences de sécurité avant d’autoriser son exécution. Sans admission controllers, une image non conforme, par exemple dépourvue des labels requis ou dotée de privilèges excessifs, peut être déployée directement dans un cluster actif sans contrôle final.

Phase de runtime : surveillance comportementale continue des containers en exécution

Dès qu’un container tourne, la surveillance comportementale continue guette les activités qui s’écartent des schémas attendus, comme des connexions réseau inattendues ou des modifications de fichiers non autorisées. Une vulnérabilité inconnue au moment du build, ou un identifiant compromis après le déploiement, ne devient visible qu’à ce stade.

C’est là que l’analyse runtime agentless apporte le plus de valeur. Nous avons conçu Wiz pour analyser les containers en exécution sans déployer d’agents sur chaque workload, ce qui vous donne une visibilité runtime continue tout en évitant la charge opérationnelle et l’impact sur les performances propres aux approches agent-based.

Avec une analyse répartie sur chacune de ces phases, les bénéfices apparaissent plus clairement une fois que vous voyez comment ils se cumulent tout au long du cycle de vie.

Les bénéfices du container security scanning

Un container scanning déployé sur tout le cycle de vie apporte des bénéfices qui se cumulent à mesure que vous passez du build au runtime.

Le guide pratique des responsables sécurité

Obtenez des conseils concrets pour prioriser les risques, aligner les équipes et accélérer vos initiatives CloudSec.

1. Détection précoce des vulnérabilités

Détecter les vulnérabilités pendant la phase de build les empêche d’atteindre la production. Cette approche shift left (approche préventive en amont du cycle de développement) fait remonter les problèmes quand ils sont les plus faciles à corriger, avant que le code ne soit mergé, déployé et repris par d’autres équipes.

2. Réduction de la surface d’attaque Kubernetes

Analyser les manifestes Kubernetes à la recherche d’erreurs de configuration, comme un RBAC trop permissif, des dashboards exposés ou des containers dotés de privilèges inutiles, réduit les chemins disponibles pour le lateral movement. Un manifeste mal configuré qui accorde à un workload des permissions cluster-admin peut, par exemple, transformer un seul container compromis en point d’appui sur l’ensemble de votre cluster. Détecter ces problèmes avant le déploiement ferme ce chemin avant qu’il n’existe.

3. Conformité aux normes de sécurité

L’analyse de conformité automatisée compare les configurations des containers à des cadres comme les CIS Benchmarks, PCI DSS, SOC 2 et NIST, et fait remonter les écarts avant qu’ils n’affectent un audit. Nous avons conçu Wiz pour analyser plus de 100 cadres, dont HIPAA et le RGPD, afin que votre équipe de sécurité identifie et corrige les écarts de conformité en continu plutôt que dans l’urgence avant une échéance d’audit.

4. Des CI/CD pipelines plus rapides

Intégrer l’analyse au CI/CD pourrait sembler ralentir les builds, mais c’est l’inverse qui se vérifie avec le temps. Détecter les problèmes automatiquement et tôt signifie moins de rollbacks tardifs, moins de correctifs d’urgence et moins d’allers-retours manuels entre les équipes de sécurité et de développement, autant d’éléments qui ralentissent les pipelines bien plus qu’une analyse automatisée.

Ces bénéfices dépendent d’une analyse qui fonctionne comme prévu, ce qui soulève un ensemble de défis que les équipes doivent anticiper.

Les défis du container scanning

Le container scanning apporte une vraie valeur, mais le mettre en œuvre correctement s’accompagne de points de friction qu’il vaut mieux anticiper. Voici les défis courants de l’analyse.

Alert fatigue liée au volume élevé de CVE

Une seule analyse peut renvoyer des centaines de CVE, dont beaucoup présentent peu de risque réel pour votre environnement. Sans moyen de filtrer et de prioriser ce volume, les équipes de sécurité se désensibilisent vite aux alertes, et le risque augmente qu’un résultat vraiment critique se perde dans le bruit.

Risque hérité des images de base

Chaque vulnérabilité présente dans une image de base devient une vulnérabilité de chaque image qui en dérive, souvent sans que l’équipe en aval s’en rende compte. Ce risque hérité peut persister sur des dizaines d’images si l’image de base elle-même n’est pas régulièrement mise à jour et réanalysée.

Containers éphémères qui échappent aux analyses ponctuelles

Les containers des environnements modernes sont souvent éphémères : ils démarrent pour traiter une tâche et s’arrêtent peu après. Une analyse effectuée à un seul instant peut manquer tout le cycle de vie d’un container et laisser un angle mort pour les workloads qui n’existent que quelques minutes.

Priorisation sans contexte runtime

Un score CVSS seul vous indique la gravité théorique d’une vulnérabilité, mais pas si elle est réellement exploitable dans votre environnement. Une vulnérabilité critique dans un container sans exposition réseau présente bien moins de risque qu’une vulnérabilité de gravité moyenne dans un container ayant un accès direct à des données sensibles, et les scores CVSS seuls ne font pas cette distinction.

Intégrité de la supply chain du scanner

Les outils d’analyse eux-mêmes reposent sur des bases de vulnérabilités et des flux de signatures qui doivent rester à jour et dignes de confiance. Un scanner qui s’appuie sur une base obsolète peut manquer des vulnérabilités récemment divulguées, tandis qu’un flux compromis pourrait, en théorie, introduire des faux négatifs à grande échelle.

Ces défis orientent vers un ensemble de pratiques qui aident les équipes à tirer une valeur plus régulière du container scanning.

Bonnes pratiques du container scanning

Les pratiques suivantes aident les équipes à faire du container scanning non plus un contrôle ponctuel, mais une protection continue sur tout le cycle de vie.

1. Utiliser des images de base minimales pour réduire la surface de CVE héritée

Choisir une image distroless ou basée sur Alpine plutôt qu’une image complète de système d’exploitation réduit fortement le nombre de packages, et donc le nombre de vulnérabilités potentielles, dès le départ. Partir d’une image de base surchargée revient à hériter de CVE dans des packages que votre application n’utilise même jamais.

2. Intégrer l’analyse au CI/CD et faire échouer les builds sur les résultats critiques

Intégrer l’analyse à votre CI/CD pipeline et la configurer pour faire échouer les builds dès qu’une vulnérabilité critique est détectée arrête les images risquées avant qu’elles n’atteignent un registre. Sans ce sas, un résultat critique pourrait n’apparaître qu’après le déploiement de l’image dans plusieurs environnements.

La configuration GitLab CI suivante montre ce sas en pratique : l’étape d’analyse fait échouer le pipeline si Trivy détecte la moindre vulnérabilité critique, ce qui empêche l’étape de déploiement de s’exécuter.

# Sample integration of a security scanner in GitLab CI
stages:
  - build
  - scan
  - deploy

build:
  stage: build
  script:
    - docker build -t my-image .

security_scan:
  stage: scan
  script:
    - trivy image --exit-code 1 --severity CRITICAL my-image

deploy:
  stage: deploy
  script:
    - docker push my-repo/my-image:latest

3. Appliquer des admission controllers pour bloquer les images non conformes

Les admission controllers de Kubernetes agissent comme un point de contrôle final et bloquent le déploiement des images non analysées ou contraires aux règles. Sans cette application, une image ayant contourné les contrôles antérieurs, par erreur humaine ou par une faille de processus, peut tout de même atteindre un cluster en exécution.

4. Générer et tenir à jour des SBOM pour les images de production

Tenir à jour un SBOM pour chaque image de production donne à votre équipe une réponse immédiate dès qu’une nouvelle vulnérabilité est divulguée dans une bibliothèque très utilisée. Sans SBOM, les équipes doivent chercher manuellement dans les images pour évaluer leur exposition, souvent sous la pression du temps.

5. Prioriser les résultats selon le contexte runtime, pas le seul score CVSS

Utiliser le contexte runtime pour prioriser les vulnérabilités, par exemple si un container est exposé à Internet ou a accès à des données sensibles, permet de concentrer l’effort de remédiation sur les problèmes qui présentent un risque réel. S’appuyer sur les seuls scores CVSS peut conduire à passer des jours sur une vulnérabilité critique théorique, pendant qu’un problème de gravité moyenne plus exploitable reste sans réponse.

Le pseudocode suivant montre ce principe en pratique : l’exploitabilité d’une vulnérabilité et son accès à des données sensibles déterminent sa priorité, plutôt que sa seule note de gravité CVSS.

# Pseudocode for prioritizing vulnerabilities by runtime context
for vulnerability in scan_results:
    if is_exploitable(environment, vulnerability) and has_sensitive_access(environment):
        raise_alert(vulnerability)
    elif is_exploitable(environment, vulnerability):
        schedule_for_remediation(vulnerability)
    else:
        log_for_review(vulnerability)

6. Analyser en continu au runtime, pas seulement au build

Étendre l’analyse au runtime détecte les menaces qui apparaissent après le déploiement, y compris les vulnérabilités récemment divulguées et les anomalies comportementales révélatrices d’une compromission. Une approche limitée au build laisse toute la durée de vie du container en production sans surveillance.

7. Ne jamais stocker de secrets dans les couches d’image

Stocker des secrets comme des clés d’API ou des mots de passe dans les couches d’image les laisse récupérables même si une couche ultérieure supprime le fichier, car les couches antérieures restent dans l’historique de l’image. Recourir à un gestionnaire de secrets dédié maintient les identifiants hors de l’image et supprime ce risque à la source.

Avec ces pratiques en tête, le choix du bon outil d’analyse repose sur un ensemble précis de capacités.

Comment choisir un outil de container scanning

L’évaluation des outils de container scanning repose sur quelques capacités qui déterminent le niveau de protection réelle qu’un outil apporte à votre environnement.

Couverture du cycle de vie. L’outil doit analyser le build, le registre, le CI/CD et le runtime, plutôt que de se limiter à l’analyse statique des images.
Déploiement agentless. L’analyse agentless supprime la charge liée à l’installation et à la maintenance d’agents sur chaque workload, accélère le time to value et allège le poids opérationnel.
Contexte runtime pour la priorisation. L’outil doit relier les résultats d’analyse aux données runtime, comme l’exposition réseau et le comportement des workloads, pour prioriser selon le risque réel plutôt que le seul score CVSS.
Profondeur d’intégration CI/CD. Recherchez des intégrations natives avec vos outils de pipeline existants, comme GitLab, qui prennent en charge les politiques fail-fast sans scripts sur mesure.
Génération de SBOM. L’outil doit générer et tenir à jour les SBOM automatiquement et vous fournir un inventaire des dependencies à jour sans effort manuel.
Couverture Kubernetes et services managés. L’outil doit analyser les manifestes Kubernetes et étendre la couverture aux services de containers managés de vos fournisseurs cloud, pas seulement aux clusters autogérés.

Nous avons conçu Wiz pour offrir une couverture agentless sur tout le cycle de vie des containers, du Dockerfile au runtime, en reliant chaque résultat au contexte plus large de votre environnement cloud grâce au Wiz Security Graph. Une vulnérabilité signalée dans une image de container est ainsi automatiquement rattachée à son exposition runtime, à son accessibilité réseau et à sa relation avec d’autres ressources, ce qui donne à votre équipe une vue priorisée au lieu d’une liste plate de CVE.

Un container scanning qui s’arrête au niveau de l’image laisse votre surface d’attaque la plus active sans surveillance. Pour voir les pratiques abordées dans cet article appliquées à votre propre environnement, téléchargez les bonnes pratiques de sécurité des containers, un plan concret à appliquer à vos workflows de build et de runtime. Ou réservez une démo pour découvrir comment Wiz peut unifier votre stack de sécurité cloud.

Prêt à passer à la pratique ? Voir Wiz en action sur vos propres workloads.

Découvrez Wiz en action

Voyez comment Wiz vous aide à identifier, prioriser et corriger les risques cloud plus rapidement.

Pratiques avancées recommandées pour la sécurité dans le cloud Télécharger

[CTA-END]

Points clés à retenir