There is no single best container scanner for every team. Choose by what it reads inside an image (OS packages and application libraries), which advisory data it trusts, how it ranks findings, whether it exports SBOMs, and where it runs in your pipeline. Then test two or three candidates on your own images.
What should a container scanner actually inspect?
NIST SP 800-190, the container security guide first published in September 2017, covers the risks containers introduce and what to do about them. Treat it as the baseline reading, then judge scanners by what they inspect inside an image.
So ask a candidate to cover four things:
- Operating system packages from the base image.
- Language libraries added on top, such as npm, Maven or Python packages.
- Files that are not in any package manager, such as a binary copied into a layer.
- Embedded secrets and risky configuration.
Many tools do the first two well and the others unevenly. Build a test image with one of each and see what shows up.
Where does the advisory data come from?
Ask the vendor to name its sources. OSV is one public example: it aggregates vulnerability data across 38 ecosystems, including Debian, Ubuntu and Alpine alongside language registries like npm, PyPI and Maven. A scanner that matches Linux distribution advisories correctly will report fewer false positives than one that matches only by upstream version number, because distributions often backport fixes without changing the version string. Test this by scanning a well patched base image and counting findings you can show are already fixed.
How does it rank what it finds?
An image full of base layer packages can produce hundreds of findings. Ranking decides whether anyone reads them. Useful public signals:
- Listing in the CISA KEV catalog, which tracks vulnerabilities exploited in the wild.
- EPSS, an estimate of the chance a CVE is exploited in the next 30 days.
- Whether the vulnerable package is loaded or called at all. Reachability analysis tries to answer that, and it works better for application code than for every OS package, so ask what it covers.
Be wary of any vendor that claims a risk score with no explanation. You should be able to see why a finding is high.
Can it prove a finding does not matter?
Teams spend real time on findings that are not exploitable in their product. Look for support for VEX, which conveys whether a vulnerable component can actually be exploited in the product that uses it. If the tool cannot record "not affected" with a reason and carry it forward to the next scan, the same finding will return every week.
Does it fit where you work?
Check the places a scan can run: on a developer machine, in CI before push, at the registry when an image lands, and against running workloads. Each catches different things. A registry scan finds images nobody rebuilt. A CI scan stops a bad build earlier but never sees an image that was already deployed and later affected by a new advisory.
Ask about exit codes and output formats such as SARIF so a failing build is easy to wire. Ask how it handles a new advisory landing against an image scanned last month. That is the rescan question, and it is often the weak spot.
Honest limits to expect
No scanner finds unknown flaws, malicious code that has no advisory, or misconfiguration it has no rule for. A clean report means no known issue matched, not that the image is safe. A scanner also cannot fix a vulnerable base image. Someone has to rebuild and redeploy.
What to do
- Build a test set: one clean image, one old image, and one with a vendored binary and a planted dummy secret.
- Run each candidate on the same set and compare package lists first.
- Count findings you can show are already fixed by the distribution.
- Check ranking on your top ten findings against KEV and EPSS.
- Export an SBOM and open it in a second tool.
- Test the rescan path with an image scanned a month ago.
- Score the results in a table and decide with your platform team.
Quick check
Is the scanner with the most findings the most accurate?
Not necessarily. More findings can mean more false positives. Verify a sample by hand and compare against distribution advisories.
Do I need a scan at the registry if I scan in CI?
Usually yes. CI sees an image once. New advisories appear after deploy, and a registry or runtime rescan catches those.
Can I try something free first?
You can run the free in-browser scan at gold.safeguard.sh/scan for up to 100 dependencies to see how a dependency list is reported before you commit to a trial.
Sources
- NIST SP 800-190, Application Container Security Guide
- OSV
- CISA Known Exploited Vulnerabilities catalog
- FIRST EPSS
- CycloneDX VEX
Last reviewed: 18 October 2026.
