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

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

1. Isolate local AI agents. Limit what untrusted code can reach.
2. Freeze unvetted dependencies and disable lifecycle scripts. Buy the ecosystem time and prevent automatic execution.
3. Use a hardened multi-stage container build. Reduce the software and attack surface you ship.
4. Generate an SBOM and maximum-level provenance. Preserve evidence about the exact artifact.
5. 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.
• Within 14 days after a corrective or mitigating measure becomes available: final report for an actively exploited vulnerability.
• Within one month after the full notification: final report for a severe incident.

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

Sources

1. 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
2. 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
3. npm. "Config: min-release-age." https://docs.npmjs.com/cli/v12/using-npm/config/#min-release-age
4. 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/
5. European Commission. "Cyber Resilience Act - Reporting obligations." https://digital-strategy.ec.europa.eu/en/policies/cra-reporting