What are the free container scanning options and their limits?

Free container scanning comes in two main forms: open source command line scanners you run yourself, and the basic scan built into a cloud registry. Both find known vulnerabilities in image packages. Neither tells you which findings matter in your runtime, and each has gaps in coverage or upkeep that you should know first.

What do open source scanners cover?

A typical open source image scanner reads the packages inside an image and matches them to advisory data. The documentation for one widely used Apache-2.0 licensed scanner says it covers operating system packages for Alpine, Debian, Ubuntu, RHEL, Oracle Linux and Amazon Linux, and language packages for Ruby, Java, JavaScript, Python, .NET, Go, PHP and Rust. It reads Docker, OCI and Singularity image formats, and supports OpenVEX to filter results.

Another popular scanner in this category turns on vulnerability and secret scanning by default for images. Misconfiguration and license checks are off by default and you opt in. Its docs say misconfiguration scanning is "not useful in most cases" for images, because that feature is aimed at infrastructure as code files.

Two details matter in practice. Defaults differ between tools, so the same image can produce different counts. And the scan only sees what is in the image, not how it runs.

What do cloud registry scans cover?

A registry basic scan is convenient because it is already there. Take the AWS container registry documentation as the example of the category. Basic scanning checks operating system vulnerabilities against the CVE database, on push or manually. Enhanced scanning, a separate tier delivered through another AWS service, adds language package vulnerabilities and continuous rescans. The docs also note that switching between the two types makes earlier scans unavailable until you switch back.

So if your image is a Node or Python service, a basic OS-only scan misses most of the code you shipped. That is the first limit to check.

Where do free options usually stop?

• No runtime context. A finding in a package that never loads looks the same as one on your request path. Reachability analysis is a separate capability.
• Data freshness is your problem. A scan is only as current as the last time you ran it. Rescan stored images, not only new builds.
• Noise. Base images carry many OS findings with no fix available yet. Without a policy, teams stop reading the report.
• Unsupported or unusual images. Distroless, scratch and custom base images may list fewer packages. Test with your own images.
• Ownership. Free tools need someone to wire them into CI, keep versions current, and triage output.

What should you ask before choosing?

1. Does it scan both OS and language packages in your images?
2. Does it rescan stored images when new advisories land?
3. What advisory sources does it use, and can you see them?
4. Can it accept a VEX document or suppression file with a reason and expiry?
5. Does it output a format your CI understands, such as SARIF?
6. Who owns it after the first week?

Is there a free way to check dependencies, not images?

Safeguard offers a free in-browser scan at gold.safeguard.sh/scan, up to 100 dependencies. That covers a dependency list rather than a container image, so treat it as a quick check on your application packages, a complement to an image scan and not a replacement.

What to do

1. Pick one open source scanner and run it on your three most important images this week.
2. Check that the output includes language packages, not just OS packages.
3. Add it to CI, failing only on fixable critical findings at first.
4. Schedule a rescan of images already in your registry.
5. Write down who triages and how often.

Quick check

Sources

• Open source image scanner documentation, container image target, fetched 18 October 2026.
• Open source scanner README, supported packages and VEX, fetched 18 October 2026.
• AWS documentation: image scanning in Amazon ECR, fetched 18 October 2026.

Last reviewed: 18 October 2026.