The TeamPCP attacks are a warning: Your CI/CD pipeline is the new front line

We built the modern software supply chain on a flawed assumption: that the systems and dependencies we rely on are trustworthy by default.

Attackers figured out a while ago that this assumption is wrong, and they’ve been exploiting it ever since. The fastest way to distribute malware at scale isn’t to attack your production systems directly; it’s to hijack the pipelines that build and ship your software in the first place. TeamPCP just made this obvious to everyone else.

Here’s what happened: Attackers used stolen credentials to publish malicious versions of Trivy, a widely used vulnerability scanner, and its GitHub Actions. Days later, a separate attack hit LiteLLM, pushing credential-stealing payloads to millions of developers through PyPI. Then, Telnyx, a Python package downloaded roughly 790,000 times a month. 

“The fastest way to distribute malware at scale isn’t to attack your production systems directly; it’s to hijack the pipelines that build and ship your software…”

This is a playbook, not just a series of unrelated incidents. And it’s going to keep working until we stop treating CI/CD systems like they’re somehow different from production systems.

The system is working as designed, and that’s the problem

CI/CD pipelines are the most critical environment in most organizations and also the least secure. They have access to cloud credentials, signing keys, and deployment systems. They routinely execute third-party code with almost no scrutiny. That combination is a gift to attackers. 

Last year, attackers compromised tj-actions/changed-files and exposed secrets across more than 23,000 repositories by redirecting version tags to a malicious commit. More recently, an autonomous AI bot called Hackerbot-Claw demonstrated how easily these workflows can be exploited. 

The TeamPCP attacks aren’t especially sophisticated. The bar just isn’t that high. 

The issue isn’t that development teams are doing something wrong. The defaults in CI/CD tooling are unsafe. Trust is implicit, controls are weak, and the blast radius is enormous. One compromised release can cascade across thousands of organizations in hours. We designed it to work that way.

We already know how to fix this

The fixes aren’t complicated or novel. We have the patterns and tooling. The problem is we haven’t applied them consistently.

Get rid of static credentials, including long-lived tokens, PATs, and static API keys. Assume they’ll be stolen, because they will be. Move to short-lived federated identity with OIDC. Credentials should be ephemeral and tightly scoped.

Pin everything, then audit what you pinned. Pinning to a commit hash isn’t enough if that action pulls in other components by a mutable tag. You’re only as secure as the weakest reference in the chain.

Enforce the basics in your repositories. Branch protection, PR reviews, no admin bypasses, MFA across the organization, signed commits. None of this is new advice. Gitsign makes the signing part easier than PGP, even if GitHub still doesn’t make it as easy as it should be.

“Pinning to a commit hash isn’t enough… You’re only as secure as the weakest reference in the chain.”

Treat CI/CD systems like production systems, because that’s what they are.

What we’re seeing right now is the early phases of something that’s going to compound. Every successful compromise leaks more credentials. Those credentials get used to compromise more systems. The blast radius grows. This is how supply chain attacks scale.

This is also exactly how they can be stopped, if we’re willing to apply the same rigor to our pipelines that we already apply everywhere else.