Dependency cooldowns: a simple supply chain fix

Sometimes the best defense is simply waiting

Update
March 2026 saw three major supply chain compromises in under two weeks: Trivy, LiteLLM, and axios. April 2026 added two more (xinference on PyPI, and a multi-channel Checkmarx compromise hitting their Docker images, GitHub Action, and VS Code extensions). May 2026 then brought the TanStack Mini Shai-Hulud campaign (42 official npm packages compromised within minutes from a pull_request_target workflow misconfiguration), and just eight days later the durabletask compromise: TeamPCP pushed three malicious versions of Microsoft’s official Azure Durable Functions Python SDK directly to PyPI inside a 35-minute window. On May 16, Grafana Labs disclosed that the same TanStack cascade had reached its own GitHub environment: caught on day one, but one workflow token survived rotation and gave attackers five more days of access. Then on May 18, the Nx Console VS Code extension (2.2M installs, verified publisher) was backdoored for 18 minutes via the same chain reaction and breached even GitHub itself. I’ve updated this post to reflect on each incident, expanded the IDE extensions section into a full treatment of extension-layer supply chain risk, and added a new section on CI/CD identity hygiene and verified token rotation.
Christian Schneider · 27 Jan 2026 · 20 min read

The golden hour problem

TL;DR
Most supply chain attacks—including short-lived campaigns like the Nx incident and the recent wormable Shai-Hulud incarnations—exploit a narrow window between malicious package publication and detection. In DevSecOps consulting engagements, simple cooldown policies have proven effective at eliminating exposure: a zero-cost 7-day delay breaks the attacker’s time advantage and neutralizes short-lived blast radii easily.

Read on if your build pipelines auto-adopt new dependency versions — a zero-cost delay policy eliminates most supply chain attack windows.

Most supply chain attacks share a common pattern: malicious code gets published to a package registry, and within hours it’s already been downloaded thousands of times before anyone notices. By the time security researchers flag the package or the registry removes it, the damage is done.

This is the golden hour of supply chain attacks: the window where attackers race to compromise systems before their malicious package gets detected and removed. They exploit the immediate-adoption culture of modern development. When a popular package releases a new version, CI/CD pipelines worldwide pull it automatically within minutes, giving attackers just enough time to compromise thousands of build systems.

Consider the Nx supply chain attack from August 2025: Malicious packages were published to npm at 22:32 UTC on August 26. NPM was alerted at 02:44 UTC and removed all affected versions within an hour. Total exposure window: roughly 4–5 hours. Yet in that brief period, thousands of developers had their secrets exfiltrated, including SSH keys, GitHub tokens, and API credentials. The malware even attempted to leverage local AI CLI tools for reconnaissance, a disturbing first in supply chain attacks.

Then March 2026 happened. Three major compromises in under two weeks:

The axios compromise hit one of npm’s most widely used packages. The attacker hijacked a maintainer account, injected a hidden dependency (plain-crypto-js) that delivered cross-platform malware, and hit both release branches within 39 minutes. The malicious versions were pulled within hours. At that download volume, two hours is enough. A cooldown policy likely would have made this a non-event.
LiteLLM followed the same pattern: malicious PyPI releases with a three-stage credential harvester, removed within hours. Again, cooldowns would have prevented exposure.
The Trivy incident (suspected root cause of the LiteLLM compromise) was a different animal. TeamPCP force-pushed many version tags in the aquasecurity/trivy-action GitHub Actions repository and replaced tags in setup-trivy, redirecting existing trusted references to malicious commits. In that tag-hijack scenario, no new version needs to be published, so cooldowns alone can’t help. What can: pinning to immutable commit SHAs in addition to cooldowns.

April 2026 added more to the pile:

