Qualys Container Sensor Compatibility With Docker Version 29

Impact:

Qualys TotalCloud Kubernetes and Containers Security Customers

Summary:

With the latest version of Docker version 29, there are major architectural changes, including the change of the default image store from Overlay2 to Containerd(overlayfs). This is leading to the incompatibility of current versions of Qualys Containers Sensors for container and image scanning, including:

• General Sensor on Standalone Docker Hosts With Docker Version 29
• Registry Sensors/Scanners
• CI/CD Sensors for scanning CI/CD pipelines. If you are using QScanner to scan your CI/CD pipeline you are not affected.

The Docker team has acknowledged the downstream impact and disruption in their latest release notes, and the Qualys team is working actively to address sensor support for Docker version 29.

For more information, go to the Docker blog.

Recommendation:

We strongly recommend pausing any upgrades to Docker version 29 and above in your environments until support is added.

Existing Docker versions, including version 28 and below, are supported and will continue to function.

If you have already upgraded your systems to Docker version 29, please contact Qualys customer support for assistance.

Updates:

December 21, 2025: The Qualys team is currently working on adding sensor support for Docker version 29. Updates will be posted here. 

Additional Background:

In Docker Engine version 29 (released late 2025), the transition to the containerd image store as the default backend has introduced several fundamental breaking changes. These changes primarily affect how images are stored, identified, and listed.

1. Identity Shift: Deterministic Image IDs

The most visible breaking change is that the Image ID is now often identical to the Manifest/Index Digest.

• Old Behavior: The Image ID was a local “Config SHA” generated by the Moby graph driver. This ID was unique to your local daemon’s view of the image.
• v29 Behavior: Under the containerd image store, Docker uses deterministic IDs based on the image’s content manifest.
• Impact: Automation scripts that expect a distinct 12-character “Config SHA” may find that the IMAGE ID field now contains the same value as the DIGEST field. This makes image IDs consistent across different machines but breaks workflows that relied on the local-only Config SHA.

2. Architectural Default: Containerd Image Store

The legacy “graph drivers” (such as overlay2, btrfs, and zfs) have been deprecated and replaced by the containerd snapshotter framework for all new installations.

• Impact: Images are stored in /var/lib/docker/containerd rather than /var/lib/docker/overlay2. Tools that directly inspect the filesystem for layer data will fail.
• Multi-Arch Support: Docker now natively stores multi-platform images (indexes) locally, whereas previously it only stored the specific architecture of the host.

3. Strict API Enforcement (v1.44)

Docker v29 strictly mandates API version 1.44 (originally introduced in v25.0).

• Impact: Older clients (CLI versions < 25) or third-party integrations (like older versions of Portainer, Traefik, or Watchtower) will receive “client is too old” errors.
• Missing Fields: The docker inspect JSON output no longer includes empty or default-value fields. Parsers that expect a specific key to exist (even if null) will encounter “key not found” errors.