DEV Community: Docker

Docker Security Dispatch — Issue 4: Miasma, Phantom Gyp, and AI Routing 🪱️

Mohammad-Ali A'RÂBI — Wed, 01 Jul 2026 22:09:36 +0000

Welcome to the fourth issue of Docker Security Dispatch, written from the beautiful city of Bratislava, Slovakia.

June has proven that the security battleground has shifted from the production server to the developer's workstation, the CI/CD pipeline cache, and the AI agent's execution context. Supply chain worms are evolving to bypass the most trusted industry defenses, and new research has exposed critical flaws in the AI routing layer.

Key Takeaways

Miasma & Phantom Gyp: The latest wave of npm worms bypasses the --ignore-scripts defense using native binding.gyp command substitution.
Malicious AI Routers: Understanding the implications of the "Your Agent Is Mine" research, which reveals how third-party LLM APIs alter in-flight tool-calling requests.
Agentic Remediation: New insights on safely scaling agentic AI in production environments.
Upcoming Events & Releases: Details on my upcoming WeAreDevelopers World Congress sessions, a new talk at BaselOne, and a special comic book announcement.

🪱 The Evolution of Worms: Miasma and Phantom Gyp

If you need a refresher on worms, perhaps take a look at my talk notes from EnterJS 2026: Defense Against the Dark Arts: NPM Attack.

Just as the community began remediating the fallout from the TanStack CI cache poisoning, a highly sophisticated descendant emerged. In early June, the Miasma worm debuted a terrifying evasion technique dubbed "Phantom Gyp".

For years, the standard advice for preventing malicious package execution during installation has been to run npm install --ignore-scripts. Miasma renders this control entirely ineffective. The attackers embedded a tiny binding.gyp file inside the published tarballs. Because package managers must process native bindings via node-gyp before the C++ compiler is invoked, the malware uses command substitution to force the evaluation of an attacker-controlled shell payload during the configuration phase.

I've put together a comprehensive analysis of the recent worm campaigns tearing through the ecosystem. You can read my full breakdown of the 6 worms here: Beyond SLSA: The Worms Are Here.

Also, I gave Phantom Gyp a special treatment, "composing" music for it:

🤖 The AI Supply Chain & Production-Safe Remediation

This month, I'm also poking my finger into academic research. This section is about a research paper titled "Your Agent Is Mine: Measuring Malicious Intermediary Attacks on the LLM Supply Chain" by Hanzhi Liu et al. from UC Santa Barbara (Liu et quinque plures homines, as they say in Latin). The paper explores the security implications of using third-party LLM APIs in production environments.

LLM API routers are basically a part of the transport layer that sits between your code and the LLM. They are responsible for routing requests to the appropriate model, handling retries, and managing rate limits. However, these routers have plaintext access to in-flight JSON payloads, which means that, if compromised, they can silently rewrite an LLM's output. A benign installation URL generated by an LLM can be swapped for a malicious script, or an API key can be seamlessly exfiltrated.

To safely utilize these tools, we must rethink how we deploy them. I recently co-authored a deep dive on this exact topic that was featured on the main page of DZone! Check it out here: Building Production-Safe Agentic Remediation With Docker MCP Gateway: Lessons From 43% to 100% Accuracy.

🎙️ Recent Talks & Catch-Ups

If you missed my recent conference appearances, the write-ups and recordings are now available:

EnterJS 2026: Defense Against the Dark Arts: NPM Attack
JRush: I recently joined the JRush livestream for a great discussion on the current threat landscape. Watch the replay on YouTube here.

📅 Upcoming Events: Berlin & Basel

The conversation regarding advanced supply chain security will continue next month in Berlin at the WeAreDevelopers World Congress. I have a packed schedule, and I’d love to see you there:

July 8 (Pre-conference meetup): Agentic AI in the Wild: What Actually Runs in Production – I'm co-organizing this event alongside Dana Fine and Zaid Zaim. We have a fantastic lineup of speakers, including Ana-Maria Mihalceanu.
July 9 (Conference workshop): Dockerize Java Securely: SBOMs + Attestations + Bake, which is Docker Commandos v1.6.3.
July 10 (Conference talk): Beyond SBOMs: The Future of Container Supply Chain Security.

Looking further ahead: I am thrilled to announce that my talk has also been officially accepted at BaselOne! More details on the schedule for that will follow soon.

📚 Special Announcement: "Black Forest Commandos: Asgard Mission"

Finally, I am incredibly excited to announce that my comic book, "Black Forest Commandos: Asgard Mission," is officially coming out in September!

This comic tells the story of the 10 Docker Commandos workshop series. It chronicles the exact narrative and technical challenges as they happened live during the workshops at:

WeAreDevelopers Berlin 2026
JCON Europe 2026
Rabobank 2026

The comic will be available in both print and digital formats. Stay tuned for pre-order information later this summer!

Until then, keep your caches isolated, sandbox your AI agents, and verify your dependencies.

Supercharge Your AI Agent with Terraform: Introducing the Terraform Ops Kit for Docker Sandbox

Falcon — Tue, 23 Jun 2026 21:40:10 +0000

If you've ever wanted your AI coding agent to do more than just write code — to actually plan, validate, and cost-estimate real cloud infrastructure — the new Terraform Ops Kit for Docker Sandbox (sbx) is here to make that happen.

This community-contributed kit, submitted to the docker/sbx-kits-contrib repository, brings a production-ready Infrastructure-as-Code (IaC) toolkit straight into the sandbox environment where agents like Claude, Gemini, GitHub Copilot, and Shell already run.

What Is a Sandbox Kit?

Docker Sandbox (sbx) is a runtime environment where AI agents operate. Kits are modular add-ons that extend the capabilities of those agents — think of them as pre-configured toolboxes that get installed automatically when a sandbox is created.

The Terraform Ops Kit is a mixin kit, meaning it can be layered on top of any existing agent setup without replacing or conflicting with other kits.

What's Inside the Kit?

When the Terraform Ops Kit is activated, six tools are pre-installed and ready to use inside the sandbox:

Tool	Purpose
Terraform	Core IaC engine — plan, apply, and destroy infrastructure
Terragrunt	Terraform wrapper for DRY configurations and multi-account workflows
tflint	Linter for catching Terraform misconfigurations before they're applied
Checkov	Static analysis security scanner for IaC files
Infracost	Cost estimation — know the price tag before you deploy
AWS CLI	Interact with AWS services directly from the sandbox

Together, these tools enable AI agents to autonomously carry out the full infrastructure development lifecycle: write Terraform code, lint it, scan it for security issues, estimate its cost, and plan the deployment — all without leaving the sandbox.

Why This Matters

Infrastructure work has traditionally required a human-in-the-loop at every step. You'd write the config, then manually run terraform plan, then check the security scan, then get a cost estimate — context switching across multiple tools.

With the Terraform Ops Kit, an AI agent can now:

Autonomously validate Terraform code before it ever touches a real environment
Catch security misconfigurations with Checkov as part of the planning phase
Provide cost visibility with Infracost, so there are no billing surprises
Work with complex multi-environment setups via Terragrunt

This is a meaningful step toward AI-assisted infrastructure operations, where the agent isn't just a code suggester but an active participant in the IaC workflow.

Smart Engineering Choices Under the Hood

The kit author made several deliberate technical decisions worth highlighting, especially for developers reviewing or adapting the kit:

Pinned versions instead of "latest" — Both Terragrunt (v0.59.3) and Infracost (v0.10.31) are pinned to specific releases. This is because GitHub's API is rate-limited inside sandboxes (no auth token available), making automatic "latest version" detection unreliable. Pinning guarantees reproducible installs.

APT for Checkov instead of pip — On Ubuntu 24.04, running pip3 install checkov throws a PEP 668 error due to the externally-managed-environment policy. The kit installs Checkov via apt (python3-checkov), which sidesteps the conflict cleanly.

/etc/os-release over lsb_release — The shell-docker image doesn't ship lsb_release, so the kit reads the OS release file directly for Ubuntu version detection.

curl over wget — The shell-docker image includes curl but not wget. A small detail, but the kind that causes frustrating install failures if overlooked.

These choices reflect the kind of environment-aware engineering that makes the difference between a kit that works reliably in production and one that breaks on edge cases.

File Structure

The kit follows the standard sbx kit layout:

terraform-ops-kit/
├── spec.yaml    # Kit definition and install steps
└── README.md    # Usage documentation

Simple, focused, and easy to fork or adapt for your own toolchain.

Tested and Validated

The kit has been validated using the sbx CLI:

sbx kit validate — returns VALID
Sandbox created with sbx create --kit ./terraform-ops-kit/ shell /tmp/tf-test — all 6 tools installed successfully
All tools confirmed working via version checks: terraform, terragrunt, tflint, infracost, and aws-cli

Get Started

The Terraform Ops Kit is currently open for review as Pull Request #98 in the docker/sbx-kits-contrib repository. Once merged, you'll be able to use it like any other community kit.

If you're building AI-assisted DevOps workflows, working on cloud infrastructure automation, or just want your agent to have a stronger grasp of IaC tooling, this kit is worth a close look.

