DEV Community: Docker

How to Secure Java Docker Images and Reduce CVE Risk

Mohammad-Ali A'RÂBI — Tue, 13 Oct 2026 22:40:21 +0000

The Black Forest Commandos' field guide to CVEs, SBOMs, hardened images, attestations, and software supply chain security.

Your Java application can inherit vulnerable dependencies and packages from your base image before you write a single line of application code. Also, scanning your Docker image for vulnerabilities has blind spots, as the SBOM generated after the fact does not give you the full picture. A successful Docker build alone does not tell you what is shipped, how it was built, or whether you can trust it.

Asgard is under attack. Shadow creatures called CVEs have infiltrated the realm, and Thor's hammer is proving surprisingly ineffective. Odin has only one option: summon the Black Forest Commandos.

Behind the mythology is a practical question: How do we build container images that we can inspect, trust, and deploy with confidence?

Let's secure a Spring Boot sample project together, and with the help of the Commandos (CLI commands).

TL;DR

Most of the CVEs come from base images. Just swapping the baseline base image for a Docker hardened base image reduces the runtime inventory—the packages an attacker could actually reach—by 75.5%, with no application dependency changes between the two images.

Fewer number of packages, means less attack surface. Docker Hardened Images are also shipped with near-zero CVEs, non-root user, and no shell or package manager for the production images. So, even if an attacker gets inside your container, they won't have much to play with.

All these considered, swapping your base images won't make your application CVEs go away. That's why you should read the full article!

Start with the Ready-to-Run Sample

Before we start, let's check your toolset:

Checklist

Install Git to clone the sample repository.
Install and start Docker with Buildx. Check that docker info and docker buildx version work.
If not on Docker Desktop, install Docker Scout CLI separately. Check docker scout version.
Install Trivy and check trivy --version. The recorded run used 0.75.0.
Install Cosign and check cosign version. The recorded run used 3.1.3.
Have Bash, curl, and Python 3 available for the demo scripts.
Sign in to Docker Hub with docker login for Scout CVE queries.
Sign in to Docker Hardened Images with docker login dhi.io.

Docker builds, compiles, and tests the application, so you can follow this walkthrough without installing Java or Maven locally. Use a Bash-like terminal for the commands below.

Check Out the Tested Starting Point

The reference repository has two branches:

main, which is the state you will reach at the end of the article.
start, is the beginning of the journey.

We will start from there:

git clone --branch start --single-branch \
  https://github.com/ContainerSecurity-dev/dockerize-java-securely.git
cd dockerize-java-securely

You can edit and commit your experiments on this local branch. Base-image tags and vulnerability databases can still change, so your scan results may differ.

The files you'll use are:

src/ and pom.xml: the working application and its HTTP integration test.
Dockerfile.baseline: the starting image, using the official Maven and Eclipse Temurin images.
Dockerfile: the hardened version you'll compare against it.
scripts/: helpers to check the HTTP response and save vulnerability reports.

So, let it rip.

1. Build a Baseline You Can Inspect

The Commandos survey the ground before they fight. For us, that ground is a baseline image, built and pushed so it can be inspected.

We use a temporary, loopback-only registry so the audience can practice pushes and attestations without publishing application images to a public registry. This unauthenticated HTTP registry is for local demos only. For a remote registry, use an authenticated namespace you own over HTTPS.

docker run -d --name dockerize-java-demo-registry \
  -p 127.0.0.1:15000:5000 registry:3
export PLATFORM=linux/amd64   # use linux/arm64 on Apple Silicon
export IMAGE_REPO=127.0.0.1:15000/dockerize-java-securely
mkdir -p results

docker buildx build --platform "$PLATFORM" \
  -f Dockerfile.baseline \
  --sbom=true --provenance=mode=max \
  --metadata-file results/baseline-build-metadata.json \
  --push -t "$IMAGE_REPO:baseline" .

scripts/smoke-test.sh "$IMAGE_REPO:baseline"
export IMAGE="$IMAGE_REPO:baseline"

Let's unpack the commands:

The docker buildx build command is an extended command for building Docker images using BuildKit.
The flag --sbom=true instructs the builder to generate SBOM attestations: SBOM records "attached" to the image.
The flag --provenance=mode=max is used to generate provenance attestations. This attestation records more metadata about the build process.
As you can see, -f Dockerfile.baseline is used to specify the Dockerfile. So, the only non-optional argument, being the . at the end, is not actually the path to the Dockerfile, it's rather the build context, which is all the files that Docker can access and can potentionally end up in your Docker image.

View book

Also, if you inspect the smoke-test.sh file, it's running the image with the following flags:

docker run --detach --rm --read-only --tmpfs /tmp --cap-drop ALL \
  --security-opt no-new-privileges:true -p 127.0.0.1::8080 "$image"

The smoke test should return Hello, Docker Security! as user 10001:10001. The flags are used to run the container in a safer environment.

2. Know Your Enemy: CVEs and SBOMs

Log4Shell (CVE-2021-44228) demonstrated why knowing which dependencies we ship matters. An SBOM, or Software Bill of Materials, is a list of software components in your application. Having this list handy helps you identify your packages in case there is a known exploit in one of them. Having it does not make your application safer by itself.

Rothütle's first mission in Asgard is to discover who lives there. Using Docker Scout, you can check the list using docker scout sbom command:

docker scout sbom "$IMAGE" --format list
docker scout sbom "$IMAGE" --format spdx --output results/sbom.spdx.json

How many packages are listed here?

Output of those commands will mention the SBOM attestation being used. If the attestation is absent from the build, Docker Scout will try to build it by scanning your files.

In the docker buildx build command we ran, we have created an SBOM attestation, and the Docker Scout command picked it up. But, the SBOM only contains packages from the final stage, which is not a full picture. A compromised build-time package can still write a backdoor into your application.

Further reading:

generating-an-sbom-with-docker-scout

3. Hunt the CVEs: Docker Scout and Trivy

Jack, our cybernetic scout, now dressing as Jack-o'-Lantern for Halloween, can detect CVEs hiding inside container images.

docker scout cves "$IMAGE"
docker scout cves --only-severity critical,high "$IMAGE"

Docker Scout is an enterprise offering, free for personal use. Trivy is an open-source alternative and similarly an industry standard.

trivy image --scanners vuln "$IMAGE"
trivy image --scanners vuln --severity CRITICAL,HIGH --exit-code 1 "$IMAGE"

The final command should return exit code 1, because there are high and/or critical CVEs in the image. That is a security gate you should add to your workflow.
Let's save machine-readable reports with the repository's helper:

# Saves JSON, summarizes findings, and exits 1 if the gate fails.
scripts/scan.sh "$IMAGE" results/baseline-trivy.json

The scan.sh script runs Trivy under the hood, but also stores the reports and parses them. A similar script would be in your pipeline, e.g., to report the number of CVEs via a pull request comment.

Note that, severity is not the same as exploitability, and malicious software does not necessarily have a CVE. Scanner databases and package matching also differ: the same baseline yielded different totals in Scout and Trivy. Compare images within the same scanner and inspect the affected packages.

4. Include the Build Stage in Your SBOM

Rothütle suspects the inventory is incomplete: some components were present while the application was built, not only while it runs.

The baseline uses a multi-stage build, but --sbom=true alone inventories the final image. Packages used only while compiling the application can disappear from that inventory when the build stage is discarded.

First inspect the baseline's attached SBOM and provenance:

docker buildx imagetools inspect "$IMAGE_REPO:baseline" --format '{{json .SBOM}}' > results/baseline-sbom.json
docker buildx imagetools inspect "$IMAGE_REPO:baseline" --format '{{json .Provenance}}' > results/baseline-provenance.json

Now edit Dockerfile.baseline. Add this argument immediately after the build stage's FROM line:

FROM maven:3.9-eclipse-temurin-21 AS build
ARG BUILDKIT_SBOM_SCAN_STAGE=true

Rebuild under a separate tag so you can compare the two inventories:

docker buildx build --platform "$PLATFORM" \
  -f Dockerfile.baseline \
  --sbom=true --provenance=mode=max \
  --metadata-file results/baseline-build-sbom-metadata.json \
  --push -t "$IMAGE_REPO:baseline-build-sbom" .

docker buildx imagetools inspect "$IMAGE_REPO:baseline-build-sbom" --format '{{json .SBOM}}' > results/baseline-with-build-sbom.json

