How to Protect Your Repositories from Open-Source Supply Chain Attacks

The open-source trust model is broken. Not strained, not under review—broken. 

For years, your team has pulled third-party code into your repositories on the reasonable assumption that a widely used dependency is safe. Popularity looked like a proof. Millions of downloads looked like a security review. 

TeamPCP has proven otherwise. The threat group compromised and injected malicious code into more than 1,000 software packages, hitting names your stack almost certainly touches, including Checkmarx, Bitwarden, PyTorch Lightning, SAP, Red Hat, and GitHub. Together, the packages compromised across the campaign account for roughly 500 million weekly downloads. 

And the payload wasn’t ransomware in the classic sense. The attackers focused on stealing credentials for Kubernetes environments, Amazon Web Services, Microsoft Azure, Google Cloud, and any other service the compromised code could reach.

What is more, the attacks weren’t innovative at all. TeamPCP exploited defensive weaknesses the software industry has known about for years. The group didn’t find a new door. It walked through the one left open because closing it would slow down releases.

That trade-off – ship fast, verify later – is exactly what’s being weaponized against you. Cyberattacks on open-source registries succeed today because automation has removed the last human who might have asked a question.

None of this happened in isolation. Our DevOps Threats Unwrapped 2026 report tracked a 69% year-over-year rise in DevOps incidents, 150+ events with critical or major impact, and more than 1,700 hours of disruption across GitHub, GitLab, Azure DevOps, and Jira.

Supply chain attacks aren’t an emerging risk anymore. They’re the baseline. This article covers how the trust model collapsed, why prevention alone won’t save you, and what a real recovery position looks like.

How did the open-source trust model get broken?

Ask your team a simple question: who reviewed the last dependency update that reached production?

In most organizations, the honest answer is ‘nobody’. Not out of laziness—out of volume. A single service can carry thousands of transitive dependencies, and no human review process scales to that.

So attackers stopped attacking you directly. There’s no reason to break in when your pipeline can fetch the malicious code for you; on schedule, with valid credentials, over a connection your security team approved. 

That’s the mechanics behind the open-source software supply chain problem. Compromise a trusted package upstream, and every downstream consumer imports the malicious code themselves. It flows straight into the repositories, pipelines, and workflow files you host on GitHub, GitLab, Bitbucket, or Azure DevOps. 

This happens through an authenticated, whitelisted, entirely legitimate build process. Your firewall never fires, because nothing broke in. You invited it. The public registries are only the delivery route. Your repositories are the destination. And they’re what you actually own, control, and have to restore. 

The scale of the invitation is what should concern you. Feross Aboukhadijeh, founder and CEO of supply chain security firm Socket, told CyberScoop that installing open-source code quickly is now among the most dangerous things an organization can do, with roughly a 1 in 10 chance that any given package could trigger an active attack. 

And one poisoned package is enough, because your compromised CI/CD pipeline holds the master key: hack the runner, and you don’t get access to one room, but the whole building. Overprivileged runners, permanent service tokens, and unprotected workflow files turn a single bad dependency into cluster-admin access.

The open doors to your pipeline don’t have to be new, either. Abandoned repositories sit unmonitored with live tokens inside, and attackers scan them automatically with tools like TruffleHog and Gitleaks. Nobody owns that code. Nobody rotated those secrets. Nobody would notice the entry.

Which is why the trust model didn’t collapse under a sophisticated attack. It collapsed under ordinary operational neglect.

When your security tools become the attack vector 

So how do you compromise an organization that did everything the playbook told it to do? You compromise the playbook. Specifically, the tools it told them to buy.

In late February 2026, attackers slipped into the repository automation behind Trivy (CVE-2026-33634), a vulnerability scanner, through a misconfiguration in its GitHub Actions environment. 

On March 19, they published poisoned releases of it. They came back three days later with malicious Docker Hub images, infecting Aqua Security’s repositories and registries related to Trivy.

The software whose sole purpose is catching malicious code became the vehicle for delivering it. From there, the campaign spread across password managers, automation platforms, data visualization tools, and CI/CD infrastructure. 

Every one of those tools holds privileges you deliberately granted: repository-wide read access, vault credentials, deployment rights to production. Compromise the tool, and you inherit the trust. No exploit required.

The delivery route runs through your automation. Attackers hit CI runners and inject malware into the repositories those runners maintain, turning one poorly secured pipeline into patient zero for everyone downstream who pulls the latest version on schedule.

What follows is credential theft at elevated privilege, exfiltrated source code, wiped repositories, and repository ransomware extortion. 

Paying won’t help you either. Kimberly Goody, a senior manager at Google Threat Intelligence Group cited by Cyberscoop, reads the group’s behavior as a desire for notoriety and chaos rather than revenue. 

Nathaniel Quist of Palo Alto Networks put numbers to it: more than 10,000 claimed victims have yielded only about $90,000 in extortion payments. They’ll take your money. They just aren’t doing this for it. 

Meanwhile, automation removed your last checkpoint. Agents now install dependencies nobody reviewed, and the AI failure modes are already catalogued: package names the model invented, poisoned MCP servers, and cracked marketplace extensions. 

