Every Supply Chain Attack of June and July 2026 Was After the Same Thing

Eight weeks. Nine notable incidents. Let me put them in one place, because the pattern only becomes obvious when you do.

Ten rows, if you count the mitigation. Ten completely different technical entry points: a Python startup file, a JavaScript CDN tag, a phone call to a contractor, an edit-distance package name, a compromised npm token, a GitHub Actions trigger, a dataset loader, a marketplace extension.

Now read GitGuardian's conclusion about the four npm/PyPI campaigns: all of them "targeted credentials sitting in developer environments and build pipelines."

Extend that across the whole table and it holds:

• Hugging Face: harvested cloud and cluster credentials from a processing worker
• AsyncAPI: stole the asyncapi-bot PAT
• jscrambler: cloud credentials, npm/GitHub tokens, AI assistant credential stores
• Payment SDKs: AWS_SECRET_ACCESS_KEY, GITHUB_TOKEN, NPM_TOKEN, by name
• PyPI worm: registry credentials, then self-spread using them
• Nx Console: workstation credentials reaching internal repositories
• AdaptHealth: a live session
• Polymarket / Medtronic: inherited vendor trust

Nine vectors. One prize.

Why this reframing matters

The security industry organises itself around vectors. There is a product for dependency scanning, a product for CI/CD security, a product for IDE extension governance, a product for TPRM, a product for AI supply chain. Each is sold against a column in that table.

The problem is that the attacker is optimising against the prize, not the column. When npm v12 closed install scripts on 8 July, the campaigns did not stop — they moved to import-time execution within three days. When you close one column, the prize is unchanged and the next column is cheaper.

A vector-oriented defence has to win every column, forever. A prize-oriented defence has to win once.

The prize, concretely

Here is the configuration nearly every organisation runs by default:

Long-lived credentials, injected as environment variables, resident for the full duration of every job, available to every line of every dependency that executes.

Your CI runner has AWS_SECRET_ACCESS_KEY in its environment from second zero to job end. Your npm ci step has it. Your TypeScript compile has it. Your linter has it. Your 1,400 transitive dependencies have it, because they run in that process, in that environment.

The same is true of the developer workstation: ~/.aws/credentials, ~/.ssh/id_ed25519, .env files, a git credential helper with a PAT, ~/.npmrc with a publishing token, and now an AI assistant config directory holding API keys and MCP server credentials.

None of that needs to be there. A step that compiles TypeScript does not need production cloud credentials. It has them because the pipeline was written years ago and nobody revisited it, and because scoping secrets per-step is more work than scoping them per-job.

That gap — between the access a step needs and the access it has — is the entire prize. Every incident in the table above monetised it.

What "fixing the prize" actually means

Four properties, in rough order of leverage:

1. No standing credentials. Secrets brokered just-in-time, scoped to the step, expiring in minutes. A payload that gets code execution and sweeps process.env finds nothing worth having. This is the single highest-leverage change available in software supply chain security today, and it is dramatically under-deployed relative to how much scanning organisations buy.

2. Egress allowlists on build and developer environments. Execution without exfiltration is a much smaller problem. Every payload in that table needed to reach an attacker-controlled destination — IPFS, a paste service, a GitHub repo, an Ethereum contract, a C2 host. That is the narrowest point in the entire kill chain and almost nobody constrains it.

3. Capability scoping. An ingestion worker that cannot reach the cluster API. A build step that cannot reach production. An AI agent whose tool surface is bounded and declared rather than accumulated.

4. Signed audit trails. When an autonomous agent framework executes thousands of actions across ephemeral sandboxes — as at Hugging Face — the difference between an incident report and a mystery is whether those actions were recorded in a form you can review.

Notice what is not on that list: knowing which vector was used. All four properties hold regardless.

The agentic accelerant

One more thing changed in this window, and it is the reason the pattern will intensify rather than plateau.

The Hugging Face intrusion was driven by "an autonomous agent framework… executing many thousands of individual actions across a swarm of short-lived sandboxes, with self-migrating command-and-control staged on public services." Whatever the attribution, that is the new cost curve for offence: probing that used to require a patient human now runs unattended through a weekend.

And on the defender's side, the credential surface is growing at the same time, because AI coding assistants are now standard developer tooling — each holding API keys, OAuth tokens, and MCP configurations that constitute a pre-authorised agent with a tool surface someone already wired to your repositories and cloud. That is why jscrambler went looking for Claude Desktop, Cursor, and Windsurf credential stores specifically.

More attempts, against a larger and more valuable credential surface. The direction is not ambiguous.

How Safeguard helps, at scale

We built Safeguard around the prize rather than the vectors, and this is the clearest way to explain what that means in practice.

Lion is the answer to the prize. Lion is a 1B governance model that runs alongside every AI coding agent and build process, enforcing exactly the four properties above: just-in-time secret brokering instead of resident long-lived credentials, capability scoping so a step or agent reaches only what it was granted, egress allowlists so exfiltration fails at the narrowest point in the kill chain, and signed audit trails so thousands of agent actions produce a reviewable record. Deploy that across a fleet of thousands of CI runners and developer environments and every row of that table becomes materially less profitable — without needing to have predicted which row was next.

The Supply Chain Core covers all the vectors anyway, under one policy. Eleven scanners across npm, PyPI, containers, IaC, models, datasets, MCP servers, and IDE extensions, with behavioural version-over-version deltas so a malicious publish is caught before a CVE exists. One engine, one policy, one inventory — which is the only configuration that matches an attacker running shared payloads across ecosystems.

Continuous SBOMs that answer the day-one question. Per-release CycloneDX and SPDX, VEX statements, and SLSA provenance across every repo and release. When the next compromise breaks, "are we affected, where, and through which transitive path" is a query, not a two-week archaeology project. That is what a four-hour exposure window like AsyncAPI's demands.

500K+ pre-vetted zero-CVE components. For the strongest posture: do not reach the compromised version at all. This closes the publish-to-detection window that every registry campaign lives inside.

Eagle for the triage crush. Reasoning over EPSS, KEV, exploit databases and live telemetry to cut false positives by roughly 80% and compress remediation from 45 days to 3. At org scale, nobody is short of findings — they are short of the ordering.

Griffin for the fix. Walks the dependency graph 100 layers deep with reachability and taint analysis, then authors and tests the fix PR through your existing merge gates. Five variants from Griffin Lite (8B) to Griffin Zero (671B-MoE), including sovereign and air-gapped deployment. Across hundreds of affected repositories, autonomous remediation is what converts a quarter of work into a review queue — 100K+ autonomous remediations applied to date, against 50+ coordinated-disclosed zero-days and 1M+ scans.

Deployment that fits regulated reality. SaaS, private cloud, or sovereign / air-gapped, with FedRAMP HIGH-ready and IL7-ready posture and SOC 2 Type II in audit.

If you do one thing after reading this, do not go and audit your pull_request_target workflows — though you should. Go and find out how long the credentials in your CI environment live, and which steps can read them.

That is the number the attackers are optimising against.

Sources: GitGuardian: Four More Supply Chain Attacks Hit npm and PyPI · Hugging Face security incident disclosure · Veracode: Supply Chain Compromises from June and July 2026 · CISA Alert on Nx Console · Unit 42: The npm Threat Landscape