Docker Desktop 4.3.2 fixes sensitive data in login logs

Login credentials need protection after authentication as well as while they travel to a service. The December 21 Docker Desktop 4.3.2 release notes describe a bug that can log an access token or password on the user's machine during login. It affects Desktop 4.3.0 and 4.3.1 when the user has logged in while running one of those versions. Reading the exposed data requires access to the user's local files.

The affected operation matters as much as the installed version. The notes do not say that every machine with an affected release necessarily contains a logged secret. They identify login on those versions as the condition. They also describe local file access as necessary to obtain the data, which is different from an unauthenticated remote disclosure.

I regard this as part of the security of the development environment itself. Docker makes an application environment transferable, but the developer tools around it also handle credentials. A well-constructed service image cannot compensate for a password being written into a local log by another component.

Logging creates another copy of a credential

The failure described by Docker changes where sensitive information may exist. A credential supplied to authenticate can also appear in a file used to record program activity. Those are different purposes with different readers. The release note identifies the information that may be present without providing a public implementation account of the logging path.

It would therefore be speculation to claim a particular internal formatter or network trace caused the bug. The established facts are the affected versions, the login condition and the local-file exposure. The repair is supplied in 4.3.2. Describing those boundaries accurately is more useful than inventing an explanation for code the announcement does not show.

Replacing the affected program and accounting for existing files are separate questions. The note establishes that the update fixes the logging bug. It does not establish that a previously written secret has been removed from every copy of a file or that the credential has ceased to work. An executable update should not be described as proof of those additional effects.

The practical implication follows from the nature of the data. A password or access token is useful beyond the text record that contains it. Where a logged credential exists, understanding its remaining validity requires considering the authentication service as well as the local application. That is a consequence of copying a credential into a second location, rather than a claim about a particular incident.

The scanner update addresses image contents

Desktop 4.3.2 also updates Docker Scan to 0.14.0. The release notes say this version can detect the Log4j issues identified as CVE-2021-44228 and CVE-2021-45046. This is a separate security function. It concerns the tool's ability to identify vulnerable contents in an image, while the login fix concerns how Desktop handles a user's credential.

The Docker Scan README at the supplied version describes scanning existing images by name or ID. Supplying the corresponding Dockerfile provides additional details. A documented invocation has this form:

docker scan -f Dockerfile service:example

The target is an existing image. The Dockerfile adds construction context to the result. It does not replace the need to identify which image was examined. A service name and tag used in an example must be replaced with the actual artifact intended for inspection.

The scanner's sample output shows dependency paths and base image attribution. Those details help locate how a package entered the artifact. A dependency inherited through the base image may require a different build change from one installed by an application-specific instruction. That attribution is useful information for a repair decision, but it is not itself the repaired image.

A detector update does not rebuild an application

Updating the scanner changes the analysis available to the developer. An existing application image remains the target of that analysis. If it contains an affected dependency, changing the tool used to detect it does not change the dependency's bytes. The difference is fundamental to interpreting the two security changes in this Desktop release.

The tagged README also documents --exclude-base for excluding vulnerabilities attributed to the base image, when a Dockerfile is supplied. That changes the report's scope. It does not remove the base image from the application or establish that the excluded findings are irrelevant to the resulting container.

Its example for hello-world reports no vulnerable paths and also says the scanner does not currently have vulnerability data for the image. That combination makes coverage part of reading a result. An empty finding list alone does not establish that every component in the target has been examined for every known defect.

The README supports JSON output with --json. Its sample includes a dependency count and package manager, together with base image remediation information. That gives automation more context than a simple finding count. Retaining the coverage message alongside the vulnerability array avoids discarding a qualification the scanner itself supplied. A machine-readable report still needs interpretation according to the fields present in that report.

I prefer small runtime images because their contents are easier to identify. The same discipline applies to these reports. The useful question is which artifact and dependencies the tool recognized, followed by what a finding says about those particular contents.

The local tool and the application need separate accounts

The scanner documentation says it uses a third-party provider and asks for consent before sending data to Snyk. It also describes Docker Hub login and provider authentication. Scanning therefore includes authenticated tool behavior around an image, alongside the analysis of the image itself.

Desktop 4.3.2 repairs the identified local login logging problem and supplies a scanner with the stated detection capabilities. A developer assessing this update needs to preserve both scopes. The first protects information handled by the development product. The second improves evidence about application artifacts, whose contents still have to be changed separately when a vulnerable dependency is found.