March's Supply Chain Wave Targeted the Tools That Hold the Keys
March 2026 produced an unusually dense run of software supply chain compromises. Taken one at a time, each looked like a familiar story: a maintainer account or publishing token was taken over, and malicious versions were pushed to a registry. Taken together, they show attackers choosing targets with care.
What happened
Security scanners. A group researchers track as TeamPCP was linked to compromises affecting distribution channels for open-source security scanning tools, including the widely used Trivy vulnerability scanner and an infrastructure-as-code scanner. These tools run inside CI/CD pipelines, often with access to cloud credentials and container registries.
An AI gateway library. On March 24, two malicious versions of LiteLLM, a popular Python library that routes requests to many AI model providers, were published to PyPI and stayed available for a few hours before being quarantined. One version ran its payload whenever Python started, through a .pth file; the other ran on import. Public analyses linked this to the same group and described payloads aimed at cloud tokens, SSH keys and Kubernetes credentials.
A ubiquitous HTTP client. On March 30 and 31, attackers took over the npm account of the lead maintainer of Axios, a JavaScript HTTP client with enormous usage, and published two malicious versions that pulled in a dependency with an install-time script. Researchers described the payload as a cross-platform remote access trojan dropper, and at least one analysis attributed the activity to a North Korean actor.
The malicious versions were live for only a few hours. With dependencies this widely used, hours are enough.
Why these targets
Look at where each tool runs:
- Security scanners run in build pipelines, often with permission to read source code, pull and push images, and access cloud accounts.
- AI gateway libraries run wherever applications call models, and they typically hold API keys for several model providers. Those keys are valuable on their own and often sit next to other cloud credentials.
- HTTP clients run nearly everywhere: developer laptops, build systems, servers and serverless functions.
Each is a place where a payload is likely to find credentials. The libraries were the delivery route. The credentials beside them were the prize.
There’s an uncomfortable irony in security tooling becoming an entry point. Teams add scanners to pipelines to reduce risk, and give them broad access because scanning needs to see everything. That access makes them attractive.
What to do
The lessons from last September’s npm worm still apply, and we covered them in detail in Self-Replicating Packages. March adds a few specific points.
Treat security and AI tooling as privileged software. Inventory where scanners, AI SDKs and gateway libraries run, what credentials are available to them, and how they’re updated. Apply the same scrutiny you’d apply to an identity provider agent.
Pin actions and tools by digest, not by tag. CI systems that reference a third-party action or container image by a mutable tag will pick up whatever is published under that tag. Pinning to an immutable digest, and updating deliberately, prevents silent substitution.
Delay adoption of new versions. A short cooling-off period, even a few days, before new dependency versions reach builds would have avoided exposure to every malicious release this month. Most dependency management tools can enforce it.
Narrow what builds can reach. Use short-lived, narrowly scoped credentials issued per job. A scanning step shouldn’t hold credentials that can deploy to production.
Separate AI provider keys. Keep model provider API keys out of general-purpose environments, scope them per application, set spending limits and monitor usage. Unexpected usage is often the first sign a key has leaked.
If you were exposed
Identify builds and systems that installed the affected versions during the exposure windows, using lockfiles and build logs. Rotate every credential that was present in those environments, including any the published analyses don’t mention. Review cloud and repository audit logs for activity from those credentials since the exposure.
Looking ahead
Attackers have learned that the fastest route to many organizations’ cloud credentials runs through the tools developers and security teams trust most. Organizations that know where those tools run and limit what they can reach will be able to absorb the next compromise as a routine rotation exercise rather than an investigation.