The xinference PyPI compromise (April 22, 2026) hit a Python package with 680K downloads and a 9.3K-star repo. Three poisoned releases (2.6.0–2.6.2) landed on PyPI with the malicious payload sitting in xinference/__init__.py, which means it ran on every import xinference: CLI launches, service startup, downstream libraries that just touched the package. Each of those code paths exfiltrated cloud credentials, SSH keys, and .env contents to the attacker’s C2. Maintainers yanked the versions within hours of the first user report. The payload carried a # hacked by teampcp marker, though TeamPCP publicly denied involvement and pointed at a copycat. Either way, the lesson holds: same pattern as axios and LiteLLM, same defense. A 7-day cooldown keeps your pipeline from ever seeing these releases.
The same day, a Checkmarx supply chain compromise hit several distribution channels at once: poisoned tags on the public KICS Docker image, a malicious tag in the GitHub Action repository, and tampered Checkmarx VS Code extensions on both the Microsoft and Open VSX marketplaces. Exposure windows were short, roughly half an hour for the Docker side and about 80 minutes for the Action. Notably, this was the second Checkmarx incident in about a month, after a March 23 compromise of their GitHub Actions and OpenVSX plugins. Like Trivy, another security vendor’s distribution channel became the attack vector, and the same defenses apply: pin GitHub Actions to commit SHAs, pin container images to digests (@sha256:<digest>) rather than mutable tags like latest. And since IDEs auto-update extensions in the background by default, reviewing or disabling those auto-update settings is worth doing, at least for security-critical tooling. Two hits in 30 days against the same vendor also says something on its own: when distribution channels are the soft target, repeat compromises aren’t surprising.

May 2026 then added the clearest illustration so far of why upstream pipeline security and downstream cooldown policies are two sides of the same problem:

