Dépendances
Scan de conteneurs
Le scan de conteneurs inspecte une image de conteneur à la recherche de vulnérabilités connues, de paquets obsolètes et de configurations risquées. Une image regroupe votre application, un système d'exploitation de base et tout ce qui se trouve entre les deux : un scan couvre donc bien plus que vos propres dépendances. Il lit aussi l'image finale, ce qui limite ce qu'il peut savoir de la façon dont elle a été produite.
Mis à jour le
Comment fonctionne le scan de conteneurs
- Décompresser l'image. Le scanner lit les couches de l'image sans les exécuter.
-
Lister le contenu. Il lit les bases de paquets du système d'exploitation et les manifestes d'application, comme
un
package-lock.jsoncopié dans l'image. - Rapprocher les données. Il compare les paquets aux données de vulnérabilité des distributions et des bases d'avis de sécurité.
- Vérifier la configuration. Certains outils signalent aussi des éléments comme l'exécution en root ou des secrets laissés dans une couche.
Où lancer un scan
| Étape | Ce qu'elle apporte | Limite |
|---|---|---|
| CI, après le build de l'image | Fait échouer le build avant le push d'une image | Un instantané des avis de sécurité du jour |
| Registre | Rescanne les images stockées à mesure que de nouveaux avis apparaissent | Trouve les problèmes après la publication de l'image |
| Admission Kubernetes | Bloque au déploiement les images non scannées ou en échec | Nécessite une politique et un moyen de gérer les exceptions |
| Exécution | Montre quelles images tournent à cet instant, et ce qui est chargé | Nécessite un agent sur vos clusters |
Outils de scan de conteneurs
- Open source : Trivy et Grype sont les choix gratuits courants, et tous deux s'intègrent facilement à la CI.
- Intégrés aux registres et aux plateformes : Docker Scout et les principaux registres cloud proposent le scan.
- Plateformes commerciales : Snyk et Anchore ajoutent des politiques, du reporting et des workflows.
Comment réduire le nombre de résultats
- Partez d'une image de base plus petite. Les images slim ou distroless contiennent moins de paquets : moins d'avis de sécurité s'appliquent donc.
- Reconstruisez régulièrement. Les images de base reçoivent des correctifs, et une image saine en mars ne l'est plus aujourd'hui.
- Utilisez des builds multi-stage. Les compilateurs et les outils de build doivent rester hors de l'image finale.
- Épinglez les images de base par digest. Un tag peut changer à votre insu, pas un digest.
- Priorisez. De nombreux résultats n'ont pas encore de correctif ou concernent des paquets que votre application n'utilise jamais. Voir comment prioriser les vulnérabilités.
Ce qu'un scan de conteneurs ne voit pas
- Le code compilé. Un binaire Go ou Rust dans l'image contient peu de métadonnées, et un scanner doit déduire ce qui y est entré.
-
Les fichiers sans enregistrement de paquet. Un logiciel ajouté avec
curlou copié dans une couche n'a aucune entrée dans une base de paquets. - Ce que le build a utilisé puis laissé derrière lui. Les builds multi-stage écartent les outils qui ont produit l'image. Si l'un d'eux a été compromis, rien dans l'image finale ne l'indique.
- D'où vient l'image. Un scan décrit l'image, pas le build qui l'a produite.
Consultez ce qu'une SBOM d'image Docker ne voit pas pour un examen plus détaillé, et les meilleurs outils SBOM pour les options.
Scanner les images et enregistrer les builds
Les scanners sont le bon outil pour les images que vous n'avez pas construites, ainsi que pour les clusters et la configuration. Pour les images que vous construisez, CRACI emprunte une autre voie. En tant que runner GitHub Actions, il voit ce qui entre dans le build, y compris l'image de base et les couches de son système d'exploitation : il enregistre donc ce qui est entré au lieu de le déduire après coup. Il continue ensuite de vérifier ces SBOM à mesure que de nouvelles vulnérabilités sont publiées.
CRACI ne scanne pas les images que vous n'avez pas construites, les clusters, les images de VM ni les erreurs de configuration. Trivy le fait : conservez-le donc pour cela. Voir CRACI vs Trivy.
Scan de conteneurs : questions fréquentes
Qu'est-ce que le scan de conteneurs ?
C'est le processus qui consiste à inspecter une image de conteneur à la recherche de vulnérabilités connues, de paquets obsolètes et de configurations risquées, généralement sans l'exécuter.
Quand faut-il scanner les images de conteneurs ?
En CI après le build de l'image, puis à nouveau dans le registre à mesure que de nouveaux avis de sécurité apparaissent. Un seul scan ne vous laisse qu'un instantané qui vieillit vite.
Quel est le meilleur scanner de conteneurs gratuit ?
Trivy et Grype sont les options gratuites les plus utilisées. Tous deux s'exécutent en CI et couvrent les paquets du système d'exploitation et des applications.
Quelle est la différence entre un scan d'image et une SBOM ?
Une SBOM liste ce que contient une image, tandis qu'un scan vérifie ce contenu à la recherche de problèmes connus. De nombreux scanners construisent d'abord une SBOM, puis la confrontent aux avis de sécurité.
Pourquoi mon image de conteneur a-t-elle autant de vulnérabilités ?
Surtout à cause de l'image de base, qui apporte les paquets d'un système d'exploitation. Une image de base plus petite et des reconstructions régulières en éliminent la plupart.
Un scanner de conteneurs peut-il lire les binaires compilés ?
En partie. Les binaires Go et Rust peuvent contenir certaines métadonnées de dépendances, mais une grande partie du code compilé donne peu d'indices à un scanner, qui doit donc déduire ce qui y est entré.
Découvrez ce qui est entré dans votre image
Construisez une image sur CRACI et comparez la SBOM enregistrée avec ce que signale votre scanner de conteneurs.
Réserver une démo