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

Host A: Welcome to DevTools Radio, I'm your host, and today we're talking about something that should be keeping every engineering team up at night — the TeamPCP attacks and what they reveal about the state of CI/CD security.

Host B: And when you say "keeping teams up at night," you're not being dramatic. This is genuinely alarming stuff. So let's set the scene — what actually happened with TeamPCP?

Host A: So attackers used stolen credentials to publish malicious versions of Trivy — which is a widely used vulnerability scanner — and its GitHub Actions. And then days later, a separate attack hit LiteLLM, pushing credential-stealing payloads to millions of developers through PyPI.

Host B: Wait, so they poisoned a *security* tool? That's almost poetic in the worst possible way.

Host A: Right, and it didn't stop there. A Python package called Telnyx — downloaded roughly 790,000 times a month — also got hit. This isn't a series of random incidents. It's a playbook, and it's working.

Host B: And the reason it works is because of something kind of fundamental, isn't it? We've essentially built the entire modern software supply chain on the assumption that the things we depend on are trustworthy by default.

Host A: Exactly. And attackers figured out a long time ago that assumption is wrong. The fastest way to distribute malware at scale isn't to attack production systems directly — it's to hijack the pipelines that *build* and *ship* the software in the first place.

Host B: Which makes CI/CD pipelines the most valuable target in any organization, and yet somehow they're often the least secured. These systems have access to cloud credentials, signing keys, deployment systems — it's like leaving the master key under the doormat.

Host A: And it's not like this is new territory either. Last year, attackers compromised a popular GitHub Action called tj-actions/changed-files and exposed secrets across more than 23,000 repositories — just by redirecting a version tag to a malicious commit.

Host B: Twenty-three thousand repositories from one move. That blast radius is staggering. So what do we actually do about this? Because I feel like the security community has been warning about supply chain attacks for years.

Host A: Here's the thing — the fixes aren't complicated or novel. We already know what to do. First, get rid of static credentials. Long-lived tokens, PATs, static API keys — assume they'll be stolen, because they will. Move to short-lived federated identity with OIDC instead.

Host B: And I'm guessing pinning your dependencies is part of the answer too, but there's a catch there?

Host A: There is. Pinning to a commit hash is better than nothing, but it's not enough if that action is still pulling in *other* components by a mutable tag. You're only as secure as the weakest reference in the whole chain. And then enforce the basics — branch protection, PR reviews, MFA across the org, signed commits.

Host B: None of that sounds revolutionary. It sounds like what we already do — or *should* already be doing — for production systems. And I think that's kind of the point, isn't it?

Host A: That's exactly the point. We need to start treating CI/CD systems like the production systems they actually are. The patterns and tooling exist. The problem is we haven't applied them consistently, and every successful compromise leaks more credentials that get used to compromise even more systems. It compounds.

Host B: It's a self-reinforcing cycle, and breaking it requires getting serious about pipeline security before the next TeamPCP, not after.

Host A: Well said. Alright, that's going to do it for today's episode. If your team hasn't audited your CI/CD security posture recently, consider this your wake-up call.

Host B: And hey, if you want to feel *slightly* better about your Monday, at least you're not the person who shipped a malicious vulnerability scanner. Thanks for listening to DevTools Radio — we'll see you next time.