LiteLLM Got Its SOC 2 From Delve -
Supply Chain Trust Is Broken Everywhere

When you run pip install litellm, you're trusting that:

• The package maintainer's account hasn't been compromised
• Every dependency in the tree is clean
• PyPI's infrastructure hasn't been tampered with
• Nobody has injected a .pth file with base64-encoded exfiltration code

When a company shows you their SOC 2 badge, you're trusting that:

• An independent auditor actually reviewed their controls
• The test procedures were designed for their specific systems
• Exceptions were honestly reported
• The auditor firm isn't a rubber-stamp operation

In both cases, the trust chain is long, opaque, and almost nobody verifies it. We just... trust. Because checking is hard.

The LiteLLM attack didn't just hit people who installed LiteLLM directly. It hit anyone who installed anything that depended on LiteLLM. DSPy users got hit. MCP plugin users got hit. The blast radius was the entire dependency tree.

The Delve compliance scandal works the same way. A company that used Delve for their SOC 2 didn't just affect themselves - they affected every customer, partner, and investor who relied on that report. The trust propagates down the chain. If your vendor's vendor used Delve, your risk assessment is wrong too.

In software supply chain terms: Delve was a transitive dependency in the compliance trust chain. And just like LiteLLM, nobody was checking.

The LiteLLM compromise was discovered because the attacker's code had a bug that caused an out-of-memory crash. If the malware had been more efficiently written, it could have run undetected for weeks.

The Delve reports were discovered because someone found a publicly accessible spreadsheet linking to hundreds of draft audit reports. If the spreadsheet had been private, 455 companies would still be waving around template-based compliance badges.

Neither incident was caught by the systems designed to prevent them. PyPI didn't catch the malicious package. The AICPA didn't catch the template audits. Both were found by accident.

For software dependencies, the industry is slowly moving toward better verification: SLSA provenance, sigstore signing, reproducible builds, SBOMs. These aren't perfect, but they're a start. The core idea: don't trust, verify.

For compliance audits, we need the same shift. That's why we built trustcompliance.xyz- a platform that lets you verify your vendor's compliance posture independently:

• Check if your vendor's audit was produced by a flagged provider
• Scan any SOC 2 report for template fingerprints (10 known patterns)
• Verify auditor credentials against known databases
• Get a multi-dimensional risk score based on real signals

We're not saying every SOC 2 is fake. Most aren't. But just like you shouldn't blindly pip installwithout checking, you shouldn't blindly trust a compliance badge without verifying.

LiteLLM (BerriAI) was a Delve compliance customer. Their SOC 2 audit appears in our database. The very company whose PyPI package was just compromised in a supply chain attack had its own compliance audit produced by the same template mill that rubber-stamped 454 other companies.

Let that sink in: a package with 97 million monthly downloads, trusted by developers to route their API keys through, had its security "verified" by a company that used the same Word document for every client. The auditor that was supposed to catch security issues like... a supply chain attack waiting to happen... was itself a supply chain trust failure.

The trust chain was circular all along. Developers trusted LiteLLM because it had a SOC 2 badge. The SOC 2 badge existed because Delve stamped a template. Nobody checked. And now credentials are exfiltrated.

This is exactly why compliance verification can't be a checkbox. When the audit itself is a template, every downstream consumer of that trust signal is exposed. Every company that relied on LiteLLM. Every developer who ran pip install. Every customer whose API keys went through that proxy. The blast radius of a template-based audit extends far beyond the 455 companies in the Delve database.

Both incidents point to the same uncomfortable reality: the things we trust most are the things we verify least.

We trust PyPI because "everyone uses it." We trust SOC 2 badges because "they wouldn't put it on their website if it wasn't real." We trust our dependencies because checking all of them is impossible.

But impossible isn't an excuse anymore. The LiteLLM attacker knew nobody checks. The compliance template mills knew nobody reads the reports. Both exploited the same gap: the space between "trusted" and "verified."

The solution isn't paranoia. It's tooling. We need automated verification at every layer of the trust chain - from the packages we install to the audits we accept. Not because everything is compromised, but because the cost of checking is finally lower than the cost of not checking.

For your dependencies:

• Pin exact versions and review diffs before updating
• Use lockfiles and verify checksums
• Minimize your dependency tree - do you really need that package?
• Run security scanning on your full dependency tree, not just direct deps

For your vendor compliance:

• Check your vendor against known flagged audit providers
• Scan your vendor's SOC 2 report for template fingerprints
• Verify the auditor firm in AICPA's peer review database
• Ask your vendor: who audited you, and can you describe what they actually tested?