Contributed by @falconcr · docker/sbx-kits-contrib#98

Docker Security Dispatch — Issue 3: Zurich, Worms, and the AI Frontier 🏔️

Mohammad-Ali A'RÂBI — Mon, 22 Jun 2026 07:00:00 +0000

Welcome to the third issue of Docker Security Dispatch, written on the beautiful island of Mallorca. May was the month to conquer SBOMs and move beyond them. It was a rollercoaster of supply chain incidents, security research, and operational AI news.

We had a major supply chain cascade through TanStack and Nx Console, the long tail of Mini Shai-Hulud kept showing up in developer environments, Docker had to respond to a kernel-level container breakout class, and I brought the Commandos on stage at DevOpsDays Zurich.

Not a quiet month, then.

Key Takeaways

Recap of the Beyond SBOMs talk at DevOpsDays Zurich 2026.
What the TanStack and Nx Console compromises teach us about OIDC, provenance, CI caches, and developer workstations.
Why Mini Shai-Hulud's IDE and agent persistence is still the right warning sign for AI-assisted development.
A practical look at Copy Fail, Docker Engine mitigations, AI workloads, and the road to WeAreDevelopers Berlin.

🏔️ DevOpsDays Zurich: Beyond SBOMs

On May 6, I was at DevOpsDays Zurich 2026 with my talk: Beyond SBOMs: The Future of Container Supply Chain Security:

Beyond SBOMs: The Future of Container Supply Chain Security — Talk by Mohammad-Ali A'râbi - Docker and Kubernetes Security

When a single phished NPM maintainer led to 18 compromised libraries—including Chalk and Debug, downloaded billions of times weekly—it proved one thing: basic SBOMs alone aren't enough. But when the recent "Mini Shai Hulud" worm and its family of variants began silently tunneling through CI/CD pipelines to infect downstream containers, it proved our entire approach to build-time security needs a massive upgrade.

containersecurity.dev

The main point was simple: an SBOM is a receipt, not a shield.

I had a checklist at the end of the talk, which was photographed a few times, so here it is in text form:

Beyond SBOMs Checklist

1. Harden build. Implement SLSA level 3 to protect your builds and their credentials.
2. Pin your versions. Use pinned dependencies and pinned base images.
3. Cool down. Have a cool-down period before installing a newly published package or image.
4. Don't trust AI. Put your AI agent in a sandbox, e.g. Docker Sandboxes.
5. Short-lived keys. Use short-lived keys to limit the blast radius of a compromised credential.
6. Disable lifecycle scripts. By default, install dependencies with --ignore-scripts.
7. Have an incident playbook. Know how to respond when you find a malicious package or image in your supply chain.

If you want more context, some Swiss German, or perhaps a discount code, watch the full talk.

🧨 TanStack, Nx Console, and the Cache That Bit Back

The largest supply chain story of May was the chain from the TanStack npm compromise to the Nx Console compromise. Quick context if, like me, you don't spend every day inside the frontend tooling universe:

TanStack is the open-source project family behind popular JavaScript and TypeScript libraries like TanStack Query, Router, Table, and Start.
Nx Console is an IDE extension for Nx, a build system and monorepo tool used by many JavaScript and TypeScript teams.

The short version: attackers abused CI/CD trust boundaries, poisoned a package-manager cache, waited for a privileged release workflow, and ended up publishing malicious packages and extension releases. The uncomfortable part is that some of the malicious packages still looked like they came from a legitimate publishing path, because the attacker got hold of valid short-lived credentials during the build.

To learn more, read the postmortems:

Supply Chain Takeaways

Treat CI caches as executable trust boundaries. A poisoned cache can be as dangerous as a poisoned dependency.
Treat developer workstations and IDEs as part of the supply chain. They are not outside the blast radius anymore.

🪱 Mini Shai-Hulud: Still in the Walls

In Issue 2, I wrote about Mini Shai-Hulud, the NPM supply chain worm that arrived on my birthday. The worm even ended up in my Zurich talk's slides and raised some copyright concerns!

