How do you scan container images in a CI/CD pipeline?
Short answer
Scan images for known CVEs in OS packages and app libraries, plus misconfigurations and embedded secrets, both at build time and continuously in the registry — because new CVEs appear after an image is built. Use minimal or distroless base images to shrink the attack surface, pin and digest-reference base images, and run the container as non-root. Scanning is necessary but doesn't replace runtime protection.
A container image is a stack of layers — a base OS, packages, libraries, and your app — and any layer can carry a vulnerability. Image scanning is how you keep that stack honest.
What scanning finds
A scanner (Trivy, Grype, Clair, or a registry's built-in scanner) inspects every layer and reports:
- Known CVEs in OS packages (the base image) and application dependencies.
- Misconfigurations — running as root, secrets baked into a layer, dangerous capabilities, missing user.
- Embedded secrets accidentally copied into the image.
Scan at build and in the registry
This is the point candidates often miss. Scanning at build time in CI gives fast feedback and can fail the build. But an image that was clean yesterday is not clean forever — new CVEs are disclosed against packages already inside it. So you also scan continuously in the registry, so an image that's now known-vulnerable gets flagged (and ideally blocked from deployment) even though nothing about it changed.
Shrink the attack surface
The cheapest vulnerabilities to fix are the ones you never ship. Minimal or distroless base images strip out shells, package managers, and unused libraries, so there's simply less to be vulnerable and less for an attacker to use post-compromise. Pin base images by digest (not just :latest), rebuild regularly to pick up patches, and run as a non-root user.
Scanning isn't the finish line
Image scanning is static — it can't see what a running container actually does. Pair it with runtime security (admission control, drift detection, behavioral monitoring) for the full picture.
What interviewers look for
They want both build-time and registry scanning explained, the minimal-base-image instinct, and the awareness that scanning a known-good image still needs revisiting as new CVEs land.
Likely follow-ups
- Why scan images in the registry if you already scanned at build time?
- How do minimal or distroless base images reduce risk?
- What does image scanning miss that runtime security catches?