The SOC 2 That Was Supposed to Catch This

A SOC 2 badge is not a promise that a company can never be breached. That is not what the report means, and it is not the standard anyone serious should apply. A Type 1 opinion speaks to whether controls are suitably designed at a point in time. But if public reporting on LiteLLM's CI/CD setup is accurate, this attack appears to have moved through basic control-design questions that a meaningful review should at least have surfaced.

That is what makes this more than a breach story.

On March 24, 2026, TeamPCP published two malicious LiteLLM packages to PyPI. Reporting on the incident says those packages harvested credentials from affected systems, including SSH keys, cloud credentials, Kubernetes secrets, and cryptocurrency wallets. The path into LiteLLM appears to have run through the earlier compromise of Trivy-related CI components and the exposure of a PyPI publishing token inside LiteLLM's pipeline.

That should stop people cold, because nothing about it sounds exotic. This does not read like an unavoidable failure buried deep in some obscure dependency chain. It reads like CI/CD trust failing in familiar places.

The chain started upstream. On February 28, a GitHub account called hackerbot-claw reportedly exploited a pull_request_target misconfiguration in Aqua Security's Trivy repository and gained access to privileged automation credentials. Aqua disclosed the breach on March 1 and rotated credentials, but reporting indicates the rotation did not fully eliminate every usable path immediately. On March 19, TeamPCP allegedly used retained access to force-push most aquasecurity/trivy-action tags and publish a malicious Trivy release. Any downstream pipeline consuming those actions by mutable tag, rather than immutable commit SHA, could be redirected to attacker-controlled code on its next run.

LiteLLM appears to have been one of those downstream victims.

Public reporting says LiteLLM's pipeline used Trivy for scanning, referenced the action by mutable tag, and exposed a long-lived PyPI publishing token to workflow steps that did not need it. The Register quoted LiteLLM's CEO saying the token was stored in the project's GitHub repository environment and exposed to the Trivy step. If that reporting is accurate, three facts matter immediately: a production publishing credential was available to more of the pipeline than necessary; a third-party action was trusted by mutable tag rather than immutable commit; and a security-critical release path depended on an upstream component that could be silently retargeted.

Those are not edge cases. They are table-stakes CI/CD hardening issues.

That is where the SOC 2 question stops being a branding detail and becomes central to the story.

LiteLLM's homepage displayed “SOC 2 Type 1” and “ISO 27001” badges attributed to Delve. Four days earlier, Delve had been accused of issuing hundreds of audit reports with strikingly repetitive boilerplate and other signs of template-driven production rather than individualized review. Delve denied those allegations, and we are not independently verifying them here. But the timing matters because LiteLLM was not compromised in some abstract, impossible-to-anticipate way. It was reportedly compromised through concrete release-pipeline decisions that map directly to the kinds of controls enterprise buyers assume a compliance review is meant to probe.

Scope matters here. SOC 2 does not certify perfection. A company can have a legitimate report and still suffer a serious incident. And if the relevant CI/CD and release controls were out of scope, that is important context. But if they were in scope, this incident raises very ordinary questions. Least privilege maps naturally to who can access a publishing credential. Change management maps naturally to how workflow dependencies are referenced and updated. Software integrity and vendor risk map naturally to whether a release pipeline depends on mutable third-party components with broad access to secrets.

Put plainly: this attack does not appear to have slipped through some invisible crack. It appears to have moved through doors that were standing open.

That is why the Delve story matters so much. According to DeepDelver's analysis, a leaked database appeared to show hundreds of SOC 2 and ISO 27001 reports with extremely high textual similarity, repeated auditor identifiers, repeated “zero incident” conclusions, and other signs of assembly-line output. TechCrunch later reported on the allegations and said Delve had halted demos. Delve disputed the characterization. We are not asserting here that any specific LiteLLM report was fabricated. The narrower claim is more than enough: public reporting about LiteLLM's CI/CD posture raises exactly the kind of questions a serious control review is supposed to force into the open, and the allegations against Delve cast doubt on whether that happened with the rigor customers were led to expect.

That distinction matters. It is also damaging enough on its own.

Follow the trust chain. Enterprise customers evaluated LiteLLM. LiteLLM presented compliance signals. Those signals were supposed to reduce uncertainty about the company's security posture. Meanwhile, the attacker appears to have walked through basic CI/CD design gaps involving secret scoping, dependency immutability, and release-path trust. The badge answered the question it was supposed to answer before the infrastructure did.

That is the real failure.

The broader pattern is hard to ignore. Trivy was a security scanner. Checkmarx sold code security tooling. Delve sold compliance assurance. LiteLLM sold infrastructure into environments that expected operational maturity. In each case, the product sat near the center of someone else's trust boundary. In each case, that trust appears to have become part of the attack surface.

Security tools are dangerous when compromised because they run where the secrets are. Compliance artifacts are dangerous when shallow because they tell buyers to stop asking the next question.

That is what makes this more than an incident recap. A scanner became a credential theft path inside customer CI. A compliance badge that should have supported diligence instead amplifies doubt. An enterprise buyer looking at a SOC 2 logo is not asking whether a vendor is invincible. They are asking whether basic controls were examined by someone competent enough, and independent enough, to call out obvious design risk before that risk reached production.

In LiteLLM's case, public reporting suggests the answer should have been: not with enough rigor.

The attack chain could have been broken in ordinary ways. Pinning GitHub Actions to full commit SHAs would have blocked silent tag retargeting. PyPI trusted publishing would have removed the long-lived token from the runner altogether. Better secret scoping could have prevented a scan step from accessing a production publishing credential. And a serious audit, if the release pipeline was in scope, should have forced a simple question: who can touch the credential that ships code to customers?

That question should not be controversial. It should be baseline.

The larger problem is that compliance theater does not just waste money. It can create false assurance at exactly the point where customers are deciding whether to trust a vendor with access, code execution, and operational reach inside their environment. If the review is shallow, templated, or detached from the actual control surface, the badge does not merely fail to help. It actively distorts the buyer's risk picture.

That is the connection between LiteLLM and Delve.

One story is about a supply-chain compromise. The other is about allegations that compliance reviews were produced with template-level rigor. Put together, they point to something worse than either story alone: a vendor appears to have been compromised through ordinary CI/CD weaknesses while displaying the exact assurance signal that was supposed to make customers comfortable with those controls in the first place.

The question is no longer whether LiteLLM should have pinned its dependencies. Of course it should have.

The question is what a SOC 2 badge is worth when the controls that matter most appear to have gone unchallenged.