Context. Shai Hulud is the giant sandworm from the Dune universe. The phrase "shai hulud" can be read through Arabic as "شيء خلود" (shay' khulud), meaning "eternal thing". In my slides, a Persian poet is riding the worm, because Hafez was known as Lissan al-Gaib ("the tongue of the unseen") long before Paul Atreides took the name in Dune.

The real lesson was persistence in the developer inner loop.

Mini Shai-Hulud: The Next Evolution of NPM Supply Chain Worms - Docker and Kubernetes Security

A deep dive into the Mini Shai-Hulud attack, a sophisticated NPM worm that uses the Bun runtime to bypass security and targets developer agents for persistence.

containersecurity.dev

Mini Shai-Hulud abused the Bun runtime to step around Node-focused security tooling. More importantly, it planted hooks in places developers trust:

Places to Inspect

.vscode/tasks.json with "runOn": "folderOpen"
.claude/settings.json with SessionStart
package lifecycle scripts
workflow files and local helper scripts

That means removing node_modules is not enough. If the repository itself has been modified, the infection can come back when someone opens the folder or starts an AI coding session.

So the practical reminder for June:

rg -n "runOn|folderOpen|SessionStart|bun|curl|wget" .vscode .claude package.json .github

And for untrusted repositories or AI-agent work, keep using isolation. Docker Sandboxes are a very natural fit here because the agent can inspect, build, and run code without turning your host machine into the place where every experiment gets to execute freely.

sbx run claude

They say to kill the Shai-Hulud, put it in a box of sand and pour water on it. I still like that line.

Funny enough, I had already written about a small Shai Hulud before Mini Shai-Hulud was a thing. My JAVAPRO article "The Whispering JAR: Java Security Lessons Hidden in a Fantasy Tale" features a tiny Shai Hulud and covers mitigation practices that map surprisingly well to defending against Mini Shai-Hulud. I should probably start fortune-telling.

The Whispering JAR: Java Security Lessons Hidden in a Fantasy Tale - JAVAPRO International

javapro.io

The article is also featured in JAVAPRO's special edition. You can download the PDF edition from JAVAPRO here:

Always Up to Date - with Every New Free PDF Edition! - JAVAPRO International

javapro.io

🧱 Copy Fail and the Boring Beauty of Defense in Depth

May was not only about JavaScript packages and IDEs. The container runtime layer had its own moment with CVE-2026-31431, also called Copy Fail.

Here is the Python-developer version.

Linux has kernel features that user programs can call into, a little like importing a standard-library module. One of those features is AF_ALG, an interface that lets programs ask the kernel to do cryptographic operations. Think: "please encrypt this buffer for me."

Copy Fail was a bug in how the kernel handled one of those crypto operations when the input and output memory overlapped. If you have ever written Python like this:

buffer = bytearray(b"important data")
view = memoryview(buffer)

# Imagine a buggy low-level function reading and writing overlapping slices.
crypto_operation(input=view[0:8], output=view[4:12])

Then you already understand the shape of the problem: the code thinks it is copying or transforming bytes safely, but the read side and write side point into memory in a way the function did not handle correctly.

In the kernel, that kind of mistake is much more serious than a corrupted Python bytearray. The kernel manages shared caches and host resources. Under the wrong conditions, a low-privileged local attacker could use the bug to write where they should not be able to write. In container terms, that raises the scary question: can a process inside a container influence the host?

Docker published mitigations in Docker Engine, first tightening the default seccomp profile and then adding stronger AppArmor and SELinux coverage for the alg socket family.

AppArmor and SELinux are covered in my book Docker and Kubernetes Security. They are Linux Security Modules that let you write policies to restrict what a process can do.

The interesting part is not only the CVE. It is the mitigation story.

Container security works because layers overlap:

namespaces and cgroups reduce what a process can see and consume
seccomp filters dangerous syscall paths
AppArmor or SELinux adds policy at the Linux Security Module layer
minimal and hardened images reduce useful tools inside the container
runtime monitoring catches behavior that static scanning cannot

When one layer has a bad day, the others still matter. Your castle needs outer walls, inner walls, guards, and a moat. Check out the first chapter of Black Forest Shadow:

Defense in Depth - Docker and Kubernetes Security

In cybersecurity, defense in depth is a strategy that employs multiple layers of security controls throughout an IT system. This approach ensures that if one...

containersecurity.dev

By the way, Black Forest Shadow is available to read online for free now. You can still get the PDF in the shop or order the physical book on Amazon or from your local bookstore.

🤖 Operational AI with Docker

May also brought a happier topic: Operational AI with Docker is out. I wrote a short review about my experience as a technical reviewer and why the book is worth reading if you care about Docker, MCP, agents, and local AI workflows.

Book Review: Operational AI with Docker - Docker and Kubernetes Security

An exclusive behind-the-scenes look at the book 'Operational AI with Docker' by Ajeet Singh Raina and Harsh Manvar, including insights from my role as a technical reviewer.

containersecurity.dev

The security angle is simple: AI workloads bring more moving parts into the supply chain: model files, MCP servers, agent plugins, local tools, and permissions. The old question was "what is in my container?" The new question is closer to "what can this agent reach, execute, remember, and publish?"

📅 Next: EnterJS, Then WeAreDevelopers Berlin

June takes me to EnterJS in Mannheim with Defense Against the Dark Arts: NPM Attack, which now feels less like a clever title and more like a monthly incident response exercise.

Defense Against the Dark Arts: NPM Attack — Talk by Mohammad-Ali A'râbi - Docker and Kubernetes Security

A deep dive into the September 2025 NPM supply chain attack—one of the largest in history—and how to defend your enterprise JavaScript applications.

containersecurity.dev

Then in July, I will be back at WeAreDevelopers World Congress in Berlin with two talks:

Dockerize Java Securely: SBOMs + Attestations + Bake on July 9
Beyond SBOMs: The Future of Container Supply Chain Security on July 10

Last year at WeAreDevelopers, more than 100 people queued for 40 seats at my Docker workshop. This year, the Commandos return with a much darker threat model and a much better battle plan.

🏁 Final Thoughts

Look out for worms, check your caches, and keep building those walls. Also, have fun this summer!

Beyond SLSA: How to Stop Zero-Click CI/CD Worms with a 9-Step Plan

Mohammad-Ali A'RÂBI — Thu, 18 Jun 2026 10:19:19 +0000

The security perimeter of modern software development has officially collapsed. Historically, protecting your supply chain meant scanning static containers and blocking typosquatted packages. But between late 2025 and mid-2026, a terrifying paradigm shift occurred: adversaries abandoned passive repository poisoning to deploy autonomous, self-replicating worms directly into developer IDEs and CI/CD pipelines.

When developers are no longer just building software but are themselves the perimeter, tools like SLSA Level 3 and container vulnerability scanning are necessary prerequisites—but they remain blind to pre-build, pre-compilation threats. If a worm steals your credentials or compromises your pipeline cache before a container image is ever built, your final Software Bill of Materials (SBOM) will look perfectly fine while carrying authentic, cryptographically verified malicious payloads.

To bridge this structural gap, we introduce the IX Hexbreaker Aegis Framework—a 9-step active defense architecture designed to sanitize the local developer environment, lock down agentic AI, and stop autonomous worms dead in their tracks. For a formal mapping of these structural vulnerabilities across ecosystems, refer to the research article SoK: Weaponizing the Developer Context: A Taxonomy of Autonomous CI/CD Worms and Remediation Architectures (available on doi.org/10.5281/zenodo.20694817).

Chronology of Chaos: The 6 Modern Worm Campaigns

To understand why traditional perimeter security failed, we must look at the rapid evolutionary velocity of the six defining autonomous campaigns in the Shai-Hulud and Miasma lineages:

1. Shai-Hulud Wave 1 (September 2025)

The sandworm made it debut as the first self-propagating npm supply chain worm on record. Attackers gained initial maintainer access via phishing and credential stuffing. Once inside, the worm stole GitHub Personal Access Tokens (PATs) and cloud provider API keys from local developer environments, uploaded them to a public "dead-drop" repository, and autonomously used the stolen tokens to publish infected updates to every package that developer maintained.

2. Shai-Hulud 2.0 (November 2025)

The second wave scaled massively, compromising around 350 user accounts and spawning over 25,000 malicious repositories. Mechanically, this campaign shifted its execution trigger from postinstall to preinstall to maximize stealth. It also pioneered runtime evasion by dynamically downloading a standalone Bun binary to run its core obfuscated payload, completely dodging traditional security tooling looking only for Node.js child processes.

This was still the time that we could disable lifecycles scripts in package managers and install npm packages with --ignore-scripts to block the attack. As they say, it was the most wonderful time of the year—spoiler alert: it would not last.

3. Mini Shai-Hulud (April–May 2026)

Orchestrated by the threat group TeamPCP, this variant targeted the enterprise-grade SAP Cloud Application Programming (CAP) ecosystem. It introduced environmental gating (self-terminating if the system language was Russian) and achieved long-term IDE persistence by planting unauthorized startup hooks inside localized AI settings.

This was a turning point in the attack surface: the worm was no longer just targeting package manager lifecycles, but was instead weaponizing the very context in which code is written. That included the AI agents that developers rely on to write code in the first place. This was also a memorable time for me personally, as the worm was first observed on April 29, 2026—my 35th birthday. I guess the universe wanted to give me a "gift" that year (in its German sense)!

4. The TanStack Cache Poisoning Incident (May 11, 2026)

Assignee of CVE-2026-45321, this campaign proved that sophisticated worms no longer counterfeit trust signals; they commandeer pipelines to earn them. By chaining a pull_request_target misconfiguration with a GitHub Actions cache contamination vector, the worm poisoned a shared dependency store. When a highly privileged release workflow ran, it restored the poisoned cache, allowing the worm to scrape OIDC tokens straight out of the runner's worker process memory to sign and publish 84 malicious packages carrying authentic SLSA Level 3 provenance.

This was another major moment, as with this attack, SLSA Level 3 was officially rendered insufficient as a standalone defense. The attack also proved that even if your final SBOM looks clean, it can still be the product of a compromised build environment.

5. Miasma Wave 1: Red Hat npm Packages (June 1, 2026)

A direct descendant of Shai-Hulud, this worm compromised 32 official packages in the @redhat-cloud-services namespace. Attackers bypassed standard code review by committing malicious code via orphan commits. It featured per-infection payload encryption to blind hash-based detection and included a destructive dead-man's switch: if defenders revoked or touched the honeypot token, a background script immediately wiped the developer's home directory.

This means, the worm would take your entire development environment hostage, threatening to delete the "French language package" from your machine: sudo rm -fr ~.

6. Miasma Wave 2: The Phantom Gyp Exploit (June 3, 2026)

Two days later, Wave 2 compromised 57 packages in under two hours. This campaign introduced the "Phantom Gyp" technique, which completely neutralized the industry's standard defense of using the --ignore-scripts flag. Instead of relying on package.json scripts, it weaponized native binding.gyp command substitution, forcing the package manager to execute an arbitrary shell payload during the initial configuration phase before any C++ compiler was even called.

The 4 Overlooked Execution Surfaces

As mapped in the SoK paper, these six campaigns achieved rapid, zero-click propagation by targeting four distinct surfaces that fall entirely outside the scope of static scanners:

Zero-Click IDE Execution: Hidden workspace configurations (like .vscode/tasks.json) trigger malicious payloads the absolute millisecond an infected repository folder is opened in code editors like VS Code.
AI Context Window Poisoning: In advanced waves like the TrapDoor campaign, attackers plant instructions containing invisible zero-width Unicode characters inside files like .cursorrules or .claude/settings.json. These characters are completely invisible to human reviewers but command local AI agents to execute unauthorized scripts.
Pipeline Memory Scraping: Highly privileged Linux CI runners are targeted post-installation. Worms scan the /proc directory to scrape ambient OpenID Connect (OIDC) tokens and secret tokens straight out of active process memory, completely bypassing standard build-log secret masking.
Native Build Hijacking (Phantom Gyp): Attackers bypass the standard --ignore-scripts defense by appending a tiny, static binding.gyp file to the published package tarball to hijack native node-gyp execution.

The IX Hexbreaker Aegis Framework: A 9-Step Active Defense Plan

If you have an army of Shai Huluds and Miasmas marching toward your development environment, you need a cool name for your defense strategy: The IX Hexbreaker Aegis. The 9 is Roman, they're breaking the hex, and an aegis is a shield of protection. Nice, right?

The IX Hexbreaker Aegis architecture layers an active, pre-build defense boundary on top of traditional container hardening practices.

                          [ UNTRUSTED REPOSITORY ]
                                     │
           ┌─────────────────────────┴─────────────────────────┐
           ▼                                                   ▼
 ┌───────────────────┐                               ┌───────────────────┐
 │ Local Development │                               │   CI/CD Pipeline  │
 └─────────┬─────────┘                               └─────────┬─────────┘
           │                                                   │
           ├─► 1. AI Agent Sandboxing (Docker Sandboxes)       ├─► 4. OIDC Scope Minimization
           ├─► 2. Pre-Execution Workspace Parsing              ├─► 5. Immutable CI/CD Caching
           ├─► 3. Ephemeral, Air-Gapped Dev Environments       ├─► 7. Heuristic Build-Time eBPF
           ├─► 6. Hardware-Backed Commit Binding               ├─► 8. Egress Traffic Filtering
           └─► 9. Zero-Trust AI Prompts                        └─────────────────────────────────┘

1. AI Agent Sandboxing via Docker Sandboxes

Running localized AI coding assistants directly on a host machine exposes local credential stores to prompt injection. This step mandates wrapping AI agents inside isolated microVMs via Docker Sandboxes. Each session runs under its own kernel, filesystem, and network stack. Because API keys are never injected into the microVM's environment—and are instead handled by a host-side proxy at the network layer—a compromised AI agent cannot find any raw host credentials to steal.

2. Pre-Execution Workspace Parsing

Manual code reviews fail against steganographic payloads. Organizations must implement automated semantic scanning of all hidden AI configuration files (.cursorrules, .claude/settings.json, etc.) prior to context-loading. Utilizing LLM-based semantic judging helps identify hidden zero-width Unicode instructions and malicious execution trajectories before your primary development AI processes them.

3. Ephemeral, Air-Gapped Development Environments

Replace static, long-lived local development environments with remote, containerized alternatives like Dev Containers or GitHub Codespaces. These environments must enforce strict egress network filtering. By air-gapping the container and explicitly allowlisting only verified registries, a background worm's killchain is severed because it can neither download secondary runtimes nor reach out to an external command-and-control server.

4. Strict OIDC Scope Minimization

The TanStack cache poisoning incident proved that overly broad OIDC permissions allow background malware to hijack trusted publisher workflows. Ensure JSON Web Tokens (JWTs) are generated with the absolute minimum Time-to-Live (TTL) required for a specific job step, and bind them to restricted, precise audiences. Never expose token-writing privileges to general, multi-purpose pipeline jobs.

5. Immutable CI/CD Caching

Internal caching mechanisms often bypass repository workflow boundaries. Under this rule, caches generated by unvetted fork-context pull requests must be completely isolated from high-privilege release workflows. Cryptographic hash verification must be enforced on package manager caches to guarantee that a poisoned pull request cannot inject malicious binaries into a shared repository store.

6. Hardware-Backed Commit Binding

Worms rapidly spread sideways through development environments by stealing local SSH keys or Personal Access Tokens (PATs) to commit code autonomously. This step mandates that all commits and Git tags be cryptographically signed using FIDO2 hardware security keys (e.g., a YubiKey using an sk-ed25519 key format). Because the key requires a physical capacitive touch to sign, an automated background process is structurally blocked from making commits.

7. Heuristic Build-Time Anomaly Detection

Static image analysis cannot catch multi-stage, uniquely encrypted droppers executing in real time. Implement kernel-level observability using eBPF to trace process execution trees inside your build systems. The heuristic engine should immediately flag and quarantine anomalous subprocesses, such as an unprompted node-gyp rebuild on a package containing no legitimate native code.

8. Egress Traffic Filtering in CI Pipelines

CI/CD runners should never operate with unrestricted outbound network access. Enforce a default-deny network egress policy at the runner level during the test and build phases. Limiting outbound communication exclusively to vetted registries blocks a scraping worm from exfiltrating plaintext process memory dumps to external dead-drops.

9. Zero-Trust AI Prompts

Apply Role-Based Access Control (RBAC) directly to the execution profiles of AI coding agents. Rather than giving an LLM tool unfettered terminal access, drop permissions that allow an agent to run arbitrary shell scripts, read .env files, or modify system configurations without direct, human-in-the-loop Multi-Factor Authentication (MFA) approval.

Actionable Execution Blueprint

If you are defending an enterprise engineering organization, you can implement the IX Hexbreaker Aegis framework in three logical phases to minimize friction:

Phase 1: Immediate Lockdown (Days 1–5)

OIDC and Caching: Add permissions: {id-token: none} globally to every GitHub Actions workflow, granting write access only to specific publish steps. Separate cache keys immediately so fork PRs cannot contaminate your release scopes.

Dependency Cooldown: Configure Dependabot or Renovate to require a minimum package release age of 5 days before allowing an auto-merge, forcing malicious bursts to be caught by public threat intel beforehand.

AI Controls: Set project-level AI settings to deny shell execution without explicit confirmation.

Phase 2: Pipeline Hardening (Weeks 2–4)

Network Filters: Deploy default-deny egress firewalls (such as StepSecurity Harden-Runner) on your CI workflows to break potential C2 phone-home logic.

Pinning: Audit configuration repositories to substitute mutable action version tags with immutable, cryptographically secure commit SHAs.

Phase 3: Total Isolation (Month 2+)

Toolchain Sandboxing: Migrate development workspaces to containerized Dev Containers. Mandate the sbx CLI tool for all local engineer interaction with AI coding assistants to enforce hardware-isolated microVM containment.

Hardware Enforcement: Issue FIDO2 security tokens to all core package maintainers, configuring Git to refuse unauthenticated, unsigned commits locally and upstream.

Treating supply chain integrity as a static checkbox will guarantee that you fall victim to the next evolution of automated threats. Moving your active defenses entirely to the left—and protecting the very context in which code is written—is the only way to build software safely in an era of autonomous worms.

Docker Security Dispatch — Issue 2: From JCON to Zurich 🏔️

Mohammad-Ali A'RÂBI — Mon, 08 Jun 2026 11:43:36 +0000

Welcome to the second issue of Docker Security Dispatch. April was a whirlwind of conferences, articles, and interviews. From the cathedrals of Cologne to the mountains of Zurich, here is everything that happened in the Docker security world last month.

Key Takeaways

Stay informed about critical vulnerabilities like CVE-2026-34040 and the 'Mini Shai-Hulud' supply chain worm.
Discover the benefits of Docker Sandboxes for isolating development environments against malware.
Recap of the Java-focused Docker Commandos workshop delivered at JCON Europe 2026.
Insights from industry experts on container security and operationalizing AI with Docker.

🛡️ Critical: CVE-2026-34040 & The Mini Shai-Hulud "Gift"

The biggest news in the Docker security scene this month was the disclosure of CVE-2026-34040. This is a high-severity authorization bypass vulnerability that affected Docker Engine versions before 29.3.1. If an API request body exceeded 1MB, the AuthZ plugin would be bypassed. Please ensure you have updated to Docker Engine 29.4.2 or Docker Desktop 4.71.0.

Speaking of security "gifts," as I turned 35 on April 29, the universe (or TeamPCP) decided to send a satirical birthday present: Mini Shai-Hulud.

This third wave of the Shai-Hulud lineage emerged on my birthday and is a highly autonomous NPM supply chain worm. It heavily targeted the SAP cloud ecosystem (infecting @cap-js/sqlite and @cap-js/postgres), harvesting tokens to backdoor other packages. The attack uses a malicious preinstall hook to download the Bun runtime—bypassing Node-based security tooling—and execute an 11.7 MB obfuscated credential stealer. Most disturbingly, it installs persistence hooks directly in your IDE settings, specifically modifying .vscode/tasks.json to trigger on folderOpen.

Mini Shai-Hulud: The Next Evolution of NPM Supply Chain Worms - Docker and Kubernetes Security

A deep dive into the Mini Shai-Hulud attack, a sophisticated NPM worm that uses the Bun runtime to bypass security and targets developer agents for persistence.

containersecurity.dev

In better news, Docker Sandboxes (Beta) are helpful against Mini Shai-Hulud. They allow you to run your AI coding agents like Claude in an isolated microVM, preventing Mini Shai-Hulud-style attacks from compromising your development environment:

sbx run claude

🏛️ JCON Europe: The Commandos in Cologne

On April 20, I was at JCON Europe 2026 in Cologne, and delivered the "Java Supply Chain Security with Docker" workshop—a Java-focused adaptation of the Docker Commandos series.

The workshop is available as a Docker Labspace, providing a guided, interactive environment.

If you don't have the Labspace extension installed in Docker Desktop, you can still run the full mission locally using the OCI artifact:

docker compose -f oci://docker.io/aerabi/docker-commandos-labspace up -d

Learn more:

Java Supply Chain Security with Docker — Docker Commandos Workshop - Docker and Kubernetes Security

Docker Commandos adapted for a Java audience at JCON Europe 2026. Supply chain security, SBOMs, and attestations — using Docker tooling with a Java project as the target.

containersecurity.dev

🎙️ Interview with Baruch Sadogursky

While at JCON, I sat down with the legendary Baruch Sadogursky (@jbaruch) for an interview with Tessl and JAVAPRO.

We discussed, surprise surprise, container supply chain security.

📰 JAVAPRO: "The Whispering JAR"

Speaking of JAVAPRO, my latest article for them also dropped during the conference: "The Whispering JAR: Java Security Lessons Hidden in a Fantasy Tale".

It's a narrative-driven look at the latest supply chain attacks hidden in a fantasy setting—similar in spirit to Black Forest Shadow, and happening right after the events of the book. It discusses the following attacks:

NPM supply chain attack of September 2025
The Shai-Hulud 1 and 2 attacks of late 2025
React2Shell, the React-based remote code execution attack of late 2025

The Whispering JAR: Java Security Lessons Hidden in a Fantasy Tale - JAVAPRO International

javapro.io

🐧 Foojay.io Debut

I am also thrilled to have published my first article on Foojay.io (the Friends of OpenJDK platform) this month: "Dockerizing a Java 26 Project with Docker Init".

Dockerizing a Java 26 Project with Docker Init

Java 26 came out in March 2026. This article walks you through Dockerizing a Java 26 Spring Boot project using Docker Init.

foojay.io

🎙️ JobRad Podcast: Writing a Tech Book

JobRad's tech podcast, Increase Cycle Time, is out, and I'm on it! 🎙️

I sat down with Holger Grosse-Plankermann and Urs Lange to talk about the behind-the-scenes of writing a tech book like Docker and Kubernetes Security. We discussed the research process, the challenges of keeping up with a fast-moving ecosystem, and what it takes to get from a rough draft to a published book.

Folge 10: Writing a tech book - Increase Cycle Time - Der JobRad® Development Podcast

Hello lovely people from the interwebs, In this episode we have a chat with our dear colleague Mohammad-Ali A'râbi. Mo wrote a book about Docker Security. Even though the content of this book is great. (Hint! Read the book: https://www.dockersecurity.io/), in this episode Urs and Holger are more interested in what it is like to write a book? Why do this after all? What are the hurdles? How do you keep your motivation high? And what one needs to do, if you are thinking: I want to write a book too! All this and more in the current episode of Increase Cycle Time.

jobrad-increase-cycle-time.podigee.io

🤖 Book: Operational AI with Docker

I'm excited to announce that I served as a technical reviewer for the new book "Operational AI with Docker", published by Packt. As AI models become a standard part of our containerized workloads, this book is a fantastic guide for anyone looking to run LLMs in production using Docker.

🏔️ Upcoming: DevOpsDays Zurich & Berlin

Recently, I headed to DevOpsDays Zurich (May the 6th) to give my talk: "Beyond SBOMs: The Future of Container Supply Chain Security". I'll write more about it in the coming issue.

I'm also happy to share that this talk was also accepted for WeAreDevelopers World Congress in Berlin this July. I can't wait to bring the Commandos to the big stage in Berlin! So, if you missed it in Zurich, we'll catch you in Berlin!

Until next time, and let's hope there are no more "gifts" from the universe in May!

Docker Security Dispatch — Issue 1: Docker Turns 13 🎂

Mohammad-Ali A'RÂBI — Tue, 02 Jun 2026 07:32:00 +0000

Welcome to the first issue of Docker Security Dispatch. This newsletter covers Docker security, container supply chains, and the community around them. The first issue of the newsletter was published on April 1st, 2026, on the following platforms:

I'm bringing the series to DEV.to as well, so I'm sharing the first issue with 2 months of delay.

Key Takeaways

Celebrate Docker's 13th anniversary with the launch of the dark fantasy security guide, 'Black Forest Shadow'.
Get insights from the Docker Commandos v1.5 workshop focused on supply-chain security.
Learn about the '10 Docker Commandos' framework for hunting security threats.
Recap the most significant Docker book releases from the first quarter of 2026.

🎂 Docker Turns 13

Docker turned 13 on March 20, 2026. Thirteen years since Solomon Hykes demoed docker run at PyCon.

I published my second book on Friday, March 13th—Docker's birthday, and a Friday the 13th. I couldn't resist.

Black Forest Shadow — A Dark Fantasy Guide to Docker and Kubernetes Security

A dark fantasy novel set in the Black Forest of 1865 that teaches Docker and Kubernetes security through narrative — covering CVE hunting, SBOM generation, runtime hardening, and container security.

containersecurity.dev

Black Forest Shadow: A Dark Fantasy Guide to Docker and Kubernetes Security grew out of the Advent of Docker Security series I published in December 2025—24 daily posts set in the Black Forest of 1865, where shadow creatures called CVEs were spreading through villages. After the series ended, I wrote seven more chapters, compiled the whole thing, and turned it into a book.

Each chapter maps to a real security technique: CVE triage, SBOM generation, OCI 1.1 attestations, vulnerability scanning, container hardening, runtime security with Falco, lateral movement prevention. Gord, Rothütle, Jack, and Evie are also the Docker Commandos from the workshop series. The book is their origin story.

Where to get it:

DockerSecurity.io — PDF, ePub, and print
Amazon
Thalia and Hugendubel for DACH print

🎖️ Docker Commandos at Rabobank

On March 27, I delivered Docker Commandos v1.5 at Rabobank in Utrecht, as part of their Docker Champions program. About 20 people attended.

Docker Commandos is a workshop where 10 fictional commandos, each paired with a Docker security command, guide participants through a mission to defend Asgard from CVE monsters. v1.5 covers the full supply-chain pipeline: from docker init to cryptographic image signing with Cosign and zero-day runtime defense. Two new commandos join in this version.

The full workshop materials:

Docker Commandos v1.5 — Docker Commandos Workshop - Docker and Kubernetes Security

Docker Commandos v1.5 at Rabobank, part of their Docker Champions program. Full supply-chain security pipeline from Docker Init to cryptographic signing and zero-day runtime defense.

containersecurity.dev

📰 JavaPro: "10 Docker Commandos"

On March 19, JavaPro published my article "10 Docker Commandos: Docker Commands to Hunt the Predator"—three days before I ran the workshop at Rabobank, which was good timing.

The article uses the React2Shell supply chain attack (CVE-2025-55182) as the threat model. Attackers deployed crypto miners within hours of disclosure. The 10 commandos walk through the response: Lockdown → SBOM → Scout → SBOM Attestations → Docker Init → Hardened Images → Exempted CVEs → VEX Attestation → Docker Bake → Zero-Day Defense.

10 Docker Commandos: Docker Commands to Hunt the Predator - JAVAPRO International

javapro.io

📚 Q1 2026 Docker Books

Five Docker books came out in the first quarter of 2026. Three of them by Docker Captains, which I think is a first.

The Complete Docker Read List: Q1 2026 Edition - Docker and Kubernetes Security

A curated reading list of the best books on Docker and Kubernetes for the first quarter of 2026, featuring releases from Docker Captains and industry experts.

containersecurity.dev

📅 Next: JCON Europe, Cologne, April 20

On April 20, I had the honor of doing a workshop at JCON Europe 2026 in Cologne with "Java Supply Chain Security with Docker"—Docker Commandos adapted for a Java audience. Same pipeline, Java project as the target.

Java Supply Chain Security with Docker — Docker Commandos Workshop - Docker and Kubernetes Security

Docker Commandos adapted for a Java audience at JCON Europe 2026. Supply chain security, SBOMs, and attestations — using Docker tooling with a Java project as the target.

containersecurity.dev

Questions or feedback: dockersecurity.io/contact.

Seven Docker Tips Every Engineer Should Know (from Docker Captains)

Mohammad-Ali A'RÂBI — Mon, 25 May 2026 07:25:00 +0000

Between June and August 2025, Docker shared a short series of practical tips from Docker Captains on Twitter/X. The format was brief, but the advice is worth unpacking. This post is revisiting those seven tips with a little more context and newer examples.

Here are the seven tips, in the chronological order they were shared!

1. Start New Projects with Docker Init

Captain intro: Mohammad-Ali A'rabi is a Docker Captain from Freiburg, Germany, a backend software engineer, Docker community leader, and the author of Docker and Kubernetes Security. His work often sits at the intersection of practical engineering, education, community, and secure-by-default container workflows.

// Detect dark theme var iframe = document.getElementById('tweet-1934618217990754462-547'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1934618217990754462&theme=dark" }

The tweet points to docker init as the fastest way to get a clean Docker setup for a new project:

docker init

The command analyzes your project and generates a set of files that follow Docker's best practices:

Dockerfile
.dockerignore
compose.yaml
README.Docker.md

Read the following article for a detailed walkthrough of docker init with a Java project: Dockerize Java 26 with Docker Init.

2. Clean Up Docker Disk Usage Carefully

Captain intro: Rafael Pazini is a Docker Captain from Sao Paulo, Brazil, and a Senior Software Engineer at Pluto TV. He has more than 10 years of experience building scalable applications, with expertise in distributed systems, microservices, Docker, and Kubernetes.

// Detect dark theme var iframe = document.getElementById('tweet-1937229925515252098-27'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1937229925515252098&theme=dark" }

The command docker system prune is no stranger to Docker users:

docker system prune -a --volumes

The terminal will say:

WARNING! This will remove:
  - all stopped containers
  - all networks not used by at least one container
  - all dangling images
  - unused build cache

Are you sure you want to continue? [y/N]

BTW, did you know [y/N] means "default to No if the user just presses Enter"?

The -a flag removes all unused images, not just dangling ones. The --volumes flag adds unused volumes to the cleanup list. Check it out, and the warning verifies it:

WARNING! This will remove:
  - all stopped containers
  - all networks not used by at least one container
  - all anonymous volumes not used by at least one container
  - all images without at least one container associated to them
  - all build cache

Are you sure you want to continue? [y/N]

A few more handy commands:

docker rmi -f $(docker images -q)  # Force-remove all images
docker volume rm $(docker volume ls -q)  # Remove all volumes

Satisfaction!

3. Use Multi-Stage Builds

Captain intro: Karan Verma is a Docker Captain from Jalandhar, India. He is a software engineer and community leader who has been active in the Docker community in Jalandhar since 2017, with a focus that includes AI and MLOps.

// Detect dark theme var iframe = document.getElementById('tweet-1939768473887916538-62'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1939768473887916538&theme=dark" }

It's not only AI images that can get big. It's better to trim images down, AI or not. It's cost-effective, faster to deploy, and more secure by reducing the attack surface. Multi-stage builds are the way to go for that.

To add to that, docker init already generates a multi-stage Dockerfile for you.

Also, make sure the final stage is hardened with a non-root user and limited privileges. For example, use a base image with no package manager, no shell, and no extra tools.

Another important tip is to generate SBOM attestations during the build:

docker build --sbom=true -t my-image:latest .

This command doesn't automatically include all stages in the SBOM, so you need to add the following line to each stage in your Dockerfile to ensure they are included:

ARG BUILDKIT_SBOM_SCAN_CONTEXT=true
FROM <image> AS stage

4. Choose Lightweight, Version-Pinned Base Images

Captain intro: Sergio Lopes is a Docker Captain from Sao Paulo, Brazil, and a Principal Backend Engineer at Banco Itau Unibanco S.A. Docker highlights his long backend engineering background and expertise in developer productivity, Kubernetes, modern application development, and observability.

// Detect dark theme var iframe = document.getElementById('tweet-1944758785475498198-694'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1944758785475498198&theme=dark" }

This tweet is from July 2025, but the advice is evergreen. Use Docker Hardened Images (DHI) for base images, and pin to a specific version. The DHI are:

Lightweight
Open-source
Secure-by-default

Check the catalog at dhi.io and pick the right image for your language and use case. Search for "node", get into the Node.js image catalog:

Then go to the "Images" tab to see the full list:

In the list of images:

If there is a lock, it's not free to use. Just skip it.
There are Debian and Alpine variants.
There are "dev" variants with build tools and "prod" variants without them.

Find a version, and your Dockerfile should start like this:

# The build stage
FROM dhi.io/node:26.2.0-debian13-dev AS build

# The production stage
FROM dhi.io/node:26.2.0-debian13

The dev image has 10 CVEs and the prod image has 0.

5. Use Docker Scout Quickview

Captain intro: Khushboo Verma is a Docker Captain and Platform Engineer at Appwrite in Bengaluru, India. She is also a community builder and speaker, with Docker listing her expertise in developer productivity, modern application development, and observability.

// Detect dark theme var iframe = document.getElementById('tweet-1947370272115290448-318'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1947370272115290448&theme=dark" }

The docker scout quickview command is a fast way to get a snapshot of your image's security posture. It checks for known CVEs, lists dependencies, and provides metadata about the base image. This is especially useful in CI pipelines to catch vulnerabilities before pushing images to a registry.

Let's do it on the DHI Node.js image:

docker scout quickview dhi.io/node:26.2.0-debian13

The output says:

    i New version 1.21.0 available (installed version is 1.20.3) at https://github.com/docker/scout-cli
    ✓ SBOM obtained from attestation, 20 packages found
    ✓ Provenance obtained from attestation
    ✓ VEX statements obtained from attestation

    i Base image was auto-detected. To get more accurate results, build images with max-mode provenance attestations.
      Review docs.docker.com ↗ for more information.

 Target   │  dhi.io/node:26.2.0-debian13  │    0C     0H     0M     0L
   digest │  f3fb2a06abd6                 │

So, there are no CVEs, and the image has:

SBOM attestation with 20 packages
Provenance attestation
VEX statements attestation

If you want to learn more about these concepts, check out the Docker Commandos workshop on Docker Labspaces: Docker Commandos.

6. Use .dockerignore

Captain intro: Anjan Kumar Reddy Ayyadapu is a Docker Captain and Senior Architect Solution Leader at Cloudera Inc. Docker lists his expertise across AI/ML, CI/CD, Kubernetes, observability, developer productivity, and software secure supply chain work.

// Detect dark theme var iframe = document.getElementById('tweet-1950295464433025395-539'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1950295464433025395&theme=dark" }

The tweet compares .dockerignore to .gitignore, which is exactly the right mental model. .gitignore decides what should not enter version control; .dockerignore decides what should not enter the Docker build context.

Two points on that!

When doing a docker build command, it usually looks like this:

docker build -t my-image:latest .

The . at the end is not the Dockerfile path; it's the build context path. It means, "send the current directory and all its contents to the Docker daemon for the build".

Anjan says blacklist some files with .dockerignore, I would say whitelist some files with .dockerignore. Start with a clean slate, and add only what you need. For example:

# .dockerignore
*

!src/
!package.json
!package-lock.json

7. Limit Container Privileges

Captain intro: Mohammad-Ali A'rabi appears again in Docker's series, this time with a security tip. It's not me promoting myself, it's Docker!

// Detect dark theme var iframe = document.getElementById('tweet-1953561787623788652-733'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1953561787623788652&theme=dark" }

Just for context: Linux capabilities are granular permissions that can be independently enabled or disabled for processes. Similar to the whitelisting approach of .dockerignore, you can start with a clean slate by dropping all capabilities and then adding only the ones your application needs. For example:

docker run --cap-drop=ALL --cap-add=NET_ADMIN my-image:latest

It's similar in a Kubernetes pod spec:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
    - name: my-container
      image: my-image:latest
      securityContext:
        capabilities:
          drop: ["ALL"]
          add: ["NET_ADMIN"]

To learn more about Linux capabilities and how to use them in Docker and Kubernetes, check out the book Docker and Kubernetes Security.

Conclusion

I wish Docker starts sharing more tips from Docker Captains, and I hope this post helps expand on the original tweets with more context and examples. If you have any questions or want to share your own Docker tips, feel free to reach out on LinkedIn or Twitter/X.

Happy Dockerizing!

Book Review: Operational AI with Docker

Mohammad-Ali A'RÂBI — Wed, 20 May 2026 07:32:00 +0000

In my Q1 2026 Docker Read List, I dropped a little hint that I was involved in reviewing an exciting upcoming book for Q2. Well, the secret is finally out! I had the absolute honor of being a technical reviewer for Operational AI with Docker, written by my friends and fellow experts Ajeet Singh Raina and Harsh Manvar.

The Complete Docker Read List: Q1 2026 Edition - Docker and Kubernetes Security - Docker and Kubernetes Security

A curated reading list of the best books on Docker and Kubernetes for the first quarter of 2026, featuring releases from Docker Captains and industry experts.

dockersecurity.io

I love a good narrative in my technical books. The authors definitely brought some drama to the text, which I absolutely loved about this book. I had the chance to review the last four chapters of the book, and would love to share some exclusive behind-the-scenes insights about the book, as well as my thoughts on it.

Authors

Well, the authors need no introduction, but I'll still give you one.

Ajeet Singh Raina was a Docker Captain for six years until he was hired by Docker as a Developer Advocate. He was my first point of contact when I started my journey in the Docker community, and we published three blog posts together on the Docker blog. He is an absolute legend, the man behind the Collabnix Community, and a great mentor to many in the container ecosystem.

Harsh Manvar is a Senior Software Engineer at Oracle, a Docker Captain, and a CNCF Ambassador. Similarly, he is also an absolute star in the Indian container ecosystem, and has been a great mentor to many in the community. I had the pleasure of meeting him in person at the Docker Captains Summit in 2025, when he shared with me his plans for the book, and I was immediately excited about it.

The Book's Final Act: From MCP to KAgent

Chapter 6. The authors introduced the Docker MCP Gateway flawlessly. Before getting into the details, they did a great job of setting the stage by showing exactly why we need a gateway, and why it is painful to connect different MCP servers directly. It's great that the authors let you feel the pain, instead of just telling you about it.
Chapters 7 and 8. These chapters dive heavily into using AI agents and orchestrating multiple AI agents using Python. The chapters are packed with multiple examples and Docker Compose projects. The chapters might feel a bit overwhelming or tedious for readers, but it perfectly shows how one can use AI agents in a real-world scenario, and create a complex system that can solve a problem end-to-end. These two chapters are practically every Hollywood movie 70 minutes in, when it feels we're at impossible odds, and there is no way out.
Chapter 9. The grand finale covers Docker Sandboxes, Docker Agent, and KAgent. Let me tell you, this is an awesome way to end the book. It suddenly becomes clear that any pain we had to endure in Chapter 8 was entirely intentional: it was just to make the out-of-the-box experience of Docker Agent and KAgent shine! Suddenly eagles come and Frodo is on his way to Valinor!

Final Thoughts

The book is purely practical, impossibly fresh, and skillfully dramatic. It teaches you the basics and the advanced features of Docker MCP, Docker Agent, and KAgent. It lets you feel the pain and the joy of better tools. It is a must-read for anyone interested in the future of AI and how it can be operationalized using Docker. It's a great read, sometimes a bit overwhelming, but always rewarding. You need it in your library, and you need to read it.

Generating SBOM with Docker Scout

Mohammad-Ali A'RÂBI — Thu, 23 Apr 2026 18:40:34 +0000

Knowing what's inside your container is the first step to securing it. In the first commando mission, we dockerized a Java 26 project using Docker Init. Now that we have an image, it's time to see what's actually in it.

The Mission: Who Lives in Asgard?

Rothütle, the tactician of the Docker Commandos, asks Thor for a list of all Asgard residents. Why? Because you can't defend a city if you don't know who's inside. By getting this list, you can later cross-reference it with known threats and identify the shadows in disguise.

Technical Requirements

Docker Desktop that is not too old, or
Docker Scout CLI plugin installed.

To make sure you have the Docker Scout plugin, run:

docker scout --help

Generate the SBOM

We'll use docker scout sbom to peek inside our image. If you followed the previous post, you have an image built from your project. Let's assume you tagged it hello-wowlrd:latest.

docker scout sbom hello-wowlrd:latest --format list

The --format list flag gives you a clean table of all the packages, their versions, and types (e.g., deb, maven).

Exporting to Standard Formats

While a table is great for humans, tools prefer standard formats like SPDX or CycloneDX. Let's export our SBOM to a JSON file using the SPDX format:

docker scout sbom hello-wowlrd:latest --format spdx --output sbom.spdx.json

If you investigate the file, you will see a detailed inventory:

jq . sbom.spdx.json | less

This file contains every package, its version, and its license—perfect for compliance and automated scanning. You can check available formats by running docker scout sbom --help. Try exporting in CycloneDX format and compare it with the SPDX output!

Exercise: Comparing Base Images

One of the best ways to understand the value of an SBOM is to compare different base images. For example, let's look at the difference between a standard Node.js image and its Alpine counterpart:

docker scout sbom node:25 --format list

Versus:

docker scout sbom node:25-alpine --format list

You'll notice that the Alpine version is significantly smaller, with fewer packages. This is why "minimal base images" are a core tenet of container security—fewer residents mean fewer places for CVE monsters to hide.

What's Next?

Now that we have our list of residents, the next mission is to find the monsters. In the next post, we'll use Docker Scout to scan for CVEs.

Want the full mission? Visit Docker Commandos or request a workshop.

Dockerizing a Java 26 Project with Docker Init

Mohammad-Ali A'RÂBI — Tue, 31 Mar 2026 13:56:57 +0000

Docker Init was introduced in Docker Desktop 4.27, before LLMs became the default answer to everything. It's a "smart" interactive wizard that analyzes your project and generates:

A Dockerfile (multi-stage, production-ready)
A compose.yaml file
A .dockerignore file
A README.Docker.md with build and run instructions

What makes it valuable is that it's deterministic—not a probabilistic guess. It produces the same correct output every time, following Docker's own best practices.

Technical Requirements

Docker Desktop 4.27 or later

Create a New Project

I'm using a Spring Boot project. Because it's early Spring now and I haven't touched one in a while—so let's go.

Head to start.spring.io and create a project with:

Project: Maven
Language: Java
Spring Boot: 4.0.5 (or whatever the latest stable is)
Packaging: Jar
Java: 26

I used these coordinates, but pick your own:

Group: io.dockersecurity
Artifact: hello-wowlrd
Package Name: io.dockersecurity.hello-wowlrd

Download, unzip, and step into the directory:

cd hello-wowlrd

Run Docker Init

As my British friend say, "It's Docker, innit?"

docker init

The interactive wizard detects your Java project automatically. Accept "Java", confirm the source directory and Java version, and enter the port:

? What application platform does your project use? Java
? What's the relative directory (with a leading .) for your app? ./src
? What version of Java do you want to use? 26
? What port does your server listen on? 8080

Docker Init generates four files. The one that matters most is the Dockerfile:

# syntax=docker/dockerfile:1

################################################################################
# Stage 1: resolve and download dependencies
FROM eclipse-temurin:26-jdk-jammy as deps

WORKDIR /build

COPY --chmod=0755 mvnw mvnw
COPY .mvn/ .mvn/

RUN --mount=type=bind,source=pom.xml,target=pom.xml \
    --mount=type=cache,target=/root/.m2 ./mvnw dependency:go-offline -DskipTests

################################################################################
# Stage 2: build the application
FROM deps as package

WORKDIR /build

COPY ./src src/
RUN --mount=type=bind,source=pom.xml,target=pom.xml \
    --mount=type=cache,target=/root/.m2 \
    ./mvnw package -DskipTests && \
    mv target/$(./mvnw help:evaluate -Dexpression=project.artifactId -q -DforceStdout)-$(./mvnw help:evaluate -Dexpression=project.version -q -DforceStdout).jar target/app.jar

################################################################################
# Stage 3: extract Spring Boot layers
FROM package as extract

WORKDIR /build

RUN java -Djarmode=layertools -jar target/app.jar extract --destination target/extracted

################################################################################
# Stage 4: minimal runtime image
FROM eclipse-temurin:26-jre-jammy AS final

ARG UID=10001
RUN adduser \
    --disabled-password \
    --gecos "" \
    --home "/nonexistent" \
    --shell "/sbin/nologin" \
    --no-create-home \
    --uid "${UID}" \
    appuser
USER appuser

COPY --from=extract build/target/extracted/dependencies/ ./
COPY --from=extract build/target/extracted/spring-boot-loader/ ./
COPY --from=extract build/target/extracted/snapshot-dependencies/ ./
COPY --from=extract build/target/extracted/application/ ./

EXPOSE 8080

ENTRYPOINT [ "java", "org.springframework.boot.loader.launch.JarLauncher" ]

This is already a proper multi-stage build: separate stages for dependency resolution, compilation, layer extraction, and a minimal runtime image with a non-root user. Gord would approve.

A Note on Java 26 Base Images

The generated Dockerfile references eclipse-temurin:26-jdk-jammy and eclipse-temurin:26-jre-jammy. Since Java 26 was just released, these Eclipse Temurin images may not be fully available on Docker Hub yet.

Swap them out for SAP Machine images instead—SAP's free OpenJDK distribution ships Java 26 on Ubuntu 24.04 (Noble Numbat):

sapmachine:26-jdk-ubuntu-noble
sapmachine:26-jre-ubuntu-noble

Find them on Docker Hub: hub.docker.com/_/sapmachine. Just replace eclipse-temurin with sapmachine in both FROM lines.

Build and Run

docker compose up --build

The generated compose.yaml is minimal:

services:
  server:
    build:
      context: .
    ports:
      - 8080:8080

The application starts, and immediately stops with exit code 0. That's expected: there's no HTTP endpoint to keep it alive.

Add a Controller

Create src/main/java/io/dockersecurity/hellowowlrd/HelloController.java:

package io.dockersecurity.hellowowlrd;

import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class HelloController {

    @GetMapping("/")
    public String hello() {
        return "Hello, Docker Security!";
    }
}

Add the Spring Web dependency to pom.xml:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>

Build and run again:

docker compose up --build

Verify:

curl http://localhost:8080
# Hello, Docker Security!

See It Live — Jfokus 2026

I presented Docker Init and Docker security at Jfokus in Stockholm in February 2026. If you want to see the commands in action rather than reading about them, the full talk is on YouTube:

Conclusion

Java 26 just shipped and Docker Init handles it cleanly out of the box—multi-stage build, layer extraction, non-root user, bind mounts for caching. You get a production-ready Dockerfile in under a minute. When Eclipse Temurin catches up, swap the base images back. Until then, SAP Machine has you covered.

Docker Init is Gord's move. The rest of the Commandos handle what comes after.

The Docker Commandos

Docker Init is assigned to Commando 1: Gord. In the Docker Commandos workshop, each Docker security feature is taught through a character on a mission to defend Asgard from CVE monsters. The ten commandos are:

Gord — docker init: establish a secure base from day one ← you are here
Rothütle — SBOM: inventory every dependency in your image
Jack — Docker Scout: hunt CVEs across your supply chain
The Valkyrie — SBOM Attestations: cryptographically sign your component inventory
Artemisia — Docker Hardened Images: near-zero-CVE base images
Mina — VEX Exemptions: mark false-positive CVEs as not exploitable
RuinTan — VEX Attestations: attach signed exemptions to your image
Captain Ahab — Docker Bake: codify your entire build pipeline in one file
Evie — Cosign: sign images and attestations cryptographically
Agent Null — Zero-Day Defense: harden against unknown, unpatched threats

The workshop has been delivered at WeAreDevelopers World Congress, Jfokus, and Rabobank. More at dockersecurity.io/commandos.

The Complete Docker Read List: Q1 2026 Edition

Mohammad-Ali A'RÂBI — Thu, 26 Mar 2026 17:21:39 +0000

2026 has been phenomenal in the number of books published on Docker or by Docker Captains so far. So, I decided to compile the books published in the first quarter of 2026 into an article for more people to discover them.

You can also read the article here, which looks slightly better.

1️⃣ Black Forest Shadow: A Dark Fantasy Guide to Docker and Kubernetes Security

Author: Mohammad-Ali A'râbi (Docker Captain)

If you've ever thought learning about Kubernetes and container hardening was a bit dry, Mohammad-Ali A'râbi is here to prove you wrong. Black Forest Shadow is a highly creative, dark fantasy guide to Docker and Kubernetes security.

—Claude

What it's about: The book weaves complex concepts like runtime security, SBOM generation, and container hardening into an exciting narrative set in the mystical Black Forest of 1865.
Why you should read it: It transforms standard cybersecurity challenges—like tracking down CVEs and preventing lateral movement—into an immersive, story-driven adventure. It's ideal for developers and security engineers seeking a distinctive, memorable approach to DevSecOps.
Where to get it:

2️⃣ The Rust Programming Handbook: An End-to-end Guide to Mastering Rust Fundamentals

Author: Francesco Ciulla (Docker Captain)

Rust is the new C, and it's been on my list for 5 years now. Now, finally, I know which book to read to learn it. Written by my dear friend and fellow Docker Captain, Francesco Ciulla, who has been teaching Rust for many years now.

What it's about: This handbook takes you from foundational syntax to advanced features like memory safety and concurrency models. Crucially for this list, it includes dedicated, hands-on sections on Dockerizing and deploying your Rust applications!
Why you should read it: It bridges the gap between beginner tutorials and production-ready coding for low-level system components or high-performance web services.
Where to get it:
- Packt Publishing
- Walmart

3️⃣ Docker for Front-end Developers (Featuring React.js)

Author: Kristiyan Velkov (Docker Captain)

Front-end developers, rejoice! As a backend engineer, it has always been hard for me to onboard frontend people to Docker, because I spoke Klingon for them. My dear friend, Docker Captain Kristiyan Velkov, has done an awesome job writing a containerization guide specifically tailored to how front-end engineers think, build, and ship. I should say, it also looks good.

What it's about: Moving past backend-centric explanations, this book walks you through containerizing real-world applications (with a heavy focus on React). You'll learn how to write clean Dockerfiles, configure NGINX properly, implement multi-stage builds, and handle caching securely.
Why you should read it: It's a purely practical, visually-driven guide that teaches you how to take full ownership of your environments without getting bogged down in abstract backend theory.
Where to get it:

4️⃣ The Ultimate Docker Container Book (Fourth Edition)

Author: Dr. Gabriel N. Schenker

Hitting shelves on March 31, 2026, this absolute heavyweight of a book clocks in at over 750 pages and leaves no stone unturned. Jeez, I need an extra bookshelf just for this book's weight.

What it's about: It takes you from basic container concepts all the way to running production-grade platforms. The fourth edition places a massive new emphasis on security, enterprise governance, compliance, and AI-driven automation patterns.
Why you should read it: It is designed for system administrators, DevOps engineers, and architects who need to build and scale secure, future-ready container platforms across major cloud providers.
Where to get it:
- Packt Publishing

5️⃣ Docker: Das Praxisbuch für Entwickler und DevOps-Teams (5th Edition)

Authors: Bernd Öggl & Michael Kofler

For the German-speaking tech community, the definitive Docker reference guide gets a major Q1 2026 update.

What it's about: A comprehensive, 580+ page practical guide covering everything from setting up Docker to CI/CD pipelines, GitLab integration, Swarm, and Kubernetes orchestration.
Why you should read it: It's an excellent, hands-on resource that balances basic principles with advanced, modern use cases like modernizing legacy applications and working with specialized databases.
Where to get it:
- Rheinwerk Verlag

Honorable Mentions from 2025

Well, while researching the new 2026 Docker books, I stumbled upon a recent video by Bret Fisher interviewing the author of a rather interesting book. That inspired me to add this honorable mentions section. I promise my original intention wasn't to sneak my own book in here, but hey, it just happened!

Learn Docker in a Month of Lunches (Second Edition)

Author: Elton Stoneman

Published in 2025, this is the much-anticipated update to one of the most beloved Docker books on the market.

What it's about: A complete refresh of the classic guide. It breaks down Docker fundamentals into digestible, daily lessons. This edition covers multi-platform builds, the latest cloud container services, and navigating the modern Kubernetes ecosystem.
Why you should read it: If you are a beginner looking for a structured, manageable way to learn—or an experienced dev needing to catch up on years of ecosystem changes—this is the gold standard.
Where to get it:
- Manning Publications

Getting Started with Docker (2025 Edition)

Author: Nigel Poulton (Docker Captain)

Nigel Poulton's fast-paced introduction to Docker received a significant 2025 update, adding a dedicated chapter on running local LLMs with Docker Model Runner — including building a multi-container chatbot app.

What it's about: A streamlined, hands-on guide to container fundamentals, Docker Compose, and microservices — now with a practical AI chapter for developers who want to run models locally.
Why you should read it: It's the quickest path from zero to productive with Docker, and the new AI content makes it uniquely relevant for 2025 and beyond.
Where to get it:
- Leanpub

Docker and Kubernetes Security

Author: Mohammad-Ali A'râbi (Docker Captain)

A DevOps Dozen 2025 finalist for Best DevOps Book of the Year, this practical guide covers container security across the full development lifecycle—from build to production.

What it's about: Ten chapters spanning supply chain security (SBOMs, OCI 1.1 attestations, vulnerability scanning with Docker Scout, Trivy, and Snyk) and runtime protection with Falco, RBAC, and Kubernetes pod security.
Why you should read it: It is the most comprehensive hands-on resource available for teams serious about securing their container platforms end-to-end.
Where to get it:
- DockerSecurity.io
- Amazon

Conclusion

The Docker and Kubernetes ecosystem has never had a stronger reading list, to be completely humble! From dark fantasy security guides to hands-on Rust handbooks and front-end containerization primers, Q1 2026 proves that the community is producing more creative, accessible, and production-focused material than ever before.

Stay tuned as more books are coming in Q2. I'm involved in reviewing one of them, so I'm excited for the quarter to come.

Have a book that should be on this list? Leave a comment.

Docker Just Made Hardened Images Free for Everyone – Let's Check Them Out!

Anil Kumar Moka — Mon, 29 Dec 2025 02:03:18 +0000

Hey everyone! If you're like me and spend a lot of time building and deploying containers, you've probably worried about security at some point. Supply chain attacks are no joke these days, and starting with a solid, secure base can make a huge difference. That's why I'm super excited about the recent news from Docker: they've made Docker Hardened Images (DHI) completely free and open source for all developers!Back in May 2025, Docker launched these hardened images as a way to give us minimal, secure, production-ready bases. And just a couple weeks ago (December 17, 2025), they announced that the whole catalog – over 1,000 images and Helm charts – is now free, under Apache 2.0. No subscriptions needed for the basics, no restrictions, no gotchas. This feels like a game-changer for making secure containers the default instead of an afterthought.Let me break it down for you based on the official blog post and docs, and share some practical ways you can start using them today.

What Are Docker Hardened Images?

In simple terms, DHI are container images that Docker maintains with security front and center. They're built on familiar bases like Alpine and Debian, but stripped down to the essentials. No unnecessary shells, compilers, or package managers that could open up attack vectors.The result?
Images up to 95% smaller

Way fewer CVEs (they aim for near-zero)
Secure defaults, like running as non-root
Full transparency with SBOMs (software bill of materials),
SLSA Level 3 provenance, and no hidden vulnerabilities

They're inspired by distroless ideas but keep enough tools so you don't have to fight with them in real workflows. And unlike some proprietary options, these are open, compatible with what you're already using, and easy to adopt.

There's a free tier for everyone, and an Enterprise version if you need extras like FIPS compliance, customizations, or super-fast patching SLAs.

Why This Matters (And Why Now)

Supply chain attacks are exploding – projected to cost $60 billion this year alone. A lot of that risk comes from bloated base images pulling in stuff your app doesn't need. By starting with a hardened image, you're shrinking that attack surface right from the first docker build.Docker's basically saying: let's make secure-by-default the new normal. And with partnerships from folks like Google, MongoDB, and CNCF, plus companies like Adobe and Qualcomm already using them, it seems like it's catching on fast.

How to Get Started – It's Super Easy

Head over to the catalog on Docker Hub: https://hub.docker.com/hardened-images/catalog (you might need to sign in with your Docker ID).Or pull directly from dhi.io.

For example, let's try a Python one:bash

docker pull dhi.io/python:3.13
Then run something simple:bash

docker run --rm dhi.io/python:3.13 python -c "print('Hello from a hardened image!')"

In your Dockerfile, just swap the base:

FROM dhi.io/python:3.13 COPY . /app WORKDIR /app CMD ["python", "app.py"]

They work great in CI/CD too. And if you're on Kubernetes, check out the open source Hardened Helm Charts.
Pro tip from the docs: These images are minimal on purpose, so no shell by default in runtime variants. Use multi-stage builds – compile in a -dev or -sdk tag, then copy to the slim runtime one.

Some Practical Use Cases I Can See

Imagine you're building a Node.js API for a startup. Instead of starting with the regular node image (which has extra stuff), switch to a hardened one. Smaller images mean faster deploys, fewer vulnerabilities to scan, and you sleep better knowing it's locked down.

Or say you're deploying MongoDB in prod. Docker has hardened versions of popular MCP servers like Mongo, Grafana, and more. Drop one in, and you've got a secure foundation without rolling your own hardening scripts.

For teams in regulated spaces (finance, healthcare), the free versions already give huge wins on CVEs and size. Upgrade to Enterprise if you need FIPS or extended support after upstream EOL.Even for personal projects or learning, why not start secure? It costs nothing extra now.

This move by Docker feels huge, putting hardened, transparent images in everyone's hands for free. If you've been putting off tightening up your container security, now's the perfect time to jump in. Go browse the catalog, pull a couple images, and see the difference yourself. Planning to switch any of your projects over? Drop a comment if you've tried them already!