Skip to main content

Rebuild a compromised package (internal supply chain)

In March 2026 litellm==1.82.7 and 1.82.8 shipped to PyPI with a credential stealer hidden in a .pth file that executed on every Python interpreter start. No import litellm required. The structural fix isn't "pin harder" — it's stop trusting the public artifact: fork the source you've reviewed, build it yourself, and prove every step.

This session is a real, unedited Claude Code run. The developer asks Claude to stand up that internal supply chain; Claude drives the real cilock CLI and the Linux kernel does the rest.

Loading recorded terminal session…

What it does, step by step​

The recording is the script — here's what each step proves.

  1. Snapshot the source. cilock run --step source --capture-mode walk records a signed material tree (Merkle root) of the forked LiteLLM source. That digest is now the trusted source of record.
  2. Build under tracing. cilock run --step build --trace -- uv build --wheel wraps the wheel build. --trace captures kernel-side — eBPF in this recording, with automatic ptrace+seccomp fallback where eBPF can't load — recording what the build read (≈2,778 source materials in) and wrote (the wheel out): SLSA-style build provenance linking inputs to the output, signed.
  3. Scan the source. cilock run --step scan --trace -- trivy fs … wraps a Trivy vulnerability scan, also under eBPF.
  4. Read the policy. The signed Witness policy is shown on screen — its approved-internal-fork Rego rule requires the build's git remote to be the approved fork, never PyPI.
  5. Verify the chain. cilock verify checks the source, build, and scan attestations against the policy, anchored on the wheel's product-tree digest → Verification succeeded. See policy verification.
  6. Install under eBPF. cilock run --step install --trace -- pip install … captures exactly what installation touches — and confirms zero .pth files were written and zero network egress occurred (the opposite of the compromised artifact).
  7. Show the egress. A kernel-level network summary: the build and install made zero outbound connections, while CI/lock even caught Trivy itself doing DNS + a TLS connect during the scan — you see your own tools' egress, not just your code's.
  8. Use it. The verified wheel is installed into the team's service and called — running from the internal supply chain, never PyPI.

Every artifact is a signed DSSE + in-toto envelope; nothing in the recording is faked.

Swap in the tools you use​

The scan and build steps wrap any command, so the same shape works with the scanner and packager your team already runs:

Why it matters​

A pin protects you from a different artifact; it does nothing when the artifact you pinned to is itself malicious. Building from reviewed source under kernel-level tracing, then gating on a signed policy, turns "trust PyPI" into "verify our own evidence." The same evidence model carries through scan, install, and runtime — one spine, many checkpoints.