Writing

Claude Code Caught a Supply Chain Attack Before I Even Finished My Coffee

A malicious litellm package hit PyPI. I needed to know if our production systems were compromised. Claude Code figured it out in 5 minutes. The same investigation would've taken me hours.

Cover image for Claude Code Caught a Supply Chain Attack Before I Even Finished My Coffee

I woke up to a link about a supply chain attack on litellm — a package we use in production.

Someone had uploaded malicious versions (1.82.7 and 1.82.8) to PyPI. The payload harvested SSH keys, AWS credentials, .env files, Kubernetes configs — basically everything you don’t want leaving your machine. It encrypted the stolen data and shipped it off to a fake domain. It even tried to deploy backdoor pods in your Kubernetes cluster.

And here’s the fun part: it used a .pth file. That means it ran on every Python process startup, not just when you import litellm. You didn’t even have to use the package directly. Just having it installed was enough.

We use litellm through Google ADK’s wrapper — google.adk.models.lite_llm.LiteLlm. No direct imports. But that wouldn’t have saved us.

The Old Way

14 years in software engineering, and I know exactly how this investigation usually goes:

  1. Read the advisory. Understand the attack vector.
  2. Check requirements.txt. Is the version pinned? (It wasn’t. Ours just said litellm — no version.)
  3. Check if there’s a lock file. (There wasn’t.)
  4. Look at the CI/CD history. Did any deployment happen during the attack window?
  5. SSH into running containers. Check the installed version. Hunt for IOCs.
  6. Cross-reference deployment timestamps with the attack timeline.

That’s half a day, minimum. More if you’re digging through CloudWatch logs and Docker layer caches.

The New Way

I pasted the advisory URL into Claude Code and said: check if we’re affected.

That’s it. One prompt.

Claude read the article and extracted every detail — the affected versions, the malicious .pth file, the persistence artifacts, the exfiltration domain, the IOCs. At the same time, it explored our ai-agents-litellm codebase and mapped out exactly how we use litellm, which files import it, and the fact that our requirements.txt had it unpinned.

Then it checked for indicators of compromise on my local machine — searched for litellm_init.pth, checked ~/.config/sysmon/sysmon.py, looked for rogue systemd services. All clean.

But the real question was: did any of our deployments pull the bad version?

I told Claude our deployments are all GitHub Actions to ECS. It pulled the workflow run history using gh, mapped every deployment timestamp against the attack window (March 24, 10:52 UTC to 20:15 UTC), and found:

Then it went one step further — pulled the actual build logs from the March 26 QA deploy and confirmed the installed version:

Downloading litellm-1.82.6-py3-none-any.whl

1.82.6. The last safe version. The malicious ones had already been yanked from PyPI by the time our next deployment ran.

We were clean. Five minutes. No SSH-ing into containers. No log diving. No spreadsheet of timestamps.

Why This Matters

I’m not writing this to say “AI is cool.” I’m writing this because supply chain attacks don’t give you time.

The malicious litellm versions were live on PyPI for about 9.5 hours. If our deploy schedule had been 4 hours different, we’d have compromised containers running in staging and production, silently exfiltrating credentials.

The speed of investigation matters. When a CVE drops or a package gets hijacked, the clock is already running. Every hour you spend manually checking is an hour your systems might be leaking.

Claude Code collapsed what would’ve been hours of forensic work into a single conversation. Read the advisory, scan the repo, check CI/CD history, verify build logs, report findings — all in one shot.

The Lesson I’m Taking Away

Pin your dependencies. We had litellm with no version constraint. We got lucky because of timing. That’s not a strategy.

But beyond that — if you’re not using AI tooling for incident response and security triage, you’re leaving speed on the table. The bottleneck in security incidents has always been investigation time. That bottleneck just got a lot smaller.

Interested in AI-assisted development and security workflows?

If you’re building with Claude Code or exploring how AI can fit into your engineering processes, I’m happy to chat.

-> Book a tech consultation

Back to writing