The TanStack compromise (May 11, 2026) was a Mini Shai-Hulud variant that pushed 84 malicious versions across 42 @tanstack/* packages in roughly six minutes. The entry point was a pull_request_target workflow in TanStack/router that ran fork-controlled code with elevated trust, combined with actions/cache poisoning across the fork-to-base trust boundary and runtime extraction of an OIDC token from the runner process. The attacker then used the project’s trusted-publisher binding to publish straight to npm. @tanstack/react-router alone pulls roughly 12 million weekly downloads, so the blast radius was sizable. Maintainers and npm yanked the malicious versions within hours after the first community reports. Wiz attributes the campaign to TeamPCP, the same crew behind Trivy, Checkmarx, and several other 2025–2026 incidents.

Two things are worth pulling out. First, this is the exact upstream-pipeline failure mode I covered in my previous Ship fast, but guard faster post: pull_request_target with a fork checkout is the classic “Pwn Request” anti-pattern, and permissions: contents: read does not stop actions/cache from writing across the fork-to-base trust boundary. Second, even with a clean compromise at the source, downstream consumers who held off on accepting fresh versions for a few days were never exposed. The malicious releases were already gone before their pipelines would have considered them. Cooldowns do not fix the upstream maintainer’s pipeline. They keep your project from being collateral damage when somebody else’s pipeline fails.

The downstream consequences of the TanStack push started surfacing within days. The most public confirmation came from a high-profile observability vendor:

Grafana Labs disclosed on May 16 that attackers tied to the TanStack campaign had reached parts of its GitHub environment. The Grafana team detected suspicious activity on May 11 — the same day the malicious @tanstack/* versions hit npm — and rotated what it described as “a significant number” of GitHub workflow tokens in response. They missed one. Attackers used that single leftover token to keep accessing repositories and then sent Grafana a ransom demand on May 16. The Unit 42 write-up on the broader campaign explains why the rotation set was so hard to get right: the May 11 wave chained pull_request_target with actions/cache poisoning, then extracted an OpenID Connect token from runner memory before publishing malicious packages. So the credentials in scope for Grafana’s response weren’t a long-lived PAT or two. They were a mix of static workflow secrets, short-lived OIDC bindings, and runner-internal artifacts spread across many workflows.

A 7-day cooldown on newly published @tanstack/* versions would likely have kept most downstream consumers outside the initial malicious publication window. For organizations whose pipelines had already resolved the compromised versions before the takedown, the next-best control is a rotation playbook that actually verifies the rotation finished. Grafana caught the cascade on day one and still left one credential behind. That is the part of this incident worth coming back to in the identity-hygiene section below.

Eight days later the same campaign moved to PyPI, this time with an official Microsoft package as the carrier:

The durabletask compromise (May 19, 2026) hit Microsoft’s official Python SDK for Azure Durable Functions, a package with roughly 400K monthly downloads. The attacker pushed three malicious versions directly to PyPI inside a 35-minute window, with no matching tags or workflow runs in the GitHub repository. The release pipeline was bypassed entirely, which points to a stolen PYPI_API_TOKEN or a compromised maintainer account. The project did not use PyPI’s Trusted Publishing (OIDC). The injected dropper sits in __init__.py and only fires on Linux, so the real target is CI runners and cloud workloads rather than developer laptops. It pulls down a 28 KB modular framework that harvests credentials from AWS, Azure, GCP, Kubernetes, Vault, and the local password managers (Bitwarden, 1Password, pass, gopass), then propagates to additional hosts via aws ssm send-command and kubectl exec. Microsoft yanked the affected versions within about two hours of the first upload.

Two things to pull out of this one. First, an official Microsoft package, with hundreds of thousands of monthly downloads and a real maintenance team behind it, still shipped malicious releases for roughly two hours before being pulled. Brand and provenance buy you a faster takedown, not a safer package. The only reliable defense against a two-hour compromise window is not being inside it: a 7-day cooldown on PyPI updates would have kept consumers from ever resolving the compromised versions. Second, this is the textbook argument for PyPI’s Trusted Publishing on the publisher side. A long-lived PYPI_API_TOKEN is one secret an attacker can lift once and use forever, while an OIDC binding only authenticates uploads that actually originate from the configured CI/CD job, on the configured tag and workflow. If you maintain a PyPI package, this incident is the cue to migrate.

Stepping back, these incidents highlight a simple countermeasure that significantly reduces exposure to this attack mode: dependency cooldowns paired with immutable pinning where possible.

What are dependency cooldowns?

A dependency cooldown is exactly what it sounds like: a waiting period before your tooling accepts new package versions. Instead of immediately adopting version 1.2.4 when it’s published, you wait 5 to 10 days before considering it for your project.

This approach works because of simple economics. Attackers publishing malicious packages face a race against time. Registry security teams, automated malware scanners, and the security community are constantly scanning for suspicious packages. Most malicious packages get detected and removed within days, often hours. A 7-day cooldown means you never touch packages during their most dangerous period.

The math is compelling: if malicious packages are typically removed within 24–72 hours, even a 7-day cooldown gives you a comfortable safety margin. Organizations with cooldown policies during the Nx incident were simply never exposed since the malicious versions had been removed days before their pipelines would have considered them.

It’s important to be precise about what cooldowns solve: Cooldowns address version freshness risk, the risk of blindly adopting new, unvetted releases. They do not mitigate known vulnerability risk. Once a vulnerability is identified and a fix is published, the risk calculus flips: delay becomes the dangerous option.

From a business perspective, the Nx and Shai-Hulud incidents exposed thousands of build systems to credential theft. Even without assigning specific costs per compromised environment, incidents of this scale translate into massive organizational impact across response effort, recovery time, and long-term risk exposure. A cooldown policy costs nothing and would have prevented this entire class of attack.

Tool support

Several dependency management tools now support cooldowns natively:

Dependabot introduced the cooldown option in mid-2025, allowing you to specify minimum age requirements before version updates are proposed. You can configure different delays based on semantic version changes, with longer waits for major versions and shorter ones for patches. Dependabot’s cooldown applies only to routine version updates, not security updates, so CVE patches should still flow through promptly. See the Dependabot cooldown documentation for configuration details.

Teams should still periodically validate this behavior in their own repositories. Cooldown logic is applied at update runtime, and overly broad configuration or exclusions can silently suppress updates if not tested.

Renovate offers similar functionality through its minimumReleaseAge setting (previously called stabilityDays). Renovate creates branches for pending updates but marks them with a “pending” status check until the cooldown expires. If you have automerge enabled, updates won’t merge until they’ve aged sufficiently. A notable behavior change in Renovate 42: packages without a release timestamp are now treated as if they haven’t passed the cooldown period, which is safer than the previous behavior. The Renovate minimum release age documentation covers the configuration options.

In Renovate setups with broad package rules, security updates can still appear “pending” unless explicitly excluded from cooldown logic. For this reason, security-specific rules are strongly recommended.

pnpm added the minimum-release-age setting in version 10.16, which filters packages by publish date and automatically remaps dist-tags to versions that meet the age requirement. This preserves semantic version compatibility while enforcing your security delay.

For ecosystems without native cooldown support, lock files provide a manual alternative. Tools like Poetry, uv, or Go modules with go.sum pin exact versions, including transitive dependencies, so newly published releases are never pulled in implicitly. Even when updates are scheduled weekly or bi-weekly, the refresh is a conscious, explicit step: you update the lock file, review the diff, and only then accept newer versions. This creates a de-facto cooldown window, ensuring that dependencies must “age” until the next planned refresh instead of being adopted immediately after release. The key is treating dependency updates as a deliberate, reviewable activity rather than something that happens automatically in the background.

A common misconfiguration trap

One recurring failure mode I see in audits is teams enabling cooldowns, assuming they are “safe,” and then relaxing their active monitoring of security advisories. Cooldowns reduce exposure to unknown malicious releases. They do nothing for known vulnerabilities already present in your dependency tree.

Without active vulnerability alerting and triage, cooldowns can actually increase dwell time for exploitable CVEs. Cooldowns are a preventive control, not a detective one.

Transitive dependencies: the hidden risk

Here’s a point that’s easy to miss: cooldowns must effectively apply to your entire dependency graph, not just direct dependencies. A malicious package introduced as a transitive dependency can still reach production even if your direct imports are carefully curated.

Modern dependency update tools can account for this, when they are used with lockfiles and conservative update policies. Tools like Dependabot and Renovate operate on the resolved dependency graph, meaning updates (including transitives) are proposed via lockfile changes rather than silently flowing in. As long as lockfiles are committed and updates are gated, transitive dependencies won’t change unless you explicitly accept an update.

A dangerous anti-pattern is allowing floating transitive dependencies in production while only cooling down direct dependencies. This recreates the golden-hour problem one level down the graph, exactly where attackers increasingly aim.

If you rely on manual version pinning or ecosystems without strong lockfile enforcement, this safety net disappears. In those cases, you must regularly regenerate and review the full dependency graph (for example via mvn dependency:tree, pip-compile, or equivalent tooling) to detect unexpected transitive additions or version shifts.

Handling urgent security patches

Cooldowns work best when paired with an explicit security SLA, for example: critical dependency CVEs must be triaged within 24 hours and patched within 72.

Cooldowns should apply to routine updates, not emergency security patches. Dependabot explicitly excludes security updates from cooldown rules. Renovate allows you to force immediate updates for specific packages through its Dependency Dashboard or security-specific rules.

For emergency overrides, establish a clear process. The security team should approve bypasses with documented justification. Record all cooldown bypasses in your security log for audit purposes.

Such fast-tracked packages deserve additional scrutiny. Where feasible, perform manual or automated review of the delta: look for obfuscation, dynamic code execution, unexpected network access, or new persistence mechanisms. Once the normal cooldown period expires, re-verify that the package remains trustworthy.

What cooldowns don’t protect against

Let's be clear about the strengths and limitations.

Dependency cooldowns are effective against:

  • Compromised maintainer accounts with short-lived malicious releases
  • Automated malware injection and wormable release pipelines

They are not effective against:

  • Typosquatting attacks using similar package names
  • Long-term maintainer compromise
  • Zero-day vulnerabilities where fixes must be applied immediately

In other words: cooldowns buy you time, not certainty. Use that time to let scanners run, advisories surface, and the community react. Then decide from a position of information, not urgency.

Cooldowns are one layer in a defense-in-depth strategy. Combine them with SBOM generation, vulnerability scanning, code signing verification, and regular dependency audits. Yes, Trivy itself was compromised in March 2026. The irony isn’t lost on me. The scanner is still solid — the distribution channel was the problem, and pinning to commit SHAs would have prevented it:

Pinning to immutable references

As the Trivy incident showed, cooldowns don’t help when the attacker rewrites existing version references rather than publishing new ones. Git tags are mutable. Commit SHAs are not. The fix: pin GitHub Actions (and any Git-referenced dependency) to full commit SHAs instead of version tags.

Instead of: uses: some-org/some-action@v1 use full commit SHA: uses: some-org/some-action@28f2510ee396bbf400402947e7a9c4e3f7e3b144

It looks a bit ugly and that’s intentional. It forces an explicit, reviewable decision whenever something is updated. Modern dependency management tools can handle this by pinning to full commit SHAs while still enforcing cooldown periods and proposing updates when new versions are released, keeping the workflow manageable.

GitHub’s Immutable Releases feature helps, but it is not a substitute for pinning. In the Trivy incident, some artifacts were protected by immutable releases, while mutable tags in GitHub Actions were still force-pushed to malicious commits. Pin to the full SHA.

For npm, the lockfile integrity hashes (sha512-... in package-lock.json) provide a similar control: they bind installs to specific resolved artifacts. That’s why committing your lockfile and using npm ci matters. Preferring npm ci requires an existing lockfile, refuses to reconcile mismatches by rewriting it, and performs a frozen install. In practice, that prevents many silent drifts to newly published malicious versions (but only if the lockfile was already committed before the compromise).

Pin to content-addressed references wherever possible. Version tags, branch names, and semver ranges are all mutable indirections. Commit SHAs and integrity hashes are not.

IDE extensions: the developer-side blind spot

IDE extensions are dependencies. They just don’t show up in your package.json, pom.xml, requirements.txt, or go.mod, so nobody treats them that way. But a VS Code extension with workspace trust reads your files, sees your environment variables, and can reach locally stored credentials. Many have terminal and network permissions. And unlike your CI/CD dependencies, they update silently in the background — no pull request, no lockfile diff, no review step.

On May 18, 2026, the Nx Console VS Code extension — over 2.2 million installs, verified publisher (nrwl.angular-console) — was backdoored for 18 minutes. The trojanized version harvested credentials from 1Password vaults, Claude Code configs, npm tokens, GitHub tokens, and AWS keys. That breach spread to GitHub itself and TeamPCP exfiltrated roughly 3,800 of GitHub’s own internal repositories before the compromised version was pulled. The entry point: the Nx developer’s own account had been compromised via the earlier TanStack supply chain attack described above. A pull_request_target misconfiguration in one npm project cascaded into a backdoored popular IDE extension on many developer machines, and then to GitHub itself.

Eighteen minutes. That was the entire exposure window. “Verified publisher” meant nothing here — the legitimate publisher’s credentials were the weapon.

If you’ve been following the cooldown argument through this post, the pattern should feel familiar by now. If VS Code hadn’t auto-updated the moment the compromised version landed on the marketplace, nobody would have been exposed. The malicious release was pulled faster than most standups run. The only developers hit were the ones whose IDE silently adopted it in real time. Same golden-hour economics, different distribution channel.

Short-lived compromises aren’t the only threat model, though. Researchers linked the GlassWorm campaign to dozens of malicious or dormant Open VSX extensions beginning in late 2025, including sleeper packages that appeared benign before they later included malicious payloads after establishing trust. The Prettier-VSCode-Plus attack (November 2025) delivered multi-stage malware through a convincing Prettier clone. A cooldown catches both patterns: the delay gives scanners and the community time to flag problems before the extension ever reaches your machine.

Extension marketplaces also have weaker vetting than package registries. npm, PyPI, and crates.io run automated malware scanning and support Trusted Publishing flows. The VS Code Marketplace’s “verified publisher” badge confirms the publisher’s domain ownership — it says nothing about what the code in the .vsix actually does. Open VSX checks even less. The Checkmarx compromise I covered above hit their VS Code extensions on both marketplaces, and the repeat incident a month later showed that once a distribution channel is identified as a soft target, attackers come back. When a package registry and an extension marketplace both face supply chain pressure, the marketplace cracks first.

What to do about it
  • Disable automatic extension updates: In VS Code, set extensions.autoUpdate to false. JetBrains IDEs provide similar controls under Plugins. This is one of the highest-impact hardening changes you can make, but it also requires a process to review and approve updates manually. Otherwise, you may miss important security fixes that should be applied promptly.
  • Disable automatic extension update checks in high-trust environments: Set extensions.autoCheckUpdates to false to prevent VS Code from automatically advertising newly released extension versions before they have been reviewed and approved, since users may otherwise be tempted to simply click “Update” once the prompt appears.
  • Use extension allowlists: VS Code profiles and organizational policies let you restrict which extensions are permitted. If your team doesn’t need an extension, don’t install it.
  • Treat extension updates like dependency updates: Review changelogs, check release timing, wait a few days before accepting. The same 7-day rule of thumb works.
  • Diff your installed extensions: Run code --list-extensions --show-versions periodically and compare against a known-good baseline. Unexpected version bumps or new additions deserve investigation.

When token rotation isn’t enough

The Grafana case above illustrates a failure mode that no cooldown policy can save you from: you are the downstream consumer of somebody else’s compromised pipeline, you detect the cascade on day one, you rotate tokens — and you still miss one. From there, a single leftover credential is enough to keep the attacker inside your perimeter for days.

This pattern shows up again and again in public CI/CD incident write-ups Teams treat “rotate tokens” as a cleanup task rather than as an engineering problem with verification requirements.

A few practical implications
  • Inventory CI/CD identities the way you inventory production service accounts: Every workflow token, every OIDC trust binding, every deploy credential needs an owner, a scope, and an expiry. If you cannot enumerate them on demand, you cannot rotate them on demand either.
  • Make “rotate” a playbook with a verification step: After rotation, run a canary job that attempts to use the old credential set against the repositories, registries, and cloud accounts it previously had access to. The job should fail closed. If it succeeds, the rotation isn’t done.
  • Reduce blast radius at the workflow boundary: PR-validation workflows should not be able to write caches that release pipelines later consume. Avoid pull_request_target unless you fully isolate the fork checkout and lock down permissions for the elevated context. This is the same upstream lesson the TanStack incident hammered home from the maintainer side; here it shows up as a downstream control.
  • Add egress controls on runners: If runners can only reach explicitly approved destinations — for example your artifact store, registry proxy, and required cloud identity endpoints — generic exfiltration becomes meaningfully harder, and stolen OIDC material is less useful unless the attacker can also reach a permitted token-exchange or deployment target.

Cooldowns, pinning, IDE extension hygiene, and identity hygiene are stacked controls for different failure modes. Cooldowns keep you out of compromised upstream windows. Pinning blunts tag-rewrite attacks. A verified rotation playbook is what saves you when somebody else’s pipeline already failed and the cascade reached you anyway.

For more practical tips on locking down your supply chain and secure build pipelines, see my post about how to ship fast, but guard faster: securing DevOps itself.

Getting started today

Rule of thumb: Delay unknown updates by default, fast-track known security fixes deliberately.

If you take nothing else from this post, implement a 7-day cooldown on your automated CI/CD dependency updates and IDE extension updates this week. The configuration is minimal, the protection is immediate, and the risk reduction is real.

For teams worried about being “slowed down”: you’re likely already waiting days or weeks between dependency updates in practice. Cooldowns simply formalize this delay and make sure it applies consistently, including on that one rushed Friday afternoon deploy.

Attackers are counting on you to adopt their malicious packages immediately. Make them wait.



If this resonated...
I help teams lock down their CI/CD pipelines, from dependency policies to build integrity. More info: DevSecOps Pipeline Consulting.