Open Source Container Scanner
A container image is layers of other people's software - a base image, its package manager's dependencies, and whatever your build copies on top - and a vulnerability introduced upstream weeks ago rides all the way to production unless a check catches it first. The label 'container scanner' actually covers several different jobs: matching known CVEs in image layers, linting Dockerfiles and Kubernetes manifests, auditing hosts against hardening benchmarks, and watching running containers for suspicious behavior. The open source tools here let you see exactly how each verdict is reached and run the check inside your own pipeline, so you can gate builds and deploys on findings you trust without shipping your artifacts to a third party.
Harbor
Cloud native registry for storing, signing, scanning, and replicating container images and Helm charts
Kubescape
Kubernetes security platform spanning IDEs, CI/CD pipelines, and live clusters
Clair
Static analysis for container image vulnerabilities, accessed through an API
Docker Bench for Security
Automated checks for Docker hosts and containers against the CIS Docker Benchmark
Falco
Cloud native runtime security for Linux that detects abnormal behavior in containers and hosts in real time
kube-bench
Checks whether Kubernetes is deployed according to the CIS Kubernetes Benchmark
KubeLinter
Static analysis for Kubernetes YAML files, Helm charts, and Kustomize manifests
Dockle
Container image linter that checks images against best practices and CIS Benchmarks
KICS
Static analysis for infrastructure as code that finds security, compliance, and misconfiguration issues
Our picks
Image CVE analysis over an API: Clair Clair performs static vulnerability analysis of OCI and Docker images, indexing each image and matching its contents against known CVEs. Clients submit images through its API, which makes it a natural fit for wiring vulnerability checks into a registry or pipeline. It runs as a self-hosted service, so build artifacts never leave your infrastructure.
Kubernetes security across the lifecycle: Kubescape Kubescape covers security, compliance, and misconfiguration from the IDE through CI/CD to a running cluster. It scans against frameworks like NSA, MITRE ATT&CK, and CIS, uses the Grype engine for image scanning with an offline database option, and runs an in-cluster operator for continuous scanning and eBPF runtime detection. It is a CNCF project.
Image hardening linter: Dockle Dockle lints a built image against best practices and CIS Benchmarks, flagging secrets baked into layers, root users, unnecessary packages, and risky environment variables. It ships as a single static binary, reads private registries through environment variables, and emits SARIF. It complements a CVE scanner rather than replacing one, catching hygiene problems vulnerability matching misses.
Runtime threat detection: Falco Falco watches running containers and hosts at the kernel level, evaluating system-call events against a rules engine and enriching them with container and Kubernetes metadata. It ships rules for malicious activity and CVE exploits and can forward events to SIEM or data-lake systems. It covers the gap image and manifest scanning leave open: what a container does once it is live.
Matching a scanner to the job in front of you
"Container scanner" bundles several different jobs, and choosing well means naming the one you have. Finding known vulnerabilities in image layers is what Clair does through an API and what Harbor builds into a registry. Checking an image for hardening mistakes - secrets baked in, running as root, unnecessary packages - is Dockle's job, while static analysis of Kubernetes and infrastructure-as-code manifests belongs to KubeLinter and KICS. Auditing a host or cluster against a CIS benchmark is what Docker Bench for Security and kube-bench do, and watching a running container is Falco's domain. These overlap less than the shared label suggests.
For the vulnerability-matching tools specifically, coverage and accuracy decide whether findings help or just pile up. Container results depend on distro advisories, package names, and backported patches, so a scanner that compares raw version strings will flag packages a vendor already fixed and train engineers to ignore it. Prefer tools that cite the distro source, the installed package release, and a fixed version, and that emit reproducible SBOMs and stable JSON for audit trails. Kubescape leans on the Grype vulnerability engine and offers an offline database, which matters in air-gapped builds.
Then fit the scanner to your release path rather than a command-line demo. CI scans give developers fast feedback, registry scanning like Harbor's catches images built outside the main pipeline, and cluster-side controls stop risky workloads at admission - Kubescape runs an in-cluster operator for exactly that, and Falco adds runtime detection once containers are live. Decide where policy belongs: a warning in a pull request, a failed build, or a blocked deployment. Tools that emit SARIF and JSON, as KubeLinter and Dockle do, wire into code review and dashboards without custom glue.
Related categories
Frequently asked questions
These tools do different things - which one is a 'container scanner'?+
The category is broader than it sounds. Clair and Harbor find known CVEs in image layers, Dockle lints images for hardening problems, KubeLinter and KICS statically analyze Kubernetes and infrastructure-as-code manifests, Docker Bench for Security and kube-bench audit hosts and clusters against CIS benchmarks, and Falco watches running containers for suspicious behavior. Kubescape spans several of these. Decide which job you have before comparing tools, since they are not substitutes for one another.
Why do two scanners report different vulnerabilities for the same image?+
They draw on different vulnerability sources, package detection logic, and severity mappings, and they treat vendor backports differently. One may count a distro-patched package as fixed while another reports the upstream CVE as open. This disagreement is normal, so evaluate with your own images and judge whether a tool explains its evidence rather than which one produces the largest number. Raw finding counts are a weak way to pick.
How should a scanner handle patched packages with open upstream CVEs?+
Container images often use distro packages that backport a security fix without bumping the upstream version number. A scanner that only compares version strings will flag those as vulnerable and generate noise. Prefer one that reads the vendor advisory and cites the distro source, the installed package release, and the fixed version, so you can see why an issue is considered open or resolved. This single behavior removes a lot of false positives.
Where in the delivery pipeline should scanning happen?+
Usually in more than one place. Scanning in CI gives developers fast feedback before an image is promoted. Registry scanning, which Harbor builds in, catches images built outside the main workflow. Cluster-side admission or runtime checks - Kubescape's in-cluster operator, or Falco for live behavior - enforce policy at the boundary. The right mix depends on build speed and how many exceptions you can tolerate.
Can these scanners run in an air-gapped environment?+
Many can, if they support offline database mirroring and scan images from a local registry or a saved archive. Kubescape, for example, offers an offline vulnerability database. The operational question is how vulnerability updates are transported, verified, and applied without internet access, and whether reports and SBOMs avoid calling external services. Air-gapped scanning works, but keeping the database fresh becomes a recurring job you have to own.
Do container scanners find secrets and misconfigurations, or only CVEs?+
It varies by tool, which is why the category is broad. Dockle flags secrets baked into images, root users, and risky Dockerfile patterns; KubeLinter and KICS catch misconfigurations in manifests and infrastructure-as-code; Docker Bench and kube-bench check hardening against CIS benchmarks. Pure vulnerability matchers like Clair focus on CVEs. Decide whether you want one tool covering image hygiene and CVEs or separate tools with clearer ownership of each.
How do we keep exceptions and false positives from piling up?+
Give every exception an owner, a reason, a scope, and an expiration date, rather than a blanket ignore file that never expires. Tie each exception to a specific package, CVE, image, and environment so it does not silently suppress unrelated findings. The scanner should make expired exceptions easy to review and separate accepted risk from work that still needs doing. Without that discipline, even accurate findings turn into ignored backlog.