Package managers used to feel like developer plumbing. In 2026 they are the front line of data loss. A compromised maintainer, a typo-squatted package, or a fresh dependency with a hostile postinstall script can read secrets, call home, and poison CI long before an advisory scanner, ticket queue, or manual approval workflow notices.
That is why Supply-Chain Guard is one of RRR's Agentic DLP proof pillars, alongside Autonomous Trust Scoring and Account-Aware Enforcement. DLP cannot stop at browser prompts. AI coding agents, CI runners, local CLIs, package managers, and model installers all move data and credentials. The control has to live where the install happens.
RRR intercepts npm and PyPI registry traffic through the local OS agent, checks signed malicious-version verdicts, applies org policy, and correlates package fetches with postinstall child processes, network egress, and sensitive file reads. One timeline, one decision.
What we have seen in the wild
The pattern across the last twelve months is consistent: attackers compromise maintainer accounts or registry tokens, publish a backdoored version of a popular package, and rely on the install happening on thousands of developer laptops and CI runners within minutes. Some highlights.
Shai-Hulud: a self-propagating npm worm
Shai-Hulud is a self-propagating supply chain worm that has compromised 800+ npm packages, expanded to PyPI, and hit organisations including TanStack, Mistral AI, and UiPath. In May 2026 the loader was published openly on GitHub, so anyone can fork it, retarget it, and ship a new variant in an afternoon. Detection strategies that depend on recognising one specific malware family lost the game the day the source code went public. (Sources: JFrog Security Research, Stream Security, Phoenix Security.)
Mini Shai-Hulud and the Sigstore problem
Between April 29 and May 11, 2026, the smaller variant tracked as
Mini Shai-Hulud (CVE-2026-45321, CVSS 9.6) compromised more than
170 packages across npm and PyPI, including the entire @tanstack/*
namespace, large parts of @uipath/*, Mistral AI's TypeScript and Python SDKs, and
the Guardrails AI Python package. The worm's most uncomfortable trick was not the payload, it was
that several malicious versions were published with valid Sigstore provenance
attestations. The signature said "built by the legitimate workflow" because the worm
had already taken over the legitimate workflow. Provenance is necessary. It is not sufficient.
(Sources: Tenable Research Special Operations, Cloud Security Alliance AI Safety Initiative,
SAND Security, Snyk advisory.)
TrapDoor: one campaign, three ecosystems
In May 2026, Socket published the TrapDoor crypto-stealer campaign: 36 malicious packages and hundreds of versions across npm, PyPI, and crates.io, all aimed at developers in crypto, DeFi, Solana, and AI tooling. The packages chained pre-install and postinstall hooks across language ecosystems to harvest wallet keys, cloud credentials, and AI provider tokens from a single install. A scanner that looks at only npm misses two thirds of this attack. (Sources: Socket Research, Rescana.)
num2words and the long tail
In July 2025, the popular num2words PyPI package was compromised and pushed version
0.5.15 distributing Scavenger malware. The package has tens of
millions of downloads. Every CI runner that resolved an unpinned version that morning ran the
payload before any advisory existed. This is the boring, recurring middle of the distribution:
not a worm, not a coordinated campaign, just one compromised maintainer and a global blast
radius. (Source: Invoke RE.)
The trend: polymorphism and persistence
Recent variants mutate per install, drop persistence agents that survive lockfile pinning, and re-publish themselves from the victim's own maintainer credentials. Static IOC lists age out in hours. The only durable control is one that reasons about identity, behaviour, and process lineage at install time, not at scan time. (Source: Phoenix Security technical dissection.)
Why advisory-only scanners miss the first install
Traditional dependency tools are useful, but most are advisory. They scan after a lockfile changes, after a pull request opens, or after a database learns about the incident. That leaves a gap during the exact moment attackers care about: the first install of the bad version on a developer laptop or build runner.
Modern install paths also bypass the clean boundaries older tools assume. A package install may
be triggered by a human, an AI coding assistant, a bootstrap script, a GitHub Action, or a
transient CI container. If a postinstall script reads ~/.npmrc, touches cloud
credentials, or opens a network connection, the package registry proxy alone cannot tell you
which process did it, on whose behalf, or for which repository.
| Era | What it caught | Where it breaks in 2026 |
|---|---|---|
| SCA 1.0 | Known CVEs in lockfiles, post-merge | Day-zero compromised versions, postinstall malware |
| SCA 2.0 | PR-time policy and signature checks | Local npm install, AI agents, CI runners outside the PR flow |
| Supply-Chain Guard | Inline verdicts plus postinstall behaviour, on every endpoint and runner | – |
Why provenance is necessary but not sufficient
Sigstore, SLSA, and npm provenance attestations are real progress. They tie a build artifact to a verifiable workflow and let consumers reject unsigned versions. The Mini Shai-Hulud campaign showed the limit: if the attacker controls the workflow, the attestation is genuine. The chain of custody is intact. The package is still malicious.
Provenance answers "was this built where the maintainer says it was built." Supply-Chain Guard answers a different question at install time: "given this package, this version, this signed verdict snapshot, this developer or runner, and what this install actually does on the host in the next sixty seconds, should we let it proceed?"
What Supply-Chain Guard adds
| # | Capability | What it answers |
|---|---|---|
| 1 | Inline verdicts | Is this specific package and version on a signed malicious list, before bytes hit disk? |
| 2 | Process provenance | Which install session spawned this process, and is it inside the risky postinstall window? |
| 3 | CI identity | Which repository, workflow, run, job, commit, and ref ran this install, instead of a fake developer user? |
The agent does not host a private registry mirror and it does not rewrite lockfiles. It uses the local TLS inspection path already present in the OS agent. The control ships without a new proxy fleet, hosts-file rewrites, or package-manager-specific network configuration.
The decision path
Every package fetch is reduced to a canonical identity. npm scoped packages keep their
@scope/name form. PyPI names follow normalised package-name semantics. Private
registries are represented by configured aliases, not full private URLs.
package request -> canonical ecosystem/name/version -> signed malicious-version verdict snapshot -> org policy and allowlist -> monitor, warn, block, or allow + telemetry
Verdict snapshots are signed server-side and refreshed on a cadence the agent can validate offline. The agent rejects missing or invalid signatures and follows fail-open defaults for monitor mode, stale caches, parser failures, and unavailable attribution. Block mode is reserved for high-confidence verdicts or explicit org policy matches.
The part a proxy alone cannot do
Registry gating is half of the problem. The more important question is what happens after install. Supply-Chain Guard tags package-manager sessions and applies elevated scrutiny to descendants during the risky postinstall window.
- Outbound network calls become high-severity
postinstall_network_callevents with the originating package, version, and process tree. - Reads of sensitive paths such as
~/.aws/,~/.ssh/,~/.npmrc,~/.config/gh/, and browser credential stores becomepostinstall_sensitive_file_accessevents where platform support exists. - The Package Activity dashboard renders one timeline from fetch to spawn to network and file behaviour, per endpoint and per CI runner.
v1 is intentionally conservative. It records suspicious postinstall behaviour and does not run uninstall or rollback commands. Platform-level kill or deny is enabled only when the platform adapter can prove a safe enforcement primitive.
CI runners: kill the "fake developer user"
Most supply-chain incidents in 2025 and 2026 were detected on CI runners, then attributed to
whichever service account the runner happened to use. That gives security teams a useless audit
trail: every malicious install looks like it came from github-actions[bot] or a
generic build user.
Supply-Chain Guard binds every runner-side install to repository, workflow, run, job,
commit, and ref, sourced from the runner's environment and verified against the
configured CI provider. When a postinstall script exfiltrates a token, the alert says
"acme/payments, release.yml, commit 4f1a…, job
publish," not "the build user did a thing." That is the difference between a
five-minute rollback and a five-day incident.
Monitor first, then enforce
Supply-chain controls need a rollout path. RRR starts in monitor mode so teams can build an observed package inventory, learn private registry aliases, and tune allowlists before blocking. Business-tier organisations can move to warn or block. Free and Professional organisations stay monitor-only; Free package telemetry is retained for seven days.
That split is deliberate. Everyone should be able to see package risk. Enforcement should be turned on only when the organisation is ready to own bypass workflows, incident review, and CI build-failure behaviour.
Where this fits in RRR's three Agentic DLP pillars
RRR's category is Agentic DLP: DLP on autopilot for humans, non-humans, and AI agents, at AI speed. Three pillars prove it.
- Autonomous Trust Scoring decides which vendors, models, and agents are even allowed in the conversation.
- Account-Aware Enforcement applies the right policy to the right identity, including non-human and agent identities, at the moment of action.
- Supply-Chain Guard closes the install path: the moment a developer tool, AI coding agent, or CI runner pulls an artifact from a public registry.
None of the three works alone. Trust scoring without enforcement is a dashboard. Enforcement without supply-chain coverage misses the install. Supply-Chain Guard without identity-aware policy is a louder version of an SCA scanner.
What to do this week
| # | Action | Why it matters |
|---|---|---|
| 1 | Inventory every installer | List every endpoint and CI runner that can call npm, pnpm, yarn, pip, uv, or poetry. That is your real attack surface. |
| 2 | Turn on monitor mode | You cannot tune policy you have never observed. Two weeks of telemetry beats two months of debate. |
| 3 | Map CI identity | Confirm runners report repository, workflow, run, job, commit, and ref. Anything still showing a generic bot user is a blind spot. |
| 4 | Decide bypass owners | Before enforcement, name who approves a bypass and how long it lasts. This is the single biggest predictor of whether block mode survives contact with engineering. |
The practical win is simple. Security sees the package, version, decision, endpoint, runner, process, and postinstall behaviour in one place. Developers get a readable block reason and a bypass path when policy allows it. CI gets repository-native attribution instead of a fake developer user. And the next Shai-Hulud variant, the one that does not exist yet, meets a control built for the install, not for the advisory.
The implementation guide covers policy sync, verdict snapshots, CI runner mode, privacy boundaries, and the current platform capability matrix. Read the Supply-Chain Guard docs →
