An image contains an OS and libraries, each with potential known vulnerabilities. Scanning compares the packages in the image against a vulnerability database. Scanning once at release is not enough, because new CVEs are published continuously and base images get patched.
Before you start
You should be comfortable with image layers and CI. This article covers scanning policy and base image updates.
Step-by-step walkthrough
Step 1: Scan in the pipeline
Run a scanner (for example Trivy or Grype) on the built image in CI, so a vulnerable image is caught before it is pushed. Scanning the built image, not just the Dockerfile, reflects what actually ships, including packages pulled in by base images.
Step 2: Set a policy with thresholds
Decide what blocks the build: for example, fail on critical and high severities with a known fix. Without a threshold, every finding is noise and the gate is ignored; with one that is too strict, everything blocks. Make the policy explicit and revisit it.
Step 3: Rebuild on base updates
New fixes arrive in base images and dependencies, so a scheduled rebuild picks them up even when your code has not changed. Treat the base image as a dependency to update, not a fixed foundation.
Worked scenario
The scanner gates the pipeline on high-severity findings.
docker build -t app:ci .
trivy image --severity HIGH,CRITICAL --exit-code 1 app:ciWalk through the example
The build produces the image, and the scan fails the step if it finds a high or critical vulnerability with a fix. Because it scans the built image, it also covers the base OS packages. A scheduled rebuild keeps the image current as fixes are published.
Common mistake
Scanning only at initial development and then shipping the same base for a year, so new CVEs accumulate unpatched. Another is failing on every low-severity finding, which makes the gate noisy and trains people to bypass it.
Verify the behavior
Run the scanner on an outdated base and confirm it reports known CVEs. Fix the base and confirm the findings clear. Introduce a vulnerable dependency and confirm the pipeline blocks.
Interview exercise
Why does scanning the built image matter more than scanning the Dockerfile?
Answer and reasoning
The built image includes everything that actually ships: the base image’s OS packages, transitively installed library versions and files added during the build. A Dockerfile review misses transitive and base-layer vulnerabilities. The image is the artifact, so it is the thing to scan.
Continue learning
Compare build hygiene in Image maintenance and secrets in Docker secrets in builds. Read the Trivy documentation and try the Docker interview questions.