Docker Desktop's extension ecosystem lets scanning happen where developers already work: the local build environment, before an image ever reaches a registry. Snyk's Docker Desktop Extension is one of the most widely installed examples of this pattern, embedding vulnerability and configuration scanning directly into the Docker Desktop UI. Instead of waiting for a CI pipeline or a registry-side scan to flag a problem hours later, the extension inspects an image the moment it's built or pulled locally, surfacing known CVEs, base image guidance, and Dockerfile issues in a panel a developer can act on immediately. For a supply chain security team, this matters because the earlier a vulnerable dependency is caught, the cheaper it is to fix and the less likely it is to end up baked into a shipped artifact. This piece walks through how the extension actually works mechanically, what it can and can't see, and where it fits relative to registry and CI-based scanning.
What is the Snyk Docker Desktop extension and how do you install it?
The Snyk Docker Desktop extension is an add-on installed from Docker Desktop's built-in Extensions Marketplace, first made generally available in 2022 alongside Docker's extension SDK. Users open Docker Desktop, go to the Extensions tab, search for "Snyk," and install it with a few clicks — no separate binary or daemon to manage outside of Docker Desktop itself. On first use, the extension prompts for authentication against a Snyk account (free tier included), which links local scan activity to an organization in the Snyk web console. Once authenticated, it adds a "Snyk" panel inside the standard Docker Desktop Images view, so scanning becomes part of the same interface developers already use to manage local images, rather than a separate tool they have to context-switch into.
How does the extension actually scan an image before it's pushed?
The extension scans an image by reading its local layers and manifest directly from the Docker Desktop image store, without requiring the image to be pushed anywhere first. When a developer selects an image in Docker Desktop, the extension invokes Snyk's container scanning engine (the same underlying analysis used by the snyk container test CLI command) against that local image reference. It extracts the package manifests and installed package lists from each layer — for example, dpkg status files on Debian-based images, apk databases on Alpine, or language-specific manifests like package-lock.json or requirements.txt if they're present in the image — and cross-references installed package versions against Snyk's vulnerability database. Because this all happens against the local image, a developer can scan a freshly built image on their laptop before ever running docker push, closing the gap between "build" and "the first time anyone checks it for problems."
What does the extension actually detect, and what does it miss?
The extension detects known CVEs in OS packages and application dependencies baked into the image, plus a set of Dockerfile best-practice issues, but it does not detect runtime behavior or zero-day flaws. Findings are typically split into two categories inside the UI: "vulnerabilities," which lists CVEs by severity (critical/high/medium/low) with a fix recommendation such as "upgrade base image to node:20-slim," and "recommendations," which flag Dockerfile patterns like running as root, using an overly broad COPY . instruction, or pinning to a mutable tag like latest instead of a digest. What it cannot do is catch vulnerabilities that aren't yet in Snyk's database, malicious behavior injected at runtime, or issues in code paths that only manifest when the container actually executes — it is a static, manifest-based scan of what's installed, not a dynamic analysis of what the container does. This distinction matters when teams treat a clean scan as a full security signal rather than one layer of coverage.
Why does scanning locally, before push, actually reduce risk?
Scanning before push reduces risk because it moves the first vulnerability check to the point with the lowest fix cost and the smallest blast radius. If a scan only happens after an image lands in a registry or during a CI pipeline run, a vulnerable image may already have been pulled by other developers, referenced in a staging deployment, or cached across multiple build agents by the time anyone sees the finding. Catching a critical CVE in a base image locally means the fix is a one-line Dockerfile change and a rebuild, with zero downstream consumers affected. This is the same "shift left" logic behind pre-commit hooks and IDE-integrated SAST tools: the cost of a fix tends to grow with the number of systems that have already consumed the vulnerable artifact, so the local Docker Desktop step functions as the cheapest possible gate before that fan-out begins.
Does a clean local scan mean the image is safe to deploy?
No — a clean local scan reflects Snyk's vulnerability database at the moment of that scan, not a guarantee that the image stays clean afterward. Vulnerability databases are updated continuously as new CVEs are disclosed (the National Vulnerability Database alone publishes on the order of dozens of new entries daily), so an image scanned clean on a Monday can have a newly disclosed CVE in one of its packages by Wednesday even though nothing in the image itself changed. The local extension scan is also a point-in-time, developer-initiated check — it doesn't run automatically on every subsequent pull, every registry push, or every deployment unless a team wires up additional automation (Snyk's CLI in CI, registry integrations, or admission controllers) to re-scan at those later stages. Treating the Docker Desktop extension as the only scan in the lifecycle leaves a gap between "clean at build time" and "still clean at deploy time," which is exactly the window where newly disclosed CVEs and drifted registry images tend to surface.
How does this fit alongside registry and CI-based scanning?
It fits as the earliest of several checkpoints, not a replacement for the ones that come after it. A typical pipeline that uses Snyk's Docker Desktop extension for local development will still run a scan in CI when the image is built for real (catching anything introduced between the developer's laptop and the actual build pipeline), and often a separate scan when the image is pushed to or stored in a registry (catching drift from newly disclosed CVEs after the fact). Docker's own extension architecture is intentionally scoped to the local desktop environment — it has no visibility into what happens to an image after it leaves the developer's machine, so registry-side and CI-side scanning cover the parts of the lifecycle the desktop extension structurally cannot see.
How Safeguard Helps
Local, developer-initiated scans like the Docker Desktop extension are a genuinely useful early checkpoint, but they only cover one moment in an image's life — the build. Safeguard is built around the parts of the supply chain that a point-in-time desktop scan can't reach: continuous re-evaluation of images already sitting in registries as new CVEs are disclosed, verification that what actually gets deployed matches what was scanned (rather than trusting a tag that could have been overwritten), and provenance tracking so a team can answer "where did this image come from and what changed in it" rather than just "did it have a known CVE the last time someone checked." Rather than treating any single scan — local, CI, or registry — as the final word, Safeguard's approach is to maintain that visibility continuously across the full path from build to production, so the gap between "clean when built" and "still clean when running" doesn't go unmonitored.