01Introduction
A container image bundles your code with an operating system layer and every package it needs. That base image often carries hundreds of known vulnerabilities before your application adds any of its own.
02What is Container image scanning?
Container image scanning analyzes the layers of a container image for vulnerable OS packages, vulnerable language dependencies, embedded secrets and insecure configuration such as running as root.
03How Container image scanning works
Image scanning happens at several points in the lifecycle.
- 1.
Build
Scan images in CI and fail builds that add critical, fixable vulnerabilities.
- 2.
Registry
Rescan stored images as new CVEs are published, since yesterday's clean image is not clean today.
- 3.
Deploy
Use admission control to block unscanned or non-compliant images from reaching clusters.
- 4.
Runtime
Correlate image findings with which containers are running, exposed and loading the vulnerable package.
04Threats and risks
Image risk is mostly inherited.
Bloated base images
Full OS images ship shells, compilers and packages the app never uses.
Unpatched layers
Images built once and deployed for months without a rebuild.
Secrets in layers
Keys deleted in a later layer remain recoverable in an earlier one. See secrets detection.
Finding floods
Hundreds of CVEs per image with no signal about which are loaded or exposed.
05How Parameter helps
Parameter connects image findings to what is actually reachable.
Reachable, not just present
Cloud Security marks which image CVEs sit on running, exposed workloads.
Dependency reachability
Supply Chain checks whether application packages in the image are ever called.
Fixes in code
Base image bumps and Dockerfile changes arrive as pull requests. See auto remediation.