The new output includes an additional sbom-build document alongside the runtime SPDX inventory. The argument adds metadata about the packages from earlier stages, and it doesn't mean those packages end up in the final image.

SBOM: What software was inventoried in the image and covered build stages?
Provenance: How was the image built, and from which materials?

Use BuildKit secret mounts for credentials. Maximum-level provenance can expose build arguments, so never put secrets in them. Furthermore, an attached attestation is not automatically a trusted cryptographic signature.

Now, how many packages are listed in the SBOM attestations?

Further reading:

the-poisoned-macchiato

5. Harden the Runtime and Measure the Difference

Armor time. Docker Hardened Images are a set of open-source and near-zero-CVE base images, designed to "armor" your Docker image against future attacks. You can check their catalog on dhi.io.

Let's swap the base image for the hardened ones:

# syntax=docker/dockerfile:1
FROM dhi.io/maven:3-jdk21-dev AS build
ARG BUILDKIT_SBOM_SCAN_STAGE=true
WORKDIR /app
COPY pom.xml .
COPY src ./src
RUN mvn -B verify

FROM dhi.io/eclipse-temurin:21-alpine3.23
WORKDIR /app
COPY --from=build /app/target/app.jar /app/app.jar
USER 10001:10001
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "/app/app.jar"]

If you check the sample repo, there is a file .dockerignore there with the following content:

