Scanning a Snyk Docker image means running Snyk's container scanner against a built image to find known vulnerabilities in both the base OS packages and your application dependencies, and the core workflow is a single snyk container test command. Snyk Container is one of the more widely used tools for this, it's included across all of Snyk's plans, and it does a genuinely good job of the two things that matter most: telling you which layer introduced a vulnerability and recommending a better base image. It also has limits worth knowing before you build your whole pipeline around it.
Here's how the scan actually works and where you'll want a second layer.
The basic scan workflow
Snyk's container scanning runs through its CLI. Install it, authenticate, then point it at a built image by name and tag:
npm install -g snyk
snyk auth
snyk container test my-app:latest
The scanner inspects the image's operating-system packages (Debian, Alpine, and so on) and, with the right flags, the application dependencies layered on top. The output lists each vulnerability, its severity, the package that carries it, and critically, which Dockerfile instruction or base-image layer introduced it. That layer attribution is Snyk Container's strongest feature, because it turns "you have 40 vulnerabilities" into "38 of them come from your base image, fix that and they're gone."
To also catch your application manifests inside the image, include the application-dependencies flag:
snyk container test my-app:latest --app-vulns
And to see the fix advice, which is where Snyk earns its reputation, use monitor mode or point at the Dockerfile:
snyk container test my-app:latest --file=Dockerfile
With the Dockerfile, Snyk can recommend a specific alternative base image that carries fewer known vulnerabilities, which is usually the single highest-leverage change you can make.
Base images are where the vulnerabilities live
The most useful lesson from any Snyk Docker image scan is that most of your findings come from the base image, not your code. A node:18 full image drags in a complete Debian userland with hundreds of packages, most of which your app never uses, each a potential CVE. Switching to a slim or Alpine variant, or a distroless image, can drop your vulnerability count dramatically because there's simply less installed.
Snyk's Dockerfile scanning surfaces this directly by suggesting a leaner or more current base tag. Acting on that recommendation, then rebuilding and rescanning, is a tight loop that removes whole batches of findings at once. Pinning the base image by digest rather than a floating tag also makes scans reproducible, so a rescan reflects a real change rather than an upstream base-image drift.
Free-tier limits and CI reality
Snyk offers a free plan, and container scanning is included in it, but with a cap. As of late 2025 the free tier includes a limited number of container tests per billing period (in the low hundreds), alongside separate limits for open-source, code, and IaC tests. That's fine for occasional local scans or a small project. It gets tight fast if you scan every image on every pull request in CI, where a handful of active repositories with normal PR volume can burn through the monthly container-test allowance in a few weeks.
The paid Team plan (billed per contributing developer, starting around 25 dollars per developer per month) raises those limits substantially, and Enterprise negotiates them. The practical implication: decide your scan cadence with the test budget in mind. Scanning on merge to main plus a nightly rebuild scan is often a better fit for the free or low tier than scanning every commit. If cost per scan is a deciding factor across tools, our pricing page and the Snyk comparison lay out how different models handle high-frequency CI scanning.
Wiring it into a pipeline
In CI, run the container scan after the image builds and fail the build on a severity threshold you can actually sustain:
snyk container test my-app:$CI_COMMIT_SHA --severity-threshold=high
Two operational notes. First, a fresh scan is only as current as the vulnerability database at scan time, so an image that passed last month can have new criticals today; schedule periodic rescans of images already in production, not just at build. Second, set the threshold where developers will respect it. Failing on every low-severity OS package guarantees the team adds --severity-threshold workarounds or ignores the gate. High and critical as a hard gate, with medium as a report, is a sustainable starting point.
What container scanning misses
A Snyk Docker image scan is a known-vulnerability scan, and that scopes what it can find. It matches installed package versions against advisory databases, so it's excellent at "this OpenSSL version has a known CVE" and blind to things that aren't a cataloged vulnerability. It won't catch a secret baked into an image layer, a misconfigured runtime (running as root, an overly permissive filesystem), or a malicious package that has no advisory yet. It also can't tell you whether the vulnerable code path is reachable in how you run the container; a CVE in a package your app never invokes still shows up.
That's not a knock on Snyk specifically; it's true of any version-matching container scanner. The takeaway is to layer it. Pair image vulnerability scanning with secret scanning of your layers, a Dockerfile linter or configuration check for the runtime posture (non-root user, dropped capabilities, read-only filesystem), and dependency scanning of your application source before it's even built into an image. An SCA tool such as Safeguard can cover the application-dependency and SBOM side across ecosystems, complementing the OS-package view a container scan gives you. Together they answer the questions a single scan can't.
Used with those caveats in mind, scanning your Docker images with Snyk is a straightforward, high-value habit: build, scan, fix the base image, rescan, and gate CI on a threshold your team will actually keep.
FAQ
How do I scan a Docker image with Snyk?
Install the Snyk CLI, run snyk auth, then snyk container test <image>:<tag>. Add --app-vulns to include application dependencies and --file=Dockerfile to get base-image upgrade recommendations. Gate CI with --severity-threshold=high.
Is Snyk Docker image scanning free?
Snyk's free plan includes container scanning but caps the number of container tests per billing period (in the low hundreds as of late 2025). That suits occasional or small-project scanning; high-frequency CI scanning usually needs the paid Team plan or higher.
Why does Snyk report so many vulnerabilities in my Docker image?
Most come from the base image, not your code. A full base image installs hundreds of OS packages your app doesn't use. Switching to a slim, Alpine, or distroless base, which Snyk's Dockerfile scan will recommend, removes large batches of findings at once.
What does a Snyk Docker image scan not catch?
It's a known-vulnerability scan, so it misses secrets baked into layers, runtime misconfigurations like running as root, malicious packages without an advisory, and whether a vulnerable code path is actually reachable. Pair it with secret scanning and configuration checks.