Qualys Container Sensor Compatibility with Docker Version 29

Who Will Be Impacted?

Qualys TotalCloud™ Kubernetes and Container Security Customers

Summary

With Docker 29, there are major architectural changes, including a change in the default image store from Overlay2 to Containerd (overlays). 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 29 version
• 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 29.

For more information, visit the Docker blog.

What We Recommend

We recommend pausing any upgrades to Docker 29 or later versions 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 29 version, please contact Qualys customer support for assistance.

Updates

• December 21, 2025
  The Qualys team is currently working on adding sensor support for Docker 29. Updates will be posted here. 
• January 20, 2026
  We are adding end-to-end image and container scanning from sensor hosts running Docker 29 into two upcoming Qualys Sensor releases: Phase 1 and Phase 2.

Phase 1 is planned for delivery on January 19, 2026 (only for selected customers). This phase includes fixes for container and image inventory reporting from Docker 29 sensor hosts and applies only to General sensors. If you would like this Phase 1 fix, please contact Customer Support.

Note: With this fix, only images that match the host architecture will be reported. For example, if an ARM64 image is pulled on an x86 sensor host, it will not be reported, as this is not a supported configuration.

Phase 2 is planned for February 25. 2026 and will include end-to-end image and container scanning support across all three sensor types: Registry, CI/CD, and General.

Note: There is a change in the sensor installation command for hosts running Docker 29. Before installing the sensor on a Docker 29 version host, please refer to the sensor release notes for updated installation steps.

Additional Background

In Docker Engine 29 (released late 2025), the transition to containerd as the default image store 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.
• Version 29 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 images for the host’s architecture.

3. Strict API Enforcement (v1.44)

Docker 29 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.