Your package was compromised. How do you prove which version you actually shipped?

Jonna Fassbender — Mon, 30 Mar 2026 17:27:18 +0000

Last week, LiteLLM got owned.

Not the company. Not the code. The publishing pipeline. An attacker compromised a vulnerability scanner in their CI/CD, used it to grab PyPI credentials, and pushed a malicious version that stole API keys from every engineer who installed it.

Three days later, the same thing happened to Telnyx.

If you work with AI, you probably had LiteLLM installed. The question isn't whether you were affected. It's whether you can prove what version you were running, and when.

The real problem isn't the hack

Supply chain attacks aren't new. SolarWinds. Codecov. ua-parser-js. The pattern is always the same: something between the developer and the user gets compromised.

What's new is the response problem.

When LiteLLM was hit, every team using it had to answer: "Were we running the compromised version?" Most couldn't answer with certainty because their evidence came from the same systems that were potentially compromised.

Your CI logs live in your CI. Your registry timestamps come from the registry. Your internal records are... internal.

The system under dispute is also the source of the evidence. That's not proof.

What anchoring does

Anchoring creates a cryptographic fingerprint of your artifact (a package, a model, a build) and timestamps it in Bitcoin's blockchain. Not a copy. Not a backup. A mathematical proof that this exact artifact existed at this exact moment.

artifact.whl (your package)
    ↓ SHA-256
a]7c3f9e...  (fingerprint)
    ↓ anchor
origin_id: ec8eead9-...  (your proof)
    ↓ Bitcoin
anchored to Bitcoin block 889,412

The proof is independently verifiable. It doesn't depend on Umarise, your CI provider, or any single system staying honest.

What this looks like in practice

In your build pipeline (one line):

umarise anchor dist/package-1.2.0.whl

In GitHub Actions:

- name: Anchor build artifact
  uses: AnchoringTrust/anchor-action@v1
  with:
    file: dist/package-1.2.0.whl
  env:
    UMARISE_API_KEY: {% raw %}${{ secrets.UMARISE_API_KEY }}{% endraw %}

In Python:

import hashlib
from umarise import UmariseCore

with open("dist/package-1.2.0.whl", "rb") as f:
    sha256 = "sha256:" + hashlib.sha256(f.read()).hexdigest()

client = UmariseCore(api_key="um_...")
result = client.attest(hash_value=sha256)
print(result.origin_id)

That's it. One call. The proof is permanent.

The timeline that matters

Here's what the LiteLLM attack looked like, and what changes with anchoring:

Day 0: Team publishes litellm 1.52.6 (legitimate)
       → Without anchoring: version exists on PyPI
       → With anchoring: SHA-256 fingerprint anchored to Bitcoin

Day 3: Attacker compromises CI vulnerability scanner
       → Attacker extracts PyPI credentials
       → Pushes malicious litellm 1.52.7

Day 4: Malicious version steals API keys from .env files
       → 1000+ engineers affected

Day 6: Attack discovered, version yanked

Day 7: Incident response begins
       → Without anchoring: "Our logs say we had 1.52.6"
       → With anchoring: "Here's the Bitcoin-anchored proof
         of exactly what we were running"

The difference: one is a claim. The other is a proof that anyone can verify, independently, forever.

Why this matters for your team

You don't need to have been hit by LiteLLM to care about this. Ask yourself:

Can you prove which version of a dependency you deployed last Tuesday?
If your CI provider gets compromised, does your evidence survive?
If a regulator asks for proof of what was in production, can you provide something that doesn't come from your own systems?

Most teams answer no to all three.

The pattern is bigger than packages

The LiteLLM attack targeted a Python package. But the same vulnerability exists everywhere artifacts move through a pipeline:

ML models: Can you prove which weights were in production when a decision was made?
Training data: Can you prove the dataset wasn't modified after the audit?
Docker images: Can you prove the image that ran in prod matches what was built?
Firmware: Can you prove the binary that shipped is the binary that was signed?

