Container scanning for a regulated industry has to do three things: find vulnerabilities and secrets in images and their base layers, run where your data rules require, and produce records an auditor can read. Speed and a long findings list matter less than evidence, placement and prioritization.
What does a regulator actually care about here?
Most frameworks do not say "scan containers." They say you must identify vulnerabilities, manage them on a defined timeline, and show your work. NIST SP 800-190, the Application Container Security Guide, is the reference most auditors reach for when containers come up. It explains the risks specific to images, registries, orchestrators, containers and the host, and recommends countermeasures for each.
So the buying question is not "does it scan images?" Every tool does. It is "can I show an assessor what was scanned, when, against which data, and what we did about it?"
Criteria worth putting in a scorecard
Where the scan runs. Some teams cannot send images or source to a third party. Ask whether scanning can run inside your network, in CI, or on a runner you control, and what leaves the machine (results only, or content too).
What it covers. Operating system packages, language dependencies inside the image, embedded secrets, and misconfiguration are different findings. A tool that covers only one will leave gaps you must fill.
How it handles noise. An image can carry hundreds of known issues in packages that never run. Ask how the product decides what is reachable or loaded, and whether it can show the reasoning.
What it can fix. Rebuilding on a patched base image is often the quickest fix. Ask whether the tool proposes it or only reports.
What the record looks like. You want a timestamped result tied to an image digest, exportable as a report and as a machine-readable inventory (SBOM). Ask how long records are kept and who can edit them.
Model choice. If the product uses AI to explain findings, check whether you can run without it, or bring your own model, when policy requires.
Honest limits
A scan sees what is in the image at scan time. It does not see what happens at runtime, and it cannot tell you whether a network policy is set correctly in your cluster. Treat image scanning as one layer next to admission control, runtime monitoring and patch discipline. Reachability analysis reduces noise but is not a guarantee, so keep a path for a human to override it with a note.
We built Safeguard with this in mind: the CLI and local runner scan on your machine and push only results, Zero AI mode runs without a model, and reachability analysis ranks findings by exposure. Check any vendor, including us, against the list above in a trial on your own images.
What to do
- List the frameworks you answer to and write the evidence each one needs, in plain words.
- Decide where scanning may run and what may leave your network.
- Pick five real images, including your largest and oldest, for the trial.
- Score each tool on coverage, noise after prioritization, fix guidance and exportable evidence.
- Ask for a sample report and open it as an auditor would.
- Write the exception process before go live: who may accept a finding, for how long, and where it is recorded.
Quick check
Is container scanning required by law?
Usually not by name. Regulations ask you to identify and manage vulnerabilities. Scanning images is the common way to meet that for containerized workloads, and NIST SP 800-190 is a standard reference for it.
Do I scan images in the registry or in CI?
Both help. CI catches problems before release. Registry scanning catches new advisories for images already built, which matters because vulnerabilities are published after you ship.
Sources
- NIST SP 800-190, Application Container Security Guide
- NIST SP 800-218, Secure Software Development Framework
Last reviewed: 18 October 2026.
