AI Library Supply-Chain Defense Kit

1. python3 supply_chain_check.py --selftest prints selftest ok.
2. python3 supply_chain_check.py path/to/repo lists unpinned AI libraries, missing hashes and undigested images, then exits 1 if any blocker exists.
3. On a host you suspect, run python3 supply_chain_check.py --site-packages $(python3 -c 'import sysconfig;print(sysconfig.get_paths()["purelib"])') from a clean interpreter or a mounted copy (see 01, step 1: starting Python in an affected environment re-runs the payload).
4. Add new advisories to bad_versions.csv and re-run.
5. Dashboard: add --afk-json to any command above and save the output as results/supply-chain.json; load it in the Agent Cyber Defense Dashboard. Python 3.9+, no installs. Read-only: nothing is changed, sent or uploaded.

Oct 2026 update (section 04)

• [ ] --site check run in every virtualenv and image, as the agent's own user.
• [ ] Every warn traced to an installed package (or treated as a block).
• [ ] Freeze-on-vendor-pause and trust_remote_code rules added to your policy.

Oct 21 incident response: poisoned litellm 1.107.0

Facts we rely on (Oct 21, 2026; wording follows the sources)

• Railway says an unauthorized party may have accessed encrypted environment variables and, for some, obtained decrypted contents. It believes this is part of a series of attacks targeting platform companies to compromise AI inference providers, and notified upstream providers to revoke keys. It recommends all users roll every variable and private registry credential and review logs. (https://blog.railway.com/p/security-disclosure-wednesday-october-21st)
• Railway later reset bucket S3 credentials and the GitHub tokens it held, and invalidated all Railway API tokens. GitHub tokens stored as registry credentials still work on GitHub until you revoke them. (https://blog.railway.com/p/security-disclosure-recommendation-redeploy-buckets-and-reconnect-github-after-the-credential-reset, https://status.railway.com/incident/QH8L8B3E)
• Railway published provider-specific guides to check for unexpected Anthropic and xAI (Grok) usage. (https://blog.railway.com/p/security-disclosure-recommendation-check-for-unexpected-anthropic-usage, https://blog.railway.com/p/security-disclosure-recommendation-check-for-unexpected-grok-usage)
• LiteLLM says its release pipeline was compromised and litellm==1.107.0 (PyPI, 11:39-13:23 UTC) plus Docker/GHCR tags v1.107.0, latest, main-latest, main-stable (from 11:46 UTC) contained credential-stealing malware. The attacker used leaked developer GitHub CLI OAuth tokens found in logs of an internal deployment. (https://docs.litellm.ai/blog/security-incident-oct-21-2026, https://osv.dev/vulnerability/MAL-2026-2144)

Am I affected?

You are in scope if, on Oct 21 2026, you ran pip install litellm without a pin between 11:39 and 13:23 UTC, or pulled litellm images tagged v1.107.0, latest, main-latest or main-stable from 11:46 UTC (Docker Hub until 14:20, GHCR until about 13:51). Check every place that installs it: laptops, CI runners, images, notebooks, agent sandboxes. (https://docs.litellm.ai/blog/security-incident-oct-21-2026)

Steps (in this order)

1. Do not start Python in the suspect environment, including pip. LiteLLM says the payload re-runs on interpreter start. Inspect from a shell or a mounted copy.
2. Look for litellm-1.107.0.dist-info, cook.pth, cook.py, sitecustomize.py (the kit script does this). Absence does not prove you are clean.
3. Remove the files LiteLLM lists, stop the detached process that holds /tmp/remote_code_loader.lock, then rebuild the venv or image from scratch pinned to a known-good version (LiteLLM names 1.106.2).
4. If the host had outbound internet, assume credentials left. Rotate what it could reach: cloud instance roles, every provider key in the proxy DB, master and virtual keys, the database password, every env secret. Use the Secrets Exposure & Rotation kit's inventory.
5. In cloud audit logs, look for identity calls (for AWS, GetCallerIdentity) near install time and any later use of those credentials from outside your network.
6. Record times, hosts and rotations in your incident record. Pin everything (policy 02) before you resume upgrades.