AI-related incidents on the major DevOps platforms doubled across the quarters of 2025, and AI-authored pull requests introduce 1.7 times more problems than human ones. That’s why a tested restore path has to be part of how you secure your agents, not a project you get to next quarter. 

Every step in this chain ran on permissions you granted and automation you built. That’s the bad news. However, it’s also the new opening. 

Take back control with DevSecOps hygiene

You cannot review thousands of transitive dependencies. Stop treating that as the goal.

What you can control is how far one poisoned dependency reaches once it lands, and how fast you can undo it. Zero trust means nothing gets access on reputation alone. You enforce that for users and devices already. Now enforce it for dependencies.

Concretely, that means tightening CI/CD pipeline security on five fronts:

Pin versions and enforce lockfiles with checksums	Automatic upgrades to the newest release are how patient zero reaches you. Pin deliberately, then upgrade on review.
Verify commits and require signing	Signature checks catch injected commits that a hijacked maintainer account would otherwise wave straight through.
Apply least privilege to runners	A runner that uploads one artifact doesn’t need cluster-admin. Separate the runners handling external pull requests from those with production deployment rights.
Review workflow files like production code	Changes to .github/workflows deserve the same scrutiny as application logic. Attackers hide exfiltration steps in YAML nobody reads.
Rotate secrets properly	The moment a package is flagged, treat every secret the affected runner could read as public and rotate it. Then verify that the rotation actually took effect.

Rotation deserves its own emphasis, because it’s where teams keep losing. Amitai Cohen, who leads the attack vector intelligence team at Wiz and has tracked TeamPCP’s campaign since it began, documented victims getting reinfected repeatedly. Some of them three times inside a single month. And for the same reason each time: the stolen credentials were never properly revoked. 

Removing the malicious package isn’t remediation. If the stolen token still works, you’ve cleaned up the symptom and left the access in place. 

The same logic scales upward to how the CI/CD pipeline itself is built: security decided at design time rather than retrofitted, least privilege as the default, and build systems isolated from the rest of your network. 

Now the honest limit. Detection has genuinely improved, and the sharpest teams now catch injected code in minutes rather than days. However, it still isn’t fast enough. By the time anyone notices, the package has already executed inside real pipelines, with real credentials attached. 

You can’t prevent your way out of a threat that arrives through legitimate channels at machine speed. Which leaves one question worth answering before it’s urgent: 

When a poisoned commit reaches your repository, how do you get back to the version before it?

Restoring confidence and code with GitProtect

Restoration is the obvious answer—but only if the restore point exists, stays clean, and covers everything the attack touched.

That’s the case for treating DevOps backup as infrastructure rather than insurance. Every other control in your stack tries to keep malicious code out. Backup is the only one that still works after it gets in.

In practice, that comes down to the following capabilities:

Disaster recovery and granular restore

When a poisoned dependency lands, you need to roll back to a known-good state without reverting three weeks of legitimate work. With granular, point-in-time recovery, you can recover a single repository, branch, or configuration file and restore into a new account when returning to the old one isn’t possible. No need to rebuild an environment from scratch.

However, that capability is only real if you’ve rehearsed it, which is why you should have a disaster recovery plan and disaster recovery testing procedures. An untested plan restores nothing on the night you need it.

Encryption and immutability

Attackers with valid credentials go after backups first—the same stolen token that reached your repository can reach a copy sitting in the same tenant. GitProtect encrypts backups in flight and at rest with AES-GCM using your own key, and writes them to WORM (write once, read many) immutable storage. Nothing can overwrite or delete that copy within its retention window, including an account with root admin rights.

Metadata coverage

Your source code isn’t your project. Issues, pull requests, comments, labels, milestones, wikis, releases, and pipeline configurations carry the reasoning behind every decision your team made. Restore only the code, and you’ve recovered a repository without its history—and without the CI/CD configuration your builds depend on.

Multi-storage and automation

Policy-based automatic backups remove the human step nobody remembers during an incident. Replication across multiple locations—GitProtect’s own cloud, your S3 or Azure bucket, local storage—satisfies the 3-2-1-1-0 rule. It gives you a clean copy in a tenant the attacker never had credentials for. All that, coupled with custom, unlimited retention for enterprise-grade backup compliance. 

These capabilities ensure a business-critical outcome: a version of your codebase the attackers cannot reach.

Stop relying on trust. Start relying on recovery.

If the tools built to protect you can be compromised, trust has stopped being a security control. That’s the real lesson learned from the TeamPCP attacks. 

More than 1,000 poisoned packages, a vulnerability scanner used as a delivery mechanism, and credentials pulled out of pipelines that were doing precisely what they were configured to do. Nothing exotic. Just a model that was always going to break, actually breaking.

Hygiene still matters. Pin your versions, verify your commits, cut your runner privileges, rotate your secrets like the attacker already has them. Then accept the ceiling. Prevention is probabilistic. It reduces how often you get hit, never whether.

Recovery is the only part of your security posture you can verify in advance. You can test a restore this week and know—not hope—that a clean version of your codebase, metadata, and CI/CD configuration exists somewhere an attacker’s stolen token cannot reach.

The question your board will eventually ask isn’t whether you were compromised. Everyone is, eventually. It’s how quickly you got back to a state you could prove was clean.

Have an answer ready before you need it.