Pourquoi scanner les images conteneur avant le déploiement (et comment le faire)

Vous venez de construire une nouvelle image conteneur. Le build est passé, les tests sont verts, et l'image est dans votre registre. Elle semble prête pour la production. Mais il y a un problème que vous ne voyez pas : l'image peut contenir des vulnérabilités de sécurité connues qui pourraient permettre à un attaquant de prendre le contrôle de votre serveur.

Les images conteneur ne sont pas des boîtes scellées. Chaque image est construite à partir de couches : une image de base téléchargée depuis Internet, des bibliothèques système, des environnements d'exécution de langage, et votre propre code applicatif. Chaque couche peut transporter des vulnérabilités. Une image de base qui était sûre la semaine dernière peut avoir un CVE critique découvert hier. Une bibliothèque que vous avez ajoutée il y a trois mois peut avoir une faille récemment signalée. Ces problèmes ne s'annoncent pas d'eux-mêmes. Vous devez vérifier.

Qu'est-ce qu'un scan de vulnérabilités ?

Un scan de vulnérabilités est un processus automatisé qui ouvre votre image conteneur, inspecte chaque paquet et bibliothèque à l'intérieur, et les compare à une base de données de vulnérabilités connues. Ces vulnérabilités sont suivies sous forme de CVE (Common Vulnerabilities and Exposures). Chaque CVE a un niveau de gravité : faible, moyen, élevé ou critique.

Une vulnérabilité critique peut permettre l'exécution de code à distance. Un attaquant pourrait prendre le contrôle de votre serveur sans authentification. Un problème de gravité élevée pourrait permettre à quelqu'un de lire des fichiers auxquels il ne devrait pas avoir accès. Les problèmes moyens et faibles sont plus difficiles à exploiter, mais ils ajoutent du risque, surtout lorsqu'ils sont combinés avec d'autres faiblesses.

Le scan produit un rapport : quels paquets sont affectés, quelle est la gravité du problème, et vers quelle version corrigée vous devez migrer.

Pourquoi vous ne pouvez pas scanner une fois et oublier

Les bases de données de vulnérabilités sont mises à jour chaque jour. De nouveaux CVE sont publiés constamment. Une image de base qui a passé votre scan le mois dernier peut maintenant avoir une faille critique. Une bibliothèque que vous avez épinglée à une version spécifique peut avoir une vulnérabilité nouvellement découverte qui n'était pas là lorsque vous l'avez choisie.

C'est pourquoi le scan doit avoir lieu à chaque fois que vous construisez une image. Pas seulement au premier build. Pas seulement quand vous vous en souvenez. À chaque build. Le scan doit faire partie de votre pipeline, automatisé et appliqué.

Où placer le scan dans votre pipeline

Le scan se situe entre l'étape de build et l'étape de promotion. Le flux typique ressemble à ceci :

Le diagramme suivant visualise ce processus de décision :

Voici un exemple pratique utilisant Trivy dans un workflow GitHub Actions qui scanne l'image et échoue le pipeline en cas de vulnérabilité critique :

scan-image:
  runs-on: ubuntu-latest
  steps:
    - name: Pull image from registry
      run: docker pull my-registry/my-app:${{ github.sha }}

    - name: Run Trivy vulnerability scan
      uses: aquasecurity/trivy-action@master
      with:
        image-ref: my-registry/my-app:${{ github.sha }}
        format: table
        exit-code: 1
        severity: CRITICAL

Le paramètre exit-code: 1 indique à Trivy de retourner un code de sortie non nul lorsque des vulnérabilités sont trouvées, ce qui stoppe le pipeline. Le paramètre severity: CRITICAL définit le seuil de la politique : seules les découvertes critiques provoquent un échec. Ajustez la sévérité à CRITICAL,HIGH si vous voulez bloquer sur les deux.

flowchart TD A[Build Image] --> B[Push to Registry] B --> C[Run Vulnerability Scan] C --> D{Scan Passes?} D -->|Yes| E[Promote to Next Environment] D -->|No| F[Block Pipeline] F --> G[Fix Image] G --> A
  1. Construire l'image
  2. Pousser l'image vers un registre
  3. Exécuter le scan de vulnérabilités
  4. Évaluer les résultats par rapport à votre politique
  5. Si le scan réussit, promouvoir l'image vers l'environnement suivant
  6. Si le scan échoue, stopper le pipeline et corriger l'image

