Trivy, KICS, LiteLLM: A Supply Chain Warning on Transitive Dependencies

How a compromise in trusted security tooling rippled through Checkmarx KICS and LiteLLM, exposing the real risk of transitive dependencies.

The past several days has been a serious reminder that supply chain attacks do not stop with the first compromised project. What started with a malicious Trivy release appears to have widened into a separate but similar attack involving Checkmarx KICS GitHub Actions and then LiteLLM. Taken together, these events show why teams need to pay closer attention to transitive dependencies, not just the packages they knowingly install. Public reports indicate that TeamPCP, a threat actor active on Telegram, orchestrated this as part of a broader campaign.

The Malicious Trivy release v0.69.4 on March 19, 2026:

The first major incident came from Trivy. On March 19, 2026, attackers pushed a malicious v0.69.4 release and tampered with related GitHub Actions. Reports show they injected an “Info-Stealer” that ran in CI/CD workflows, collected sensitive data such as SSH keys, tokens, and environment variables, and exfiltrated it—all while keeping the workflow looking normal.

This increased the danger significantly as Trivy was now a trusted security tool operating in a place where high-value credentials often exist.

This matters because teams commonly use Trivy in build and release pipelines. When attackers compromise a tool in that position, they can cause damage beyond the tool itself. The real concern is what it had access to when it ran.

The Checkmarx KICS Compromise on March 23:

On March 23, researchers disclosed a separate but similar compromise of Checkmarx KICS GitHub Actions, where attackers used similar tradecraft with different infrastructure. Whether every detail was identical is less important than the larger pattern. Attackers tampered with trusted automation components to harvest secrets from CI/CD environments. That alone should concern any organization relying heavily on GitHub Actions and other pipeline tooling.

Malicious releases in LiteLLM:

And then came LiteLLM. On March 24, LiteLLM announced that attackers had published malicious versions 1.82.7 and 1.82.8 to PyPI. The reported behavior again involved searching for SSH keys, cloud credentials, tokens, and environment variables, then exfiltrating them. What made the LiteLLM incident especially important was the likely relationship with the earlier Trivy compromise. Public reports linked the LiteLLM compromise to credentials that attackers likely exposed using a Trivy scanner on LiteLLM’s CI/CD pipeline. Now this has stopped being a story about just one bad release of a package. It became a story about compromise spreading through the software supply chain.

The Transitive Dependency Problem:

LiteLLM also makes the transitive dependency problem much easier to see. Not every affected user would necessarily have installed those malicious LiteLLM versions directly. Some environments may have pulled LiteLLM in indirectly through AI tooling, orchestration frameworks, or other upstream dependencies. For example, the popular Python project “dspy,” used for AI workflows and starred over 33,000 times on GitHub, pulls in “LiteLLM” as a transitive dependency. Hence a “pip install dspy” can bring in the malicious litellm package when the intention was not really for the developer to install litellm.  In other words, the risk may not have come from a package a developer explicitly chose. It may have arrived because something else in the dependency graph resolved to it.

That is where many teams still have a blind spot. They may have decent visibility into direct dependencies declared in manifests, but much less understanding of what enters indirectly. For attackers – they have struck gold if it lands in the environment and runs with access to secrets.

The Need for Software Composition Analysis to evolve:

The last couple of weeks have shown us why Software Composition Analysis cannot stop at a flat list of packages. The better question is not only, “Do we use this package?” but also, “How did it get here, what pulled it in, and where did it execute?” That means understanding dependency relationships, build-pipeline context, and version resolution paths, and not just producing an inventory.

The broader takeaway is straightforward: these incidents follow a recurring pattern in software supply chain attacks. TeamPCP, which Microsoft identifies as the threat actor, compromised Trivy, Checkmarx KICS, and LiteLLM, exposing the same underlying risks seen in earlier cases. In Shai-Hulud, attackers spread malicious npm packages through maintainer account abuse and preinstall execution. In Glassworm, they hid malicious code inside trusted developer tooling. In the older event-stream incident, a widely used package pulled in the malicious flatmap-stream dependency, passing risk downstream to unsuspecting users.

That is really what these incidents are showing. The issue is not just malicious packages. It is malicious packages moving through trusted relationships.