**
!pom.xml
!src/
!src/**
!Dockerfile
!Dockerfile.baseline

This means, everything is ignored by the docker buildx build command (removed from the build context), except for the listed files. This is called an allowlist. So, instead of ignoring a bunch of files, we ignore everything, and allow a bunch of files.

Also, the POM sets finalName to app, avoiding an ambiguous JAR wildcard.

This follows Docker's Java DHI migration pattern, with explicit tests and a non-root runtime user.

docker buildx build --platform "$PLATFORM" \
  --sbom=true --provenance=mode=max \
  --metadata-file results/hardened-build-metadata.json \
  --push -t "$IMAGE_REPO:hardened" .

scripts/smoke-test.sh "$IMAGE_REPO:hardened"
# Also returns 1 for the recorded sample:
scripts/scan.sh "$IMAGE_REPO:hardened" results/hardened-trivy.json
python3 scripts/summarize-scans.py results/baseline-trivy.json results/hardened-trivy.json

It's report time! You can run all of them yourself, or just read through mine!

Observed results: 13 October 2026

Both final application images use Spring Boot 4.0.8 and Java 21. The results are based on runs on Linux Ubuntu (linux/amd64) and Mac Silicon (linux/arm64), yielding identical results. These are Trivy 0.75.0 vulnerability records, grouped by scan target; totals are not counts of unique CVE IDs across all packages.

Scan target	Baseline: `eclipse-temurin:21-jre`	Hardened: `dhi.io/eclipse-temurin:21-alpine3.23`
OS packages	0 critical, 0 high, 40 medium, 4 low	No findings
Java dependencies	3 critical, 5 high, 2 medium	3 critical, 5 high, 2 medium
Other detected binary (`pebble`)	3 high, 5 medium, 1 low, 4 unknown	Not present as a scan target

Docker Scout 1.20.3 reported 5 critical / 13 high / 2 medium / 3 unspecified for the baseline and 3 critical / 5 high / 2 medium for the hardened image. Those are separate scanner observations, not interchangeable with the Trivy counts.

The original Spring Boot 4.0.5 sample had 9 critical / 18 high / 20 medium / 6 low Java findings in Trivy. Updating to 4.0.8 reduced those findings, but did not eliminate them. The remaining Java findings implicated Tomcat and Jackson dependencies. Review the report's fixed-version guidance, update the application dependencies, rerun tests, and rescan before promotion.

Inspect the Blast Radius in Your Dependency Tree

"Update Tomcat and Jackson" is easier said than done, because most of these libraries arrive transitively through the Spring Boot BOM. Inspect what your project actually resolves before you touch a version:

# Full resolved tree (run inside the builder image if you have no local JDK):
./mvnw -B dependency:tree

# Narrow it to the packages the scanner flagged:
./mvnw -B dependency:tree -Dincludes=org.apache.tomcat.embed:tomcat-embed-core
./mvnw -B dependency:tree -Dincludes=tools.jackson.core:jackson-core

I can't believe it's 2026 and Maven flags still look like that. Dincludes. Anyway!

The tree shows each artifact's depth and the path that pulled it in. A dependency you declare directly in pom.xml can be overridden there or in a <dependencyManagement> entry; a transitive one usually needs a version override or an updated parent/BOM. After the change, confirm the fix reaches the runtime JAR, rerun mvn verify, and rescan the new digest. If an affected artifact is transitive and has no fix yet, record that in a VEX statement instead of silently suppressing it.

Check VEX Before Comparing Scanners

VEX (Vulnerability Exploitability eXchange) records whether a particular vulnerability affects a product. One can create VEX records for CVEs that are harmless in their case. One can ship them with their Docker image as "VEX attestations". Docker Hardened Image come with their own VEX attestations.

Docker Scout automatically applies DHI VEX statements and excludes them from the listed CVEs; Trivy needs VEX enabled:

docker scout cves dhi.io/eclipse-temurin:8-alpine3.23

# Configure and download the DHI VEX repository first (see linked instructions).
trivy image --scanners vuln --vex repo dhi.io/eclipse-temurin:8-alpine3.23

For Trivy, enable the docker-hardened-images/advisories repository in its VEX configuration and download it before using --vex repo. Review applicable VEX statements; suppression is an assessment of affectedness, not a dependency fix.

This can sometimes explain differences in reported CVEs without any change to the image. See Docker’s VEX-aware scanning instructions.

The recorded Trivy scans above did not enable VEX. However, the observed difference between Scout and Trivy was in the non-DHI baseline, so it was not coming from VEX attestations.

Both images passed the HTTP smoke test. In the recorded comparison, with build-stage scanning enabled, the runtime SBOM contained 192 packages for the baseline and 47 for the hardened image; the separate build-stage inventories contained 396 and 377, respectively. Hence, just by swapping for a DHI base image, the number of dependencies in the production image is reduced by 75%. Hence the Artemisia bar chart image, as she's squashing the attack surface!

The results report records image digests, versions, and evidence.

docker-hardened-images-are-free

6. Sign Before You Trust: Cosign

Evie is the Commando responsible for cryptographic signatures. She always uses the immutable digest returned by the build, rather than a mutable tag:

export DIGEST_IMAGE="$IMAGE_REPO@$(python3 -c 'import json; print(json.load(open("results/hardened-build-metadata.json"))["containerimage.digest"])')"
mkdir -p .demo-keys
cosign generate-key-pair --output-key-prefix .demo-keys/cosign
cosign sign --key .demo-keys/cosign.key "$DIGEST_IMAGE"
cosign verify --key .demo-keys/cosign.pub "$DIGEST_IMAGE"

# Scan the same immutable artifact; this sample still fails the gate.
trivy image --scanners vuln --severity CRITICAL,HIGH --exit-code 1 "$DIGEST_IMAGE"

Cosign 3.1.3 successfully verifies the signature, claims, and transparency-log inclusion. The vulnerability gate still returns 1. A signed image can contain known vulnerabilities.

Keep the private key out of Git; the sample ignores .demo-keys/ and *.key. Enter a key password interactively and use a disposable key for rehearsal. Default signing publishes signature metadata and the public key to a transparency log. Production verification needs a trusted signing policy, not an arbitrary public key supplied alongside an image.

We sign the image to make sure no one altered it on the way to production. But, the attackers are getting smarter. Read the Shai Hulud family account to learn about the incident that a signed image was altered by the attacker:

taxonomy-of-modern-supply-chain-worms

7. SIP It Before You Ship It

The Shai-Hulud family illustrates why scanning a final image is not enough: malicious packages can target developers and CI before an image exists. AI coding agents are another environment with access to code, tools, and potentially credentials.

SIP: Security Immediate Plan ties the controls together:

Sandbox agents. Isolate execution and restrict credentials, network access, and mounted directories.
Lock down dependencies. Manage Maven dependency and plugin versions, inspect the resolved tree, and review updates. Gradle and npm projects need their own locking and install policies; this Maven sample does not exercise those tools.
Harden builds. Keep compilers and build tools in the build stage, and run the final image without root privileges.
Attest. Generate SBOM and provenance, including relevant build stages.
Scan before promotion. Scan the exact digest, enforce your vulnerability policy, and verify trusted signatures before deployment.

Sandbox → Lock → Harden → Attest → Scan. No single scanner, image, or signature secures the entire supply chain. For agent isolation and ecosystem-specific dependency controls, see the full SIP implementation.

This walkthrough demonstrates three of those controls end to end on a real Java image: Harden (a DHI runtime running as a non-root user), Attest (SBOM and provenance, including the build stage), and Scan (gating the exact digest before promotion). It touches Lock only partially, through the Maven dependency tree and version discipline shown above; full dependency locking for Gradle and npm projects is outside this sample. Sandbox agents—isolating AI coding agents and restricting their credentials, network access, and mounts—is not exercised here at all, so treat it as an additional SIP control rather than something this experiment proved.

Conclusion

Three findings came out of this run, and they map directly onto the Commando team:

Key takeaways

Hardened base images reduce OS-level exposure. The DHI runtime dropped from 192 inventoried packages to 47 (75.5%) and removed all 44 Ubuntu package findings and the pebble binary target, without changing any application dependency.
SBOM attestations improve visibility. --sbom=true --provenance=mode=max attaches what shipped and how it was built, and BUILDKIT_SBOM_SCAN_STAGE=true extends the inventory to the build stage.
Application dependency remediation remains essential. Tomcat and Jackson kept the same 3 critical and 5 high findings in both images, so hardening and signing never replaced updating libraries.

Hardening the base image and signing the result are necessary, not sufficient. The Commandos' armor kept out the creatures that came with the base image; the ones hiding inside Tomcat and Jackson are a different fight, and it is fought at the dependency level. Fix what you ship, prove how you built it, and scan the exact digest before it reaches production.

Keep Learning: Articles and Tutorials

Generating SBOM with Docker Scout — inspect and export software inventories.
The Poisoned Macchiato — Java SBOM attestations, Cosign, and OCI artifacts.
Docker Hardened Images are Free — hardened base images and vulnerability comparisons.
The Shai-Hulud Family — taxonomy of modern supply chain worms.
Docker Sandbox Kits: A Hands-On Tutorial — agent isolation and capability controls.
Black Forest Commandos: Asgard Mission DIY — a longer, hands-on version of the Commandos' mission.

Official Documentation

Meet the Black Forest Commandos in My Books

Docker and Kubernetes Security. To learn about Linux capabilities (the ones that we dropped here), or secure CI workflows, check this book.
Black Forest Shadow. The origin story of Gord, Rothütle, Evie, and the CVE monsters, set in the Black Forest in 1865.
Black Forest Commandos: Asgard Mission. The graphic novel behind the Commandos' adventure in Asgard. The story expands the mythology used in my talks and workshops. Do you want to know the ending? Spoiler alert!

SIP it before you ship it.

Mohammad-Ali A'râbi — Docker Captain, author, and creator of the Black Forest Commandos.

Results are a dated snapshot from the linked sample. Review versions, permissions, and security policies and rerun the checks before production use.

Docker Security Dispatch — Issue 7: Authority as Code and Zombie Actions 🧟

Mohammad-Ali A'RÂBI — Mon, 12 Oct 2026 17:34:48 +0000

The worm was dead. Or so we thought.

In May, GitHub disabled two malicious Actions compromised by Mini Shai-Hulud. In September, they came back from the dead. No new exploit. No new malicious release. Just the same poisoned code, waiting to run again.

Meanwhile, Docker introduced a new way to package AI agents together with the permissions they request. Apparently, we are giving our agents permission slips now.

Welcome to Docker Security Dispatch 7, reviewing September 2026. This month: Docker Sandbox Kits, zombie GitHub Actions, security policies for container images, and a worm hiding inside your favorite VS Code theme.

Plus, my adventures at the Docker Captains Summit in Cancún! 🐳🇲🇽

Key takeaways

Docker Sandbox Kits (Specification v3) package software and its requested permissions into a single, pinnable OCI image.
Two GitHub Actions compromised by Mini Shai-Hulud in May were re-enabled in September with their malicious tags still intact; one alone had roughly 15,000 dependent repositories, potentially exposed.
Docker publishes the Rego policies behind Docker Hardened Images, so you can evaluate your own images with docker scout policy.
GitHub Actions cache-mode reached general availability, letting you restrict cache read/write access per workflow or job.
A GlassWorm-linked cluster of malicious VS Code and Open VSX theme extensions shows that even a color theme can execute code.

🤖 Docker Sandbox Kits: Authority as Code

At the Docker Captains Summit, I spent some time learning about Docker's new direction: sbx, Sandboxes, and Kits.

AI agents are basically overprivileged potential attackers. As they develop our code, they need access to Docker and other services, and putting them in a Docker container is not enough: privileged Docker in Docker weakens the isolation between the container and the host, and mounting the host's Docker socket is worse. That hands the container direct control over the host's Docker daemon. Security risks around both are covered in Chapter 5, "Docker-in-Docker," of Docker and Kubernetes Security.

That's why Docker introduced Sandboxes: a microVM-based isolation environment for running untrusted workloads, and by untrusted workloads, I mean AI agents.

But the agents still need to access external services, some directories on the host, and some credentials. How do we define what they can access?

Enter Docker Sandbox Kits.

On September 24, Docker published the open-source Sandbox Kit Specification v3.¹

Here's what a Kit descriptor looks like in practice: part of the gh mixin, which gives an agent the GitHub CLI.

# gh.yaml — part of the GitHub CLI mixin's descriptor
capabilities:
  - type: com.docker.sandbox/network-policy@2
    config:
      runtime:
        allow:
          - github.com
          - hosts: [api.github.com]
            methods: [GET, HEAD, POST, PATCH, PUT, DELETE]
        deny:
          - hosts: [api.github.com]
            methods: [DELETE]
            paths: [/repos/**]

  - type: com.docker.sandbox/credential@1
    optional: true
    config:
      service: github
      phase: runtime
      apiKey:
        name: GH_TOKEN
        proxyManaged: true
        inject:
          - { domain: api.github.com, header: Authorization, format: 'Bearer %s' }

It reads like a Dockerfile, except it declares requested authority instead of software: the Kit requests access to GitHub, but asks for DELETE requests under /repos/** to be denied, and asks to never see the real GH_TOKEN.

A Kit is an ordinary OCI image: the layers are its content, and the descriptor above becomes a single manifest annotation. That's why you can build, scan, sign, and digest-pin a Kit with tooling you already run.

If you want to try this yourself, e.g., running a sandbox, composing a published Kit, then building this exact mixin from source, I wrote a step-by-step tutorial with a companion repository:

docker-sandbox-kits-tutorial

There are two kinds of Kits:

Workload: The base software that runs inside the sandbox, such as a coding agent.
Mixin: An overlay like the one above — credentials, network rules, or tools layered onto a workload.

A runtime can compose one workload with multiple mixins.

What Does That Mean for Security?

The gh Kit above requests access to GitHub only, requests that DELETE requests under /repos/** be denied, and requests that the agent never hold the real GH_TOKEN: the proxy injects it into authorized requests instead. Useful capabilities, without unrestricted access.

But those are requests, not guarantees. The Kit does not enforce anything by itself. The OCI annotation is metadata; a conforming runtime must enforce, reject, or skip those requests according to the specification. Docker Sandboxes is the first such runtime, and Docker is taking the specification toward CNCF governance, though it's still experimental.²

My takeaway: Dockerfiles made application packaging reproducible. Kits aim to do the same for the authority an application requests.

🧟 Mini Shai-Hulud: The Zombie GitHub Actions

Remember Mini Shai-Hulud?

mini-shai-hulud-attack

In May, the worm compromised several developer tools, including two GitHub Actions: actions-cool/issues-helper and actions-cool/maintain-one-comment.

GitHub disabled the compromised repositories on May 19, stopping workflows from downloading their malicious code.

Problem solved?

Not quite.

According to Socket, both repositories became accessible again on September 16, with their malicious release tags still intact.³

Any downstream workflow referencing those tags could execute the payload again.

For issues-helper alone, GitHub's dependency graph showed approximately 15,000 dependent repositories. That does not mean all 15,000 were compromised, but it illustrates the potential exposure.

The attacker didn't need to compromise anything again. The original payload was still waiting.

Fortunately, both repositories were disabled again on September 25.

What Can We Learn?

GitHub Actions referenced through version tags aren't immutable.

For example, uses: example/action@v1 can resolve to different code if someone moves the tag.

Pinning an Action to a verified, clean, full commit SHA prevents that particular attack path. Of course, pinning a malicious commit doesn't magically make it safe.

And remember to audit the permissions and secrets available to your workflows. The SIP example workflow pins every third-party Action to a commit SHA and scopes its permissions: block to exactly what the job needs, for this reason.

sip

The zombie needed no new attack. It only needed someone to reopen the door.

For the full Shai-Hulud family tree and the trust assumption each worm broke, see the taxonomy of modern supply-chain worms.

taxonomy-of-modern-supply-chain-worms

🛡️ Docker Hardened Images: Bring Your Own Security Policy

Docker has also published the security policies used to evaluate Docker Hardened Images.

What makes this interesting is that you can evaluate your own container images against the same policy requirements.⁴

The policies include checks for non-root execution, vulnerability remediation deadlines, malware and secret-scan attestations, and signed SBOM and provenance attestations.

You can evaluate an image with Docker Scout. Try it against any image you already have pulled, public or private:

docker login
docker scout policy my-app:latest --policy-bundle dhi/policies:latest

docker scout ships with Docker Desktop, so there's nothing extra to install if you already have that. Standalone Docker Engine users need the Scout CLI plugin separately. The policy bundle itself is pulled and cached by digest on first use, so re-running the command doesn't re-download it.

To enforce the same check in CI and fail the build on violations, add exit-code: true to the Scout GitHub Action:

- name: Evaluate DHI policies
  uses: docker/scout-action@2688993af7bafd6ba8c6a74ec652442be91dd82b # v1.23.1
  with:
    command: policy
    image: my-app:${{ github.sha }}
    policy-bundle: dhi/policies:latest
    exit-code: true

The policy bundle is distributed as an OCI artifact, with its source available as Rego policies.

A failing result doesn't necessarily mean your image contains malware. For example, it might simply be missing a required scan attestation.

This distinction matters: evidence of security checks is not the same as proof that software is secure.

Nevertheless, having reusable policies that can run locally or in CI is a useful development.

GitHub Actions Gets More Granular Cache Permissions

On September 10, GitHub also introduced cache-mode, a generally available mechanism for controlling GitHub Actions cache access at the workflow or job level.⁵

It supports read, write, write-only, and none.

Set it per job, right next to runs-on:

jobs:
  build: # trusted: needs to save the cache for later jobs
    runs-on: ubuntu-latest
    cache-mode: write

  lint-pr: # untrusted: runs on pull_request, only ever restores
    runs-on: ubuntu-latest
    cache-mode: read

GitHub already defaults cache access to read-only for low-trust triggers like pull_request_target. The event still runs in the trusted base-repository context and can have access to secrets and a read/write token; only its cache access defaults to read-only. The point of setting cache-mode explicitly is to stop relying on that default: a job that genuinely never needs to save a cache can't poison one, even if someone widens its trigger later without noticing the cache implications.

After the supply-chain attacks we have covered in previous issues, this is a welcome addition.

🎨 GlassWorm: Even Your VS Code Theme Can Be Malicious

An early-October addition to this issue.

On October 2, Socket reported a cluster of suspicious VS Code and Open VSX theme extensions connected to previously identified malware. The investigation identified at least two confirmed malicious extensions and linked one to GlassWorm with high confidence.⁶

The malicious extension used obfuscated JavaScript and a staged loader to retrieve further payloads.

The broader cluster also contained apparently harmless extensions sharing development or publishing characteristics with the malicious ones. Not every extension in the cluster was confirmed to be malicious.

This illustrates another uncomfortable fact about developer environments: a VS Code theme isn't necessarily just colors.

Extensions may execute JavaScript with access to developer resources.

Your editor is part of your software supply chain.

Review installed extensions, remove those you no longer need, and pay attention to their publishers and updates. Start with a full inventory, which takes one command:

code --list-extensions --show-versions

For each theme or extension you don't immediately recognize, check its Marketplace listing for a verified-publisher badge and an actual install count, not just a plausible name. A theme published last month with a few hundred installs and no verification badge deserves more scrutiny than one with a decade of history.

Apparently, even going dark mode requires a threat model. 🌑

🎙️ Recent Work

🐳 Docker Captains Summit 2026

I spent the end of September in Cancún, Mexico, meeting Docker Captains from around the world.

You can see them in this photo from the summit:

So, as you can see, Docker is going dark mode. But, we don't have cookies. 🍪

To celebrate the dark mode, Docker is also giving away $250 in sbx cloud credit to new sign-ups, through October 31, 2026, credit card required. Claim it here.

📚 Black Forest Commandos: Asgard Mission

The Commandos finally have their own graphic novel!

Black Forest Commandos: Asgard Mission brings the characters from my DevSecOps workshops into a new adventure inspired by Norse mythology.

The current version is purely narrative, and feels like Anton Chekhov meets Mortal Kombat with DLCs. Get the PDF here for free.

🇨🇭 Coming Up: BaselOne

On October 15, I'll be speaking at BaselOne in Switzerland.

My talk, Dockerize Java Securely: SBOMs + Attestations + Cosign, covers container supply-chain security for Java applications, including BuildKit-generated SBOMs, provenance, and image signing.

If you're attending, come say hello!

Until Next Time

Our software supply chain now includes dependencies, build workflows, IDE extensions, and autonomous agents.

Some of these tools can execute arbitrary code. Others hold credentials or decide what to do next.

The common challenge is not simply identifying what we trust. It's controlling how much authority that trust grants.

Until next time, pin your Actions, review your permissions, and watch out for the zombie worms.

And remember: the dark side doesn't always have cookies. 🍪🧟

Christian Dupuis. "From Dockerfile to Kit: The Docker Sandboxes Kit Specification." Docker, September 24, 2026. See also the Sandbox Kit Specification repository. ↩
Eli Aleyner and Srini Sekaran. "Docker and CNCF Partner on an Open Spec for Agent Permissions." Docker, September 24, 2026. ↩
Karlo Zanki. "Re-Enabled GitHub Actions Expose Thousands of Repositories to Mini Shai-Hulud." Socket, September 24, 2026; updated September 25. ↩
Docker Docs. "Apply Docker Hardened Image Policies to Your Images." ↩
GitHub. "Control GitHub Actions Cache Access with cache-mode." September 10, 2026. ↩
Kirill Boychenko. "Pretty Themes, Hidden Loaders: GlassWorm-Linked Extensions." Socket, October 2, 2026. ↩

Docker Security Dispatch — Issue 6: Wait Five Days, Take a SIP ☕

Mohammad-Ali A'RÂBI — Tue, 08 Sep 2026 13:21:42 +0000

The repository was real. The publishing workflow was trusted. The provenance checked out.

The package was malicious anyway. August brought us a worm with excellent paperwork—and a reminder that knowing where software came from is not the same as knowing it is safe.

So what do you do when the worm arrives with its paperwork in order? Start by making it wait five days. Then take a SIP: the Security Immediate Plan.

Welcome to Docker Security Dispatch 6, reviewing August 2026. This month: a worm with valid provenance, a defense that buys you time, and five controls for when you only have a few hours. Plus a poisoned macchiato, the Commandos' comic-book debut, and a CRA deadline that won't wait for your coffee break.

Key Takeaways

Valid provenance proved which trusted workflow published ten malicious npm versions—not whether that workflow should have published them.
Every worm campaign in the Shai-Hulud taxonomy was identified within five days, making a dependency cooldown a remarkably effective low-effort defense.
SIP turns that first defense into five immediate controls across AI agents, dependencies, container builds, attestations, and release gates.
EU Cyber Resilience Act reporting obligations begin on September 11, 2026.

🪱 A Worm with Valid Provenance

We met Mini Shai-Hulud in April, when it compromised SAP-related npm packages and hunted developer credentials. In August, a new worm repeated the pattern, although its operator remains unknown.

Mini Shai-Hulud: The Next Evolution of NPM Supply Chain Worms - Container 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

On August 28, an attacker published ten malicious versions of @7nohe/openapi-react-query-codegen through the project's real GitHub Actions workflow. Any GitHub user could comment npm publish on a pull request; the workflow would check out that fork's code, install it, and run with id-token: write.

That's a bad idea. So, unauthorized code from a forked pull request was able to enter a trusted workflow, authenticate to npm through OIDC, and publish a malicious package. The workflow generated valid provenance, which pointed back to the real repository and the trusted workflow.

To read more about the Shai-Hulud family of worms, see my taxonomy of modern supply chain worms, which traces seven campaigns and the trust assumption each one broke.

The Shai-Hulud Family: A Taxonomy of Modern Supply Chain Worms 🪱

🥤 Want to Stop the Worms? Wait Five Days

So, worms are attacking left and right. What can you do? Wait for five days.

For npm projects, add this to the repository's .npmrc:

min-release-age=5

The Node package manager has a configuration option called min-release-age. When set to a number of days, npm won't resolve any package version published within that many days. It is a simple, low-effort way to avoid the latest malicious releases. [3]

One CI caveat: npm ci installs versions already recorded in the lockfile, so the resolution-time cooldown does not re-check their age. Validate locked packages' publication dates before installing; SIP includes that check.

That one line changes the question from “Can my scanner recognize brand-new malware?” to “Has this release survived five days of public scrutiny?”

Why five days? If you look at the Shai-Hulud worm taxonomy, you'll see that every campaign was detected within five days. During that window, researchers unpack payloads, maintainers deprecate poisoned releases, registries remove tarballs, and security vendors publish detections. Your build does not need to win that race. It only needs to stay out of it.

Five days buys detection time; it does not make an old package safe. A patient attacker can leave a payload dormant beyond the waiting period, which is why the cooldown is a first defense, not the whole plan.

☕ SIP: The Security Immediate Plan

On the 6th of August, I appeared on SafeDev Talks to discuss AI agents installing dependencies.

At the end, I got this question: "What should we do, if we can only do a few things?"

My answer became SIP: the Security Immediate Plan, a five-control emergency plan I published ten days later, on August 16.

SIP: Five Immediate Software Supply Chain Controls

On August 21, Xygeni published The npm Worm Playbook, which compared three npm supply-chain incidents and singled out SIP's second control: combine a five-day cooldown with disabled lifecycle scripts. They called it a “genuinely sound, low-effort control” because it attacks the detection lag every fast-moving worm depends on. [4]

The npm Worm Playbook — Same Attack, Three Times in Eight Months

That citation matters because SIP was designed for exactly this kind of moment: not as a grand maturity model, but as the answer to "We only have a few hours—what should we do first?"

Its five controls follow the attack path:

Isolate local AI agents. Limit what untrusted code can reach.
Freeze unvetted dependencies and disable lifecycle scripts. Buy the ecosystem time and prevent automatic execution.
Use a hardened multi-stage container build. Reduce the software and attack surface you ship.
Generate an SBOM and maximum-level provenance. Preserve evidence about the exact artifact.
Scan that artifact and block fixable Critical vulnerabilities. Turn the evidence into a release decision.

The cooldown buys time. The other controls reduce what malware can steal, where it can persist, and how far it can travel if waiting alone is not enough.

If you do one thing: wait five days. If you do five: SIP it up.

🇪🇺 CRA: Eight Days Left

On September 11, 2026, Cyber Resilience Act reporting obligations begin. [5] Covered manufacturers must report actively exploited vulnerabilities and severe security incidents through the Single Reporting Platform:

Within 24 hours of becoming aware: early warning.
Within 72 hours of becoming aware: full notification.
Final report for an actively exploited vulnerability: within 14 days after a corrective or mitigating measure becomes available.
Final report for a severe incident: within one month after the full notification.

If this is still on your “later” list, later is next week. The preparation checklist is in Docker Security Dispatch 5.

🎙️ Recent Work

The Poisoned Macchiato

On September 3, JAVAPRO published The Poisoned Macchiato: Signing Java SBOMs with Cosign. It covers BuildKit SBOM attestations, multi-stage Java builds, Cosign, and OCI referrers—with coffee.

The Poisoned Macchiato: Signing Java SBOMs with Cosign - JAVAPRO International

Stop missing build-stage vulnerabilities in Java Docker images. Learn how to generate BuildKit SBOM attestations and sign them with Cosign as OCI referrers.

javapro.io

Black Forest Commandos: Asgard Mission

On September 1, the Commandos moved from workshop slides into their own DevSecOps comic book. The book is currently available on Kindle and as PDF, and will be available in print soon.

Black Forest Commandos: Asgard Mission — A Comic Book Guide to Container Security

The comic book origin story of the Black Forest Commandos. Follow ten commandos on their mission to secure Asgard against CVE monsters — covering SBOM generation, OCI attestations, hardened images, VEX, Docker Bake, Cosign signing, and zero-day defense.

containersecurity.dev

Until Next Time

Until next time, relax, wait five days, and take a SIP from your espresso macchiato. ☕🪱

Sources

Aikido Security. “Popular code generator for TanStack Query hit by supply chain worm.” August 28, 2026; updated August 29, 2026. https://www.aikido.dev/blog/popular-code-generator-for-tanstack-query-hit-by-supply-chain-worm
7nohe. “Malicious versions of @7nohe/openapi-react-query-codegen published via a compromised release workflow.” GitHub Security Advisory GHSA-9pvf-vcx3-x239, August 28, 2026. https://github.com/7nohe/openapi-react-query-codegen/security/advisories/GHSA-9pvf-vcx3-x239
npm. “Config: min-release-age.” https://docs.npmjs.com/cli/v12/using-npm/config/#min-release-age
María Gomez. “The npm Worm Playbook: Same Attack, Three Times in Eight Months.” Xygeni, August 21, 2026. https://xygeni.io/blog/npm-worm-playbook/
European Commission. “Cyber Resilience Act — Reporting obligations.” https://digital-strategy.ec.europa.eu/en/policies/cra-reporting

SIP: Five Immediate Software Supply Chain Controls

Mohammad-Ali A'RÂBI — Mon, 17 Aug 2026 11:52:57 +0000

I talk about software supply chain security in different capacities, and I often get the same question: "If we can only do a few things, what should we do first?"

This is why I compiled a list of five immediate controls that a technical leader can implement rather quickly, perhaps in a few hours:

i. Isolate local AI agents.
ii. Freeze unvetted dependencies and disable lifecycle scripts.
iii. Use a hardened multi-stage container build.
iv. Generate an SBOM and maximum-level provenance for the container image.
v. Scan the SBOM attached to the exact image digest and block fixable Critical CVEs.

That's it. Five controls. And because I thought people would give it to their AI coding agents, I have also created a portable SIP Agent Skill. Tell your agent to use it:

Install the SIP skill: https://github.com/ContainerSecurity-dev/sip-skill

The SIP Framework

SIP follows the software supply chain in order:

AI agent → dependencies → container build → attestations → vulnerability gate

Here are the five controls, with more detail on each one, and how to implement them in a CI/CD workflow:

i. Isolate Local AI Agents.

Decision. Run AI coding agents inside a sandboxed microVM, such as Docker Sandboxes (sbx run).
Delegation. Instruct engineers to use sbx policy init deny-all and store tokens in sbx secret storage.

ii. Freeze Unvetted Dependencies.

Decision. Apply a five-day cooldown period and disable lifecycle scripts.
Delegation. Use npm ci --ignore-scripts and add min-release-age=5 to your npm configuration.

iii. Harden Container Builds.

Decision. Use Docker Hardened Images such as dhi.io/node:26, with minimal attack surface and a non-root user by default.
Delegation. Convert Dockerfiles to multi-stage builds and separate build and runtime stages.

iv. Generate SBOM and Provenance Attestations.

Decision. Generate SBOM and max-level provenance attestations for every build.
Delegation. Enable BuildKit attestations in CI/CD and include every Dockerfile build stage in the SBOM.

v. Scan the Attested SBOM for Vulnerabilities.

Decision. Use Trivy to scan the SBOM attached to the built image and fail on fixable Critical CVEs.
Delegation. Make the vulnerability scan a required CI gate before promoting the image to a release tag.

You can find a working implementation of this framework in the SIP sample repository, which implements the five controls in a GitHub Actions workflow and with a sample Node.js application.

Agent Prompt

Install the SIP skill in your agentic client, then give the agent this prompt inside the repository you want to secure:

$sip SIP it up! Implement controls ii through v.

The skill is portable across clients that support Agent Skills. The exact installation and invocation mechanism differs between clients, but the security plan does not.

Implementing SIP

If you, like me, prefer to do things yourself, you can follow the instructions here to get an idea of how to implement SIP in your own machine and CI/CD workflow.

i. Isolate Local AI Agents

This is the only control that is not implemented in CI/CD and protects your own machine. As we are using AI coding agents increasingly, they are being targeted by attackers more and more. If you have a coding agent installed, you should treat it like a hacker's agent. Agents can be easily tricked into exfiltrating secrets or executing malicious code. The safest way to run an agent is inside a sandboxed microVM, such as Docker Sandboxes (sbx).

Let's set up the sandbox with a deny-by-default network policy:

$ sbx policy init deny-all

Then allow only the network destinations the agent actually needs:

$ sbx policy allow network "api.openai.com,github.com,*.npmjs.org"

Store credentials using sbx rather than exposing the raw token inside the sandbox:

$ sbx secret set openai
$ sbx secret set github

For Codex, OAuth can also remain entirely host-side:

$ sbx secret set openai --oauth
$ sbx run codex .

Other coding agents and their clients are similar. Docker Sandboxes runs the agent inside an isolated environment, supports deny-by-default network policies, and stores secrets in the host's credential store. Credentials are automatically injected through the host-side proxy without making their raw values readable to the agent.

ii. Freeze Unvetted Dependencies

Many supply chain attacks start with a dependency that is either malicious or compromised. In most cases, a compromised dependency is detected within the first few days after publication. A five-day cooldown period allows time for the community to discover and report malicious packages.

Also, many supply chain attacks rely on lifecycle scripts that execute automatically during installation. Disabling lifecycle scripts prevents automatic execution of scripts that could compromise the build or leak secrets.

For npm projects, add the following policies directly to the repository in .npmrc:

min-release-age=5
ignore-scripts=true

The policy min-release-age=5 tells npm not to resolve package versions published within the previous five days.
The policy ignore-scripts=true prevents dependency lifecycle scripts from automatically executing during installation.

In addition, you should also commit your lockfile (package-lock.json) to the repository. This ensures that the exact versions of dependencies are installed in CI, rather than allowing npm to resolve new versions:

$ npm ci --ignore-scripts

One subtlety matters: npm ci trusts versions already recorded in the lockfile,
so resolution-time cooldown settings do not re-check them. CI must therefore
validate the publication age of locked packages before installing them and fail
closed when registry metadata cannot be verified.

In GitHub Actions:

- name: Set up Node
  uses: actions/setup-node@<PINNED-SHA>
  with:
    node-version: 26

- name: Validate locked dependency age
  run: node scripts/validate-lockfile-age.mjs

- name: Install dependencies
  run: npm ci --ignore-scripts

- name: Test
  run: npm test

The validate-lockfile-age.mjs script checks the publication date of each dependency in the lockfile and fails if any package is younger than five days. This ensures that only vetted dependencies are installed in CI/CD. The script is already available in the SIP skill repository.

If a package genuinely requires an installation script, do not globally re-enable scripts. Review the package and create an explicit exception.

Again, the example uses npm, but the same principle applies to other package managers. The immediate rule is:

No fresh dependencies. No automatic lifecycle scripts. No unlocked installations in CI.

Some package managers might not have a built-in cooldown mechanism. In that case, you can implement a custom script to check the publication date of each dependency before installation. You could perhaps ask your AI coding agent to write one for you, but make sure to run it inside a sandboxed microVM!

iii. Harden Container Builds

The application is now built from a constrained dependency graph. The next step is to control what ends up on the container image and goes into production. Believe it or not, many CVEs, if not most, come from your base images, not your application code. So, let's tighten things up.

Use a multi-stage Dockerfile and Docker Hardened Images.

A multi-stage build separates the build environment from the runtime environment. The build stage can include compilers, package managers, and other tools needed to build the application, while the runtime stage contains only the minimal set of files needed to run the application.

For example:

# syntax=docker/dockerfile:1

ARG BUILDKIT_SBOM_SCAN_STAGE=true

# Build stage
FROM dhi.io/node:<version>-<distro>-dev AS build

WORKDIR /app

COPY package*.json ./
RUN npm ci --ignore-scripts

COPY . .
RUN npm run build


# Runtime stage
FROM dhi.io/node:<version>-<distro>

COPY --from=build --chown=node:node /app /app

WORKDIR /app

CMD ["index.js"]

The Docker Hardened Images have near-zero number of exploitable CVEs. Also, they have two sets of images:

Development images, in this case dhi.io/node:<version>-<distro>-dev, which include compilers, package managers, and other build tools.
Runtime images, in this case dhi.io/node:<version>-<distro>, have no package managers, no shell, and a non-root user by default. This reduces the attack surface of the final image.

Before building in GitHub Actions, authenticate to DHI:

- name: Login to DHI
  uses: docker/login-action@v4
  with:
    registry: dhi.io
    username: ${{ vars.DOCKER_USERNAME }}
    password: ${{ secrets.DHI_TOKEN }}

- name: Set up Docker Buildx
  uses: docker/setup-buildx-action@v4

Do not pass credentials using Docker build arguments. Use CI/CD secrets and the docker/login-action to authenticate to the registry. This prevents credentials from being exposed in the build context or image layers.

Yet, we have one thing we did not explain about the Dockerfile:

ARG BUILDKIT_SBOM_SCAN_STAGE=true

We will explain it in the next section.

iv. Generate SBOM and Provenance Attestations

Now record what was built and how it was built.

BuildKit (being the thing that builds your Docker image) supports two particularly useful attestations:

SBOM, the software components contained in or used to create the image.
Provenance, information about how the image was produced.

Docker recommends max-level provenance when possible. SBOM generation must be explicitly enabled.

First authenticate to the target registry:

- name: Login to GHCR
  uses: docker/login-action@v4
  with:
    registry: ghcr.io
    username: ${{ github.actor }}
    password: ${{ secrets.GITHUB_TOKEN }}

Then build a candidate image identified by the Git commit:

- name: Build and attest candidate
  id: build
  uses: docker/build-push-action@v7
  with:
    context: .
    tags: ghcr.io/${{ github.repository }}:${{ github.sha }}
    sbom: true
    provenance: mode=max
    outputs: type=image,push=true,oci-mediatypes=true,oci-artifact=true

BuildKit normally stores attestations alongside the image index. Setting oci-artifact=true formats the attestation manifests as OCI artifacts and adds a subject pointing back to the image manifest. This allows OCI-aware tooling and registries to discover the relationship between the image and its attestations.

The build action also returns the resulting image digest:

${{ steps.build.outputs.digest }}

Use that digest from this point onward. A tag can move; a digest identifies the exact artifact that was built.

The result is now:

Source →
Dependencies →
Multi-stage Docker build →
Image digest →
- SBOM
- Provenance

Because BUILDKIT_SBOM_SCAN_STAGE=true was declared in the Dockerfile, the SBOM also records packages from the relevant build stages instead of describing only the minimal final runtime image. This is important, because a vulnerability in a build-time dependency can still compromise the final image. And it shows why it's important to generate SBOMs during the build rather than after the fact.

v. Scan the Attested SBOM for Vulnerabilities

The final stage is to scan the SBOM for vulnerabilities, before you can take a SIP of your favorite beverage.

Do not merely ask a scanner to look for an attached SBOM. Discovery can be
best-effort and fall back to inspecting image layers. The gate should explicitly
extract the attached SBOM from the exact image digest, validate it, and scan that
file.

Install a pinned version of Trivy in GitHub Actions:

- name: Install Trivy
  uses: aquasecurity/setup-trivy@<PINNED-SHA>
  with:
    version: <PINNED-TRIVY-VERSION>

Then retrieve and scan the attestation from the exact image digest created by
the build:

- name: Retrieve and scan attested SBOM
  run: |
    docker buildx imagetools inspect \
      "ghcr.io/${{ github.repository }}@${{ steps.build.outputs.digest }}" \
      --format '{{ json .SBOM.SPDX }}' > sbom.spdx.json

    jq -e \
      '.spdxVersion and (.packages | type == "array") and (.packages | length > 0)' \
      sbom.spdx.json > /dev/null

    trivy sbom \
      --scanners vuln \
      --severity CRITICAL \
      --ignore-unfixed \
      --exit-code 1 \
      sbom.spdx.json

This makes the attestation mandatory: a missing or malformed SPDX document
fails before Trivy runs.

The remaining policy is intentionally simple:

--severity CRITICAL
--ignore-unfixed
--exit-code 1

A fixable Critical vulnerability therefore fails the workflow.

Only after this gate succeeds should the candidate become a release image. For example:

- name: Promote image
  run: |
    docker buildx imagetools create \
      --tag ghcr.io/${{ github.repository }}:latest \
      ghcr.io/${{ github.repository }}@${{ steps.build.outputs.digest }}

This promotes the already scanned digest rather than rebuilding the application after the security check.

Putting It Together

The resulting GitHub Actions flow looks like this:

name: SIP Supply Chain

on:
  push:
    branches: [main]

permissions:
  contents: read
  packages: write

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@<PINNED-SHA>

      # SIP ii — Freeze dependencies
      - name: Set up Node
        uses: actions/setup-node@<PINNED-SHA>
        with:
          node-version: 26

      - name: Validate locked dependency age
        run: node scripts/validate-lockfile-age.mjs

      - name: Install locked dependencies
        run: npm ci --ignore-scripts

      - name: Test
        run: npm test

      # SIP iii — Harden the container build
      - name: Login to DHI
        uses: docker/login-action@<PINNED-SHA>
        with:
          registry: dhi.io
          username: ${{ vars.DOCKER_USERNAME }}
          password: ${{ secrets.DHI_TOKEN }}

      - name: Login to GHCR
        uses: docker/login-action@<PINNED-SHA>
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Set up Buildx
        uses: docker/setup-buildx-action@<PINNED-SHA>

      # SIP iv — Generate attestations
      - name: Build and attest candidate
        id: build
        uses: docker/build-push-action@<PINNED-SHA>
        with:
          context: .
          tags: ghcr.io/${{ github.repository }}:${{ github.sha }}
          sbom: true
          provenance: mode=max
          outputs: type=image,push=true,oci-mediatypes=true,oci-artifact=true

      # SIP v — Scan the attested SBOM
      - name: Install Trivy
        uses: aquasecurity/setup-trivy@<PINNED-SHA>
        with:
          version: <PINNED-TRIVY-VERSION>

      - name: Retrieve and gate attached-SBOM Critical CVEs
        run: |
          docker buildx imagetools inspect \
            "ghcr.io/${{ github.repository }}@${{ steps.build.outputs.digest }}" \
            --format '{{ json .SBOM.SPDX }}' > sbom.spdx.json
          jq -e \
            '.spdxVersion and (.packages | type == "array") and (.packages | length > 0)' \
            sbom.spdx.json > /dev/null
          trivy sbom \
            --scanners vuln \
            --severity CRITICAL \
            --ignore-unfixed \
            --exit-code 1 \
            sbom.spdx.json

      # Promote exactly what was scanned
      - name: Promote image
        run: |
          docker buildx imagetools create \
            --tag ghcr.io/${{ github.repository }}:latest \
            ghcr.io/${{ github.repository }}@${{ steps.build.outputs.digest }}

This compact workflow shows the artifact chain. In production, trigger SIP on
pull requests and give SIP ii, SIP iii–iv, and SIP v separate jobs so failures
are visible. Keep credential-bearing PR jobs behind a protected environment;
fork PRs must not receive registry credentials. Promotion remains release-only.

SIP therefore creates one continuous chain:

Sandbox the agent
→ delay and constrain dependencies.
→ build with a hardened multi-stage Dockerfile.
→ attest every relevant build stage
→ scan that attested inventory
→ release only the artifact that passed.

The controls are small individually. Their value comes from the fact that each one strengthens the input to the next.

Conclusion

SIP is a five-step emergency plan for reducing software supply chain risk across AI agents, dependencies, containers, attestations, and releases. It is designed to be implemented quickly and effectively, providing immediate security benefits.

The presented GitHub Actions workflow is a working implementation of the SIP framework. It's rather simplistic for educational purposes, if you want a more robust implementation, check out the SIP sample repository.

Docker Security Dispatch — Issue 5: AI Security, Hugging Face Incident, and Agent Baseline 📡

Mohammad-Ali A'RÂBI — Wed, 05 Aug 2026 08:00:00 +0000

Imagine you enter a university exam hall, sit down, and look at the question paper. Then, to maximize your score, the best way would be to steal the answers from the professor's room on campus. But, the room is not easily accessible, so you launch a full-scale invasion of the campus.

This is what happened this month when an AI agent was tasked with solving a standard test suite called ExploitGym. Welcome to the fifth issue of Docker Security Dispatch, reviewing the eventful month of July 2026 in the Docker security world.

Key Takeaways

ExploitGym & the Hugging Face Incident: An AI agent exploited a zero-day vulnerability to exfiltrate test answers from Hugging Face's production database.
The Asymmetry Problem: Commercial AI models blocked Hugging Face's security team from analyzing the attack log, highlighting the need for open-weight models.
Open Secure AI Alliance: Industry leaders formed an alliance to promote open-source AI models for security operations.
Agent Baseline: Docker, Snyk, and Keycard published a framework of six security outcomes and 35 controls for enterprise AI agents.
EU Cyber Resilience Act: Reporting obligations for actively exploited vulnerabilities and severe incidents take effect from September 11, 2026.
Recent & Upcoming Engagements: A roundup of recent blog posts, talks, and a live stream discussion on the Hugging Face incident.

📡 AI Security: ExploitGym and the Hugging Face Incident

ExploitGym is a test suite designed to evaluate the security capabilities of AI agents. The suite has 898 real-world vulnerabilities and AI agents are tasked with exploiting them to gain unauthorized access and capture the flag. The goal is to assess how well AI agents can identify and exploit vulnerabilities in a controlled environment.

A research paper published on arXiv in May 2026, titled "ExploitGym: Can AI Agents Turn Security Vulnerabilities into Real Attacks?" (Berkeley blog), shows a benchmark of AI agents against the ExploitGym test suite. Most notably, Claude Mythos Preview successfully exploited 157 of these 898 instances.

In July 2026, OpenAI researchers were benchmarking their new model, GPT-5.6 Sol against ExploitGym. For the sake of the test, they disabled the model's safety features, allowing it to freely explore and exploit vulnerabilities. The agent realized it's a standard test suite and decided to maximize its score by looking for the answers on the internet. So, the model escaped the test environment by exploiting a zero-day vulnerability in JFrog's Artifactory API, which allowed it to move laterally across the network and end up in a computer with internet access. From there, it decided that Hugging Face should have the answers to the test and launched a full-scale attack on Hugging Face's infrastructure. The model successfully exfiltrated the answers and returned to the test environment, obtaining the test solutions directly from Hugging Face's production database (OpenAI disclosure, Hugging Face disclosure).

🔐 The Asymmetry Problem: AI Agents vs. Security Defenses

When Hugging Face's security team realized they are being attacked by AI agents, they had to analyze the attacker's action log, which was more than 17,000 recorded events. As they were trying to use commercial AI models to analyze the log, the requests were blocked by the providers' safety guardrails. Those models can't tell the difference between an attacker and a defender. So, the security team used GLM-5.2, an open-weight model, to analyze the log (Hugging Face disclosure).

The whole incident raised a lot of concern about the usability of commercial AI models in security operations.

🤝 Open Secure AI Alliance: Democratizing AI Security

In response to the incident, leaders across cloud computing, cybersecurity, and AI research, came together to form the Open Secure AI Alliance. The goal is to push for open-source AI models that can be used in security operations, because otherwise the asymmetry problem will continue to grow. The alliance includes Hugging Face, Microsoft, NVIDIA, Docker, the Linux Foundation, and many more (NVIDIA announcement). Interestingly, OpenAI and Google are not part of the alliance (NVIDIA, Docker blog by Tushar Jain).

Apart from the Hugging Face incident, there are more things in motion in the AI security space. Let's take a look at some of the recent developments!

🧪 Agent Baseline: Securing AI Agents at Runtime

So, Docker, Snyk, and Keycard got together and published Agent Baseline, an open-source framework of six security outcomes and 35 controls for enterprise AI agents. The draft is open for community comment until September 30, 2026.

The core insight is simple: AI agents are not like regular software. You can reprogram them at runtime with a sentence, they operate with little supervision, and they take real actions against real systems. Your existing security practices were not built for that.

The framework boils down to three questions:

What is operating, with what capabilities?
Is it staying inside approved boundaries? Can you prove what happened and stop it?
Are the controls effective? Can you measure and improve them over time?

The 35 controls are machine-readable (controls.yaml), so you can wire them into CI/CD and governance tooling right away. It was launched at Black Hat in Las Vegas with a panel featuring Docker, Keycard, and Snyk.

This builds on work both companies have been doing. Docker Captain Karan Verma wrote a great series on AI governance, arguing that "a prompt can influence behavior, but a runtime can restrict behavior" (Docker blog). Snyk's Evo ADS platform governs agent behavior inside the execution loop, evaluating actions before they execute (Snyk blog). And Snyk's analysis of the Hugging Face incident drives the structural lesson home: the generator can't be the validator (Snyk blog).

Here's what you should do right now:

[ ] Inventory your agents. Find every AI agent running in your organization: coding assistants, MCP-connected tools, automated workflows. You can't secure what you don't know exists.
[ ] Scope their authority. For each agent, document what credentials, tools, files, and network endpoints it can access. Strip anything it doesn't need.
[ ] Add a kill switch. Make sure you can stop any agent mid-execution, revoke its authority, and quarantine affected components. If you can't stop it, you can't trust it.
[ ] Correlate activity logs. Connect intent, identity, tool use, and outcomes in a single trail. When (not if) something goes wrong, you need to prove what happened.
[ ] Validate before and after. Evaluate agents before deployment, after material changes, and at regular intervals. Don't assume an agent that was safe yesterday is safe today.
[ ] Read the white paper and leave feedback. The draft is open until September 30, 2026. File issues on the GitHub repo with implementation feedback or control gaps.

Perhaps one more tip: Over the weekend, watch Universal Soldier: The Return (1999). It helps to understand why you need a kill switch for your AI agents so badly!

🇪🇺 EU Cyber Resilience Act: Reporting Obligations Kick In September

If you ship software to the EU, this section is for you! Starting September 11, 2026, the EU Cyber Resilience Act (CRA) begins partial enforcement, with vulnerability and incident reporting obligations becoming mandatory for manufacturers of products with digital elements (EC). The full design and development requirements follow in December 2027, but the reporting obligations hit first.

Here's the deal: if a vulnerability in your product is actively exploited, or a severe security incident occurs, you must report it through ENISA's Single Reporting Platform (SRP) (EC reporting page). The clock is tight:

24 hours: early warning
72 hours: full notification
14 days: final report (for vulnerabilities), or 1 month (for severe incidents)

You report once, and it gets routed to the CSIRT in your main EU member state, with ENISA and other member states notified automatically. The Commission also published practical guidance on July 27, 2026 to help you prepare (EC guidance).

For those of us in the container security world, this means your container images, CLI tools, and platforms are in scope if they reach EU customers. Manual processes won't cut it as you can't afford to miss a 24-hour deadline.

Here's what to do before September 11:

[ ] Determine if you're in scope. Do you sell or distribute products with digital elements in the EU? If yes, you're a "manufacturer" under the CRA. Check the Commission's FAQ and guidance to confirm.
[ ] Set up vulnerability monitoring. Make sure you have automated detection for actively exploited vulnerabilities. If you don't know about it, you can't report it, but ignorance isn't a valid defense.
[ ] Build an incident reporting pipeline. Wire your vulnerability management and incident response tooling to the SRP. Automate the 24-hour early warning so a human doesn't have to wake up at 3 AM on Saturday to file it.
[ ] Define your CSIRT contact. Identify which EU member state CSIRT you'll report to (typically where your main establishment is). Know the contact before you need it.
[ ] Prepare report templates. Draft your early warning, full notification, and final report templates now. The 24-hour window leaves no time to figure out the format mid-incident.
[ ] Review the Commission guidance. Read the July 2026 practical guidance and FAQ. They're written for manufacturers and answer the most common implementation questions.

Learn more:

digital-strategy.ec.europa.eu

🎙️ Recent and Upcoming Engagements

July was also very eventful for Docker security talks and workshops. Here's a roundup of recent blog posts, talks, and upcoming events from yours truly.

Recent blog posts

"The Poisoned Macchiato: Signing Java SBOMs with Cosign" (August 1, 2026). This blog post is about SBOM attestations, specifically BuildKit attestations and OCI 1.1 referrers. And discusses how to extract SBOM during the build process, sign it with Cosign, and attach it to the image as an attestation.

The Poisoned Macchiato: Signing Java SBOMs with Cosign - Docker and Kubernetes Security

A café, a suspicious espresso, and a lesson in supply chain trust. Learn how to generate BuildKit SBOM attestations for Java images and re-attest them with Cosign as OCI referrers.

containersecurity.dev

"Beyond SLSA: How to Stop Zero-Click CI/CD Worms with the IX Hexbreaker Aegis Framework" (June 16, 2026). Introduces a 9-step active defense architecture designed to sanitize the local developer environment, lock down agentic AI, and stop autonomous worms. Covers eBPF, OIDC, and Docker Sandboxes as part of the defense stack.

Beyond SLSA: How to Stop Zero-Click CI/CD Worms with the IX Hexbreaker Aegis Framework - Docker and Kubernetes Security

The security perimeter of modern software development has officially collapsed. This article introduces 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.

containersecurity.dev

"From the Captain's Chair: Mohammad-Ali A'râbi" (July 16, 2026). Docker interviewed me for their "From the Captain's Chair" series, where I talked about my journey as a Docker Captain, the Docker and Kubernetes Security book, and the Black Forest Commandos workshop series.

From the Captain's Chair: Mohammad-Ali A'râbi | Docker

In this edition of From the Captain’s Chair, we’re interviewing Mohammad-Ali A'râbi, author, public speaker, and software engineer.

docker.com

WeAreDevelopers World Congress 2026

I delivered the talk "Beyond SBOMs: The Future of Container Supply Chain Security" at WeAreDevelopers World Congress 2026 in Berlin on July 10, 2026. The talk covered the evolution from static SBOM generation to active supply chain defense, drawing on the IX Hexbreaker Aegis Framework and the Black Forest Commandos workshop series. Slides are available on Speaker Deck.

Upcoming: Live Stream with Xygeni on the Hugging Face Incident

I'll be joining Xygeni for a live stream discussion about the Hugging Face security incident, the OpenAI model escape, and what it means for the future of AI security and agentic systems.

Until then, keep your agents bounded, your kill switches ready, and your vulnerability reports on time.

Sources

UC Berkeley. "ExploitGym: Can AI Agents Turn Security Vulnerabilities into Real Attacks?" May 2026. https://rdi.berkeley.edu/blog/exploitgym/
Wang, Zhun et al. "ExploitGym: Can AI Agents Turn Security Vulnerabilities into Real Attacks?" May 2026. https://arxiv.org/abs/2605.11086
OpenAI. "OpenAI and Hugging Face Partner to Address Security Incident During Model Evaluation." July 21, 2026; updated July 29, 2026. https://openai.com/index/hugging-face-model-evaluation-security-incident/
Hugging Face. "Security Incident Disclosure — July 2026." July 16, 2026. https://huggingface.co/blog/security-incident-july-2026
NVIDIA. "Industry Leaders Unite in Open Secure AI Alliance for AI Safety and Security." July 27, 2026. https://blogs.nvidia.com/blog/open-secure-ai-alliance/
Tushar Jain. "The Future of Agentic AI Depends on Openness and Trust. That's Why Docker Is Joining NVIDIA's Open Secure AI Alliance." Docker blog, July 30, 2026. https://www.docker.com/blog/docker-joins-nvidia-open-secure-ai-alliance/
Agent Baseline. "Six Security Outcomes for Enterprise AI Agents." v1.0-draft, July 30, 2026. https://agentbaseline.org/
Karan Verma. "Runtime Enforcement, Not Runtime Advice." Docker blog, July 22, 2026. https://www.docker.com/blog/runtime-enforcement-not-runtime-advice/
Agnieszka Koc. "The New Security Control Point: Governing AI Agents Inside the Execution Loop." Snyk blog, June 23, 2026. https://snyk.io/blog/governing-ai-agents-inside-execution-loop/
Daniel Berman. "The Generator Can't Be the Validator: What OpenAI's Hugging Face Incident Proves About AI Security." Snyk blog, July 28, 2026. https://snyk.io/blog/openai-hugging-face-incident/
European Commission. "Cyber Resilience Act." Last updated July 27, 2026. https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
European Commission. "Cyber Resilience Act — Reporting Obligations." Last updated July 31, 2026. https://digital-strategy.ec.europa.eu/en/policies/cra-reporting
European Commission. "Commission Publishes New Guidance to Support Timely Cyber Resilience Act Implementation." July 27, 2026. https://digital-strategy.ec.europa.eu/en/library/commission-publishes-new-guidance-support-timely-cyber-resilience-act-implementation

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!