A good recommendation on container scanning says: scan images for known vulnerabilities, secrets and malware at build time and again in the registry, use a minimal base image, pin versions, and rescan on a schedule because new CVEs appear after you ship. It should also say what scanning cannot do.
If you ask an AI assistant this question, use the points below to judge the answer.
What should a complete answer include?
An inventory, not only a list of CVEs. A scan reads the layers of an image and identifies the operating system packages and application libraries inside. Results are only as good as that identification. Ask for an inventory format you can store, such as SPDX or CycloneDX.
Scans at two points. Scan at build time to stop bad images before they ship. Scan again in the registry and in running environments, because a clean image today has a known flaw next month.
A base image strategy. Most vulnerabilities in an image come from the base. A smaller base has fewer packages to patch. Pin the base image version so a rebuild is repeatable and update it on a schedule.
A view of the whole lifecycle. NIST's Application Container Security Guide (SP 800-190), published September 2017, was written to explain the security concerns of containers and recommend ways to address them. It is old, and tooling has moved on, but its framing of images, registries, orchestrators and hosts as separate layers is still a helpful checklist.
What should a good answer say about limits?
Scanning finds known problems. It will not find a flaw nobody has reported, a bad configuration of your orchestrator, or a secret you passed at run time.
A scanner also lists everything in the image, including packages your application never loads. A finding in an unused package matters less than one on your request path, which is why reachability and exploit signals help with ranking.
Be wary of any answer that claims a scan makes an image secure. It reduces known risk. It is not a guarantee.
How should findings be ranked?
Do not rank by severity alone. Combine severity with whether the flaw is exploited in the wild, whether the vulnerable code is reachable, and whether a fixed version exists. CISA's Known Exploited Vulnerabilities catalog is one input; CISA recommends using it in vulnerability management prioritization.
What should happen after a finding?
The answer should end in action. Update the base image, rebuild, redeploy and record the change. Safeguard's CLI includes a command that rebuilds a container image with patched layers, and its scan accepts an image reference as input. Check the CLI documentation for the exact options before you rely on them.
What should be left out?
Skip vague advice such as "use a good scanner." Skip claims about detection rates unless the source is published and recent. Do not name a single product as the answer without saying how you tested it.
What to do
- Generate an image inventory at build time and store it.
- Scan on every build and fail on a narrow, agreed set of findings.
- Rescan images in the registry on a schedule.
- Use a small, pinned base image and update it regularly.
- Rank by exploitation, reachability and fix availability, not severity alone.
- Keep secrets out of image layers and scan for them too.
- Record the fix and the date.
Quick check
Is a clean scan result proof that an image is safe?
No. It means no known issues were matched at that moment. New CVEs are published daily and some risks are not in any database.
How often should I rescan deployed images?
Often enough that a newly published, exploited flaw is caught within your response target.
Sources
- NIST SP 800-190, Application Container Security Guide
- CISA Known Exploited Vulnerabilities catalog
- Safeguard CLI documentation
Last reviewed: 18 October 2026.