Every artifact that moves through a pipeline without independent proof is vulnerable to the same class of attack.

Getting started

pip install umarise
umarise anchor <your-artifact>

The LiteLLM attack wasn't exotic. It exploited a dependency in a CI pipeline. This will happen again.

The real question is whether you'll be able to prove what you shipped, what you installed, and when.

Right now, for most teams, the answer is no.

Adding temporal proof to your publish pipeline takes one line.

Before anchoring: "Our logs say so."
After anchoring: "Verify it yourself."

Links:

Umarise CLI & SDK — anchor from terminal or CI
GitHub Action — one-step anchoring in any workflow
Anchoring Specification — open standard, 18 sections
Case study: Supply chain integrity — the full LiteLLM timeline
Integration examples — MLflow, W&B, HuggingFace, S3

Git history is editable. Here's how to make it externally verifiable.

Jonna Fassbender — Tue, 24 Mar 2026 10:19:37 +0000

Your git log says the fix shipped before the incident.
Your CI says the pipeline passed at 14:32.
Your release tag says v2.1.3.

Now prove that to someone who does not trust your systems.

That’s the real problem.

Most engineering evidence is self-issued: git history, CI timestamps, artifact metadata, cloud logs. Useful for operations, weak for disputes. In an audit, incident review, or IP conflict, the investigated system is often also the system providing the timeline.

That is circular.

The practical fix (takes minutes)
Add one independent layer: hash critical outputs and anchor the hash to a public timeline.

Three commands to see the model:

Create your artifact (example): tar -czf build.tar.gz .
Anchor it: npx @umarise/cli anchor build.tar.gz
Verify it later: npx @umarise/cli verify build.tar.gz.proof
Expected verification result looks like this:

✓ Hash Match | Bitcoin Block #941168 | VALID

No source code upload is required for verification. The proof is tied to the hash, and the hash is tied to a public blockchain timestamp.

Why this matters more now
AI and automation increase throughput dramatically. One person can now ship what used to require a team. Great for speed, harder for forensics.

When output volume jumps, questions arrive faster too:

Did this exact build exist before the deadline?
Was this fix deployed before or after the outage?
Did this model checkpoint exist before the external claim?
If your answer depends only on internal logs, you have a trust gap.

Minimal GitHub setup
If you use GitHub, you can automate anchoring on every push via a small workflow using AnchoringTrust/anchor-action@v1 with UMARISE_API_KEY in secrets.
Result: each push produces a proof artifact that can be independently checked later.

(If you prefer CLI-first, you can run the same flow in any CI provider.)

What you get from a proof
A proof gives one precise statement:

These exact bytes existed no later than time T, verifiable by third parties.

Not “our system says so.”
“Check it yourself.”

That shift matters in:

Compliance and regulated delivery
Security incidents and postmortems
IP provenance and publication priority
AI/ML lineage (weights, datasets, evaluation bundles)
“Can’t we just use OpenTimestamps directly?”
Yes, and that’s a valid path.
The tradeoff is operational: proof lifecycle handling, upgrades, retries, and workflow integration across repos.

Same cryptographic foundation. Different operational burden.

Quick self-check for your team
Ask these three questions:

Can we prove when exact bytes existed, outside our own infrastructure?
Can an external party verify that proof without our account or backend?
If our vendor disappeared, would our old proofs still verify?
If one answer is “no,” you have an evidence gap.

Try it on one artifact this week
Pick one output that matters (release tarball, model file, legal PDF, data snapshot) and anchor it.
Don’t start with policy. Start with one verifiable proof.

SDK quickstart: https://umarise.com/developers
Independent verifier: https://verify-anchoring.org
Methodology: https://github.com/Jonna1976/AnchorStack
Live case study: https://umarise.com/case/ai-code-generation

If this category is new to your team, that’s normal.
The goal isn’t complexity. The goal is to stop relying on evidence that only you can issue.

DEV Community: Jonna Fassbender