Container scanning: 12 questions to ask a vendor before you buy

Before buying a container scanner, ask what it checks in images and registries, how it decides a finding is real, where it runs, and what it cannot see. NIST SP 800-190 gives you the checklist: image vulnerabilities, configuration defects, embedded malware, embedded secrets, untrusted images and stale images.

Why use NIST SP 800-190 as the yardstick?

Vendor feature lists are written to win comparisons. A neutral standard is harder to bend. NIST's Application Container Security Guide groups risks into images, registries, orchestrators, containers and the host operating system. A scanner mostly speaks to the first two groups, plus parts of the third and fourth. Knowing that stops you from paying for coverage a scanner was never going to give.

The guide lists these image risks: vulnerabilities, configuration defects, embedded malware, embedded clear text secrets, and use of untrusted images. Its registry risks are insecure connections, stale images, and weak authentication and authorization. Use each as a question.

Questions about what it finds

1. Which layers does it open? Ask whether it reads OS packages, language packages and files copied in by hand, or only what a package manager reports.
2. Which vulnerability sources does it use, and how fresh are they? Ask for the list and the update interval, and what happens when sources disagree.
3. Does it check image configuration? Running as root, exposed ports and missing health settings are the defects NIST describes. A scanner that only matches CVE IDs will miss them.
4. Does it look for secrets in layers? A secret deleted in a later layer can still be in the image.
5. Can it flag malware or suspicious packages? Ask how, and how it handles a false alarm.

Questions about whether a finding matters

6. Does it tell me which findings are reachable? A long list of flaws in packages your code never calls wastes engineering time. Reachability analysis narrows the list, but ask the vendor to show it on one of your own images, not a demo image.
7. How does it handle a vulnerability with no fix? You want a clear state, owner and review date, not a permanent red badge.
8. Can I export results in a standard format? SBOM formats and SARIF let you keep your data if you switch tools.

Questions about where it runs

9. Does the image or its metadata leave my network? Ask what is sent, where it is stored and for how long. Some teams need scanning to run locally.
10. Does it scan registries on a schedule, not only at build time? NIST names stale images in registries as a risk. An image that passed last quarter can fail today as new flaws are published.
11. How does it block or warn in CI? Ask for a gate that is configurable by severity and reachability, with an override path that leaves an audit record.

The honest limits

12. What does it not cover? Expect a straight answer. A scanner does not see runtime behavior, orchestrator misconfiguration or a compromised host. NIST treats those as separate risk areas with separate countermeasures. A vendor who claims to cover everything has not read the guide.

How Safeguard answers these

Safeguard scans from the web app, the CLI and the local runner, which scans on your machine and pushes only encrypted results. It offers reachability analysis and works with Full AI, Zero AI or your own model. Ask us the same twelve questions.

What to do

1. Pick three of your real images, including a messy one, for a trial.
2. Run all twelve questions past each vendor in writing.
3. Score answers against the five image risks and three registry risks in NIST SP 800-190.
4. Ask each vendor to show a reachability result on your images.
5. Test the CI gate with a deliberately failing build.
6. Record what each tool does not cover and assign that gap to another control.

Quick check

Sources

• NIST SP 800-190: Application Container Security Guide
• NIST SP 800-190 full text (PDF)

Last reviewed: 18 October 2026.