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

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.

---

🏔️ 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

Delivered at DevOpsDays Zurich 2026.

dockersecurity.io

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:

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:

• TanStack npm supply-chain compromise postmortem
• Nx Console v18.95.0 supply-chain compromise postmortem
• Microsoft's write-up on malicious npm packages and dependency confusion

My takeaway is simple:

---

🪱 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

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.

dockersecurity.io

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

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

A fantasy-style Java security article with supply chain lessons that aged suspiciously well.

javapro.io

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

JAVAPRO Special Edition PDF

Download the free JAVAPRO PDF edition featuring The Whispering JAR.

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:

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:

Black Forest Shadow: Chapter 1: Defense in Depth

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

dockersecurity.io

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

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.

dockersecurity.io

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

EnterJS Mannheim, June 2026.

dockersecurity.io

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!