Le scan doit s'exécuter après la construction de l'image mais avant qu'elle n'atteigne la préproduction ou la production. De cette façon, les images vulnérables ne quittent jamais le registre.

Définir une politique de scan

Une politique de scan définit ce qui se passe lorsque des vulnérabilités sont trouvées. Vous décidez des seuils. Pour une application exposée au public, vous pourriez bloquer le pipeline sur toute découverte critique ou de gravité élevée. Pour un outil interne, vous pourriez bloquer uniquement les problèmes critiques et journaliser ceux de gravité élevée pour le prochain sprint.

La clé est la cohérence. Ne décidez pas par déploiement. Définissez la politique une fois, écrivez-la dans votre configuration de pipeline, et laissez-la s'exécuter automatiquement. Si la politique bloque un déploiement, c'est un signal pour corriger l'image, pas pour outrepasser la politique.

Outils que vous pouvez utiliser

Plusieurs outils peuvent scanner les images conteneur. Ils fonctionnent tous de manière similaire : ils inspectent les couches de l'image, identifient les paquets, et les recoupent avec les bases de données CVE.

  • Trivy - Open source, rapide, largement utilisé. Fonctionne bien dans les pipelines CI.
  • Snyk - Commercial avec un niveau gratuit. S'intègre avec de nombreux registres et systèmes CI.
  • Grype - Open source d'Anchore. Souvent associé à Syft pour la génération de SBOM.
  • Clair - Open source, originellement de CoreOS. Utilisé par de nombreux services de registre.
  • Scanners intégrés aux registres - Docker Hub, Amazon ECR, et Google Artifact Registry offrent un scan automatique pour les images stockées dans leurs registres.

Choisissez celui qui correspond à votre flux de travail. La plupart s'exécutent en une seule commande dans votre pipeline.

Que faire quand un scan échoue

Lorsque le pipeline s'arrête à cause d'une vulnérabilité, ne l'ignorez pas. La correction se range généralement dans l'une de ces catégories :

Mettre à jour l'image de base. C'est la correction la plus courante. Les images de base comme Alpine, Ubuntu ou les images distroless publient régulièrement des versions mises à jour. Passez à la dernière version corrigée et reconstruisez.

Mettre à jour les dépendances applicatives. Si la vulnérabilité se trouve dans une bibliothèque utilisée par votre code, mettez à jour la dépendance dans votre code source et reconstruisez l'image.

Supprimer les outils inutilisés. Parfois, les vulnérabilités proviennent d'outils laissés accidentellement dans l'image : débogueurs, compilateurs, gestionnaires de paquets. Ceux-ci ne sont pas nécessaires à l'exécution. Les builds multi-étapes résolvent ce problème en ne conservant que les artefacts d'exécution finaux dans l'image de production.

Après la correction, reconstruisez l'image et exécutez à nouveau le scan. Répétez jusqu'à ce que l'image réussisse.

Ce que le scan de vulnérabilités n'est pas

Le scan ne remplace pas les autres pratiques de sécurité. Il ne couvre pas les tests d'intrusion, le contrôle d'accès, la sécurité réseau ou la surveillance à l'exécution. Mais c'est une couche de défense peu coûteuse et efficace qui s'exécute automatiquement. Sans elle, des vulnérabilités critiques peuvent atteindre la production sans que personne ne le remarque.

Liste de contrôle pratique

  • Ajoutez une étape de scan de vulnérabilités après la construction de l'image dans votre pipeline CI
  • Définissez une politique de scan avec des seuils clairs (par exemple, bloquer sur les vulnérabilités critiques et élevées)
  • Configurez le pipeline pour s'arrêter en cas de violation de la politique
  • Utilisez des builds multi-étapes pour réduire la surface d'attaque de vos images
  • Planifiez des mises à jour régulières de vos images de base et dépendances
  • Examinez périodiquement les rapports de scan, même pour les builds réussis

L'essentiel à retenir

Une image conteneur qui n'a pas été scannée est un risque inconnu. Ajoutez le scan de vulnérabilités à votre pipeline dès aujourd'hui. Choisissez un outil, définissez une politique, et laissez l'automatisation attraper les problèmes avant qu'ils n'atteignent la production. Cela prend quelques minutes à configurer et vous évite de découvrir un CVE critique après qu'un attaquant l'ait déjà trouvé.