Docker’s Zero-CVE Push Turns Supply-Chain Security Into an OS-Level Default

Somewhere in the past year, the tools defenders trust to catch vulnerabilities and misconfigurations in other people’s code became targets of exactly that kind of attack themselves. Aqua Security’s Trivy scanner and Checkmarx’s KICS infrastructure-as-code analyzer were both hit by credential-theft campaigns that pushed malicious versions through their own legitimate publishing channels. On August 17, 2026, Docker announced the broadest expansion yet of its Hardened Images program in response: hardening that now reaches below the container image to individual operating system packages, and up the stack to Helm charts and MCP servers.

“A permanent shift in the threat landscape.” That is how Mark Lechner, Docker’s Chief Information Security Officer, described the wave of attacks on trusted developer tooling, according to Docker’s own announcement. The company’s response is to widen the trusted foundation under its Docker Hardened Images (DHI) catalog and tighten how that trust gets enforced, from the packages inside an image down to the individual developer’s machine.

What happened to Trivy and KICS

Independent researchers at Wiz traced one wave of attacks to a group tracked as TeamPCP, which compromised the Trivy scanner on March 19, 2026 using access retained from an earlier, incompletely contained breach. The group made commits impersonating legitimate maintainers to trigger a malicious v0.69.4 release, then separately abused a compromised Aqua service account to push further malicious changes across dozens of tags on the trivy-action and setup-trivy GitHub Actions. The poisoned tooling harvested SSH keys, cloud credentials, Kubernetes tokens, and GitHub Actions runner secrets from anyone who pulled the compromised versions, then exfiltrated the data to attacker-controlled infrastructure. Days later, Arctic Wolf reported that the same group reportedly used previously stolen CI/CD secrets to compromise two Checkmarx GitHub Actions, including kics-github-action, on March 23.

A separate incident hit Checkmarx’s KICS again a month later, this time on Docker Hub itself. In its own account of the breach, Docker’s security team says a threat actor authenticated to Docker Hub on April 22, 2026 using valid Checkmarx publisher credentials and overwrote five tags of the checkmarx/kics image, plus created two new malicious tags. The poisoned binary kept its normal scanning behavior intact while quietly collecting and encrypting scan output before sending it to attacker infrastructure. Because KICS scans Terraform, CloudFormation, and Kubernetes configuration files, that output routinely contains secrets, credentials, and internal topology. Docker says its own infrastructure was not breached in either case; both attacks relied on stolen publisher credentials moving through otherwise legitimate publishing flows, and Docker caught the KICS push within about half an hour and disabled the malicious digests.

Hardening drops below the image

The centerpiece of the announcement is Docker Hardened System Packages, which takes the hardening model Docker already applies to full container images and applies it to the individual packages inside them. Every package across both Alpine and Debian is now built from upstream source, patched, and maintained by Docker through the same SLSA Build Level 3 pipeline that builds the images themselves, giving auditors a verifiable build chain instead of a vendor claim to take on faith.

Coverage that began with Alpine now spans Debian too, and Python, the catalog’s most-pulled image, is among the first packages to ship fully hardened as that Debian coverage rolls out. DHI Enterprise customers get direct apt or apk access to Docker’s hardened package repository, letting them pull the same hardened packages into images they build themselves rather than only into images Docker ships. Docker publishes the Debian and Alpine package lists so customers can track coverage as it expands.

Patching software after its official end of life

Docker is also extending security coverage past a project’s own end-of-life date. Its example is MinIO, the object-storage server whose upstream project was archived in February 2026. In the DHI catalog, MinIO keeps receiving patches and hardening on Docker’s own schedule, which means a team depending on it can plan a migration on its own timeline instead of being forced to move the moment upstream support stops.

Customization that keeps its guarantees

A common failure mode for hardened-image programs is that the guarantees hold only until a customer modifies the image. Docker says DHI customization is built to avoid that: teams define what their images need, such as CA certificates or internal agents, and Docker rebuilds the customized image through the same hardened pipeline on every upstream patch, carrying the SBOM and attestations forward rather than treating customization as the point where the vendor’s responsibility ends.

For organizations whose data-residency rules keep workloads inside the European Union, Docker says EU-hosted customized images are arriving this September, living in Docker Hub’s EU region with the same SBOMs, attestations, and SLA as images hosted elsewhere.

Hardening moves up the stack, too

The same standard is extending beyond container images. The DHI catalog now includes fully supported Helm charts, so Kubernetes deployments can start from a hardened baseline, and a growing set of hardened MCP servers, the connective tissue that lets AI agents call external tools. Docker’s framing is direct: the tools an agent calls deserve the same scrutiny as the image that runs it.

Enforcement reaches the developer’s machine

Scanning identifies what is wrong; policy is what stops it from shipping in the first place. Docker’s answer here is Docker Scout policy, which evaluates customizable rules from the command line and inside CI using the same policies Docker applies to certify its own hardened images. The distinguishing feature Docker is emphasizing is where that enforcement lives: not just at the registry, which developers can route around, but on the developer’s own machine, closing the gap where security programs most often lose the fight for adoption. Docker describes it as an additive control that works alongside whatever scanners a team already runs, bundled into existing Docker subscriptions rather than sold as a separate product.

Why it matters

The scale Docker is defending is not small. The DHI catalog has grown past 4,000 hardened images, plus MCP servers, Helm charts, and ELS images, drawing more than 3.5 million pulls a week with over a million builds running regularly to keep everything patched. Docker’s own post also points to industry estimates that more than a quarter of production code is now AI-written, with coding agents pulling in dependencies at machine speed, a trend this site has covered in the context of Docker’s own 2026 supply chain survey and the Nx npm supply-chain attack.

That volume is exactly what makes the Trivy and KICS incidents worth taking seriously beyond their immediate blast radius. When the scanners and static-analysis tools teams rely on to vet their own supply chain can themselves be poisoned through a stolen publisher credential, point-in-time scanning stops being sufficient on its own. Docker’s bet, laid out across system packages, end-of-life support, customization, Helm charts, MCP servers, and machine-level policy, is that the fix is a foundation that is secure by default everywhere at once rather than a scanner bolted on at the end. Attacks on the software supply chain have kept escalating this year, from the credential-theft campaign against Trivy and KICS to the more recent ChainDrop worm that infected hundreds of npm packages without touching their visible source code, and defenders are increasingly being asked to assume that any single tool in the chain could be the next one compromised.