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:

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:

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

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 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 article is also featured in JAVAPRO's special edition. You can download the PDF edition from JAVAPRO here:

🧱 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:

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.

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.

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!