Docker Desktop 3.3.3 updates the tools behind image scanning

A scanner can report no vulnerable paths while also saying it has no vulnerability data for the image. The Docker Scan documentation at version 0.8.0 contains exactly that combination in its hello-world example. This is a useful detail to understand as Docker Desktop 3.3.3, released May 6, updates the bundled scanning tools. A clean-looking result needs to be read together with what the scanner examined.

Desktop now includes Docker Scan 0.8.0 and Snyk 1.563.0. The same release fixes diagnostic uploads from the Troubleshoot screen. Its release notes do not claim that these component updates establish new coverage for every image type, and there is no basis for reading an ordinary dependency update as such a guarantee.

I prefer a small final service image, often containing a static Go binary. That preference makes the coverage question relevant. Reducing the contents of an image is useful, but it does not make every dependency visible to every scanner or turn an empty finding list into proof of safety.

The image is the scan target

Docker Scan accepts an existing image by name or ID. Supplying a Dockerfile adds information about how the image was constructed. The documented invocation uses -f to associate that file with the image being examined:

docker scan -f Dockerfile service:example

This command assumes that service:example identifies the intended image and that the supplied Dockerfile corresponds to it. The distinction matters because the file and the artifact are separate inputs. A familiar filename alone cannot establish that it describes the image currently under inspection.

The tagged README's sample report identifies a base image and shows dependency paths that introduce a vulnerable package. It can attribute findings to the base image or to an instruction in the supplied Dockerfile. This makes the report more useful for deciding where a dependency entered the artifact, instead of treating every reported package as a direct application dependency.

Attribution can change the appropriate repair. A package inherited through the base image has a different construction history from one installed by an application-specific instruction. The report helps locate that history, although choosing the replacement still requires understanding what the image needs to contain.

Filtering changes the question being answered

The --exclude-base option requires the Dockerfile and excludes vulnerabilities attributed to its base image. It is a filter on the report. It does not remove packages from the existing image or repair the base image. A result obtained with that option answers a narrower question than the full scan.

That distinction is easy to lose when comparing totals. The README shows a report with base image findings and another with the base excluded. Different counts are expected because the scope has changed. Recording the invocation alongside a result preserves the meaning of the comparison.

The documentation also supports selecting a minimum severity with --severity. Its stated levels are low, medium and high, with the selected level and higher included. Filtering by severity is another deliberate reduction in reported findings. A lower count after changing the threshold describes the presentation criterion, not a change to the image.

For interpreting individual findings, dependency paths are often more informative than the total. The from information identifies routes through which a package appears. Multiple routes can refer to the same underlying issue. The documented --group-issues option groups those findings, while --dependency-tree displays dependencies before the scan result.

Structured output retains context

The --json option emits a structured report. The README's example includes dependency count, package manager information and a summary, alongside vulnerability data. It also includes base image remediation information whose message says the scanner does not currently have vulnerability data for that image.

An automated reader needs to preserve that context. Looking only for an empty vulnerability array discards information already present in the same report. The example establishes that the summary and the coverage message can coexist, so they should not be collapsed into one unconditional approval signal.

I find this more useful than a single security score. A report should help explain which contents it recognized and where a finding came from. That information gives an engineer a concrete dependency to examine and a build step that may need to change.

Scanning depends on a provider

The plugin documentation says Docker Hub login is required and that scanning uses a third-party provider. The first scan requests consent before sending data to Snyk. Provider authentication has its own login flow. These are parts of the documented operation of the tool, so a scan result cannot be understood solely as the output of reading a local Dockerfile.

Desktop 3.3.3 updates the components that perform this work and repairs an unrelated diagnostic upload failure. The practical value of the scanner remains in the detail it returns. Image identity establishes what was examined, Dockerfile attribution describes how dependencies arrived, and coverage information qualifies what the reported absence of findings means for that artifact.