Supply chain, AI benefits/risks

Supply chain attacks now make the budget case CISOs never could

Supply chain vulnerability being exploited through a cyber attack on text code in an editor.

COMMENTARY: Supply chain risk in the software pipeline has been a known problem for years, but it never did get budget priority.

Before exploitation, when entire classes of attack are just theoretical, risk stayed low. Getting ahead of potential future risks represents a "nice to have" for security teams in orgs where there’s tight funding, even for controls that are known to move the risk needle.

[SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Read more Perspectives here.]

Until there's real-world impact that costs money or does reputational damage, novel attack vectors don't get much real-world attention.

And then the exploits start.

Enter TeamPCP. The threat group's wave of high-profile, high-damage attacks over the past year has handed CISOs the concrete language and real-world examples they need. The attacks are recent enough to be news, and specific enough so they are useful in a boardroom.

Every time TeamPCP (and now their partners) exploited these companies, they've used the same attack pattern, adapted to different environments. Once inside a pipeline, an attacker runs with our permissions and ships code the same way our team does. There’s no outsider anymore.

Attackers can execute inside trusted systems now, and that means the entry point is no longer what’s been installed. Most boards think they are already covered because they funded scanning tools, but reliance on traditional scanners creates a blind spot now actively exploited by attackers. TeamPCP did it first, but they certainly won't be the last to hit these powerful, often unguarded, weak points.

What a compromised pipeline actually costs

TeamPCP spent three weeks turning the security industry's own tools against the developers who relied on them. They compromised Trivy (a scanner running in pipelines everywhere) and used the credentials it harvested to reach Checkmarx, then LiteLLM, a library running inside nearly every AI application in production. The tj-actions breach hit over 23,000 repositories. The Bybit hack cost $1.4 billion. Each compromise funded the next one automatically, at machine speed, while every pipeline involved showed green.

Victims of this chain of exploits have also been hit by massive amounts of data exfiltration: Cisco lost 300 private source code repos, the European Commission lost 350 gigabytes of data, and Mercor lost 3 terabytes of video interviews and identity verification documentation, including personal data for 30,000 AI contractors.

The FBI issued a warning about imminent extortion across thousands of downstream environments. Class action investigations are being launched against companies that experienced losses of personal information for customers and employees. The board needs education about why current scanners don't work to detect these weaknesses, and why companies are at risk.

The board may have already seen coverage of these attacks. But they haven't heard that the tools they already paid for (scanners, DevSecOps, SBOMs) don't cover the pipeline itself. Scanning tools wait for code to arrive in the repository. The pipeline executes before that. Runners, tokens, third-party actions all live in the blind spots, and attackers know it.

It’s actually a simple conversation: Our automated build systems ship code directly to customers. Attackers can take over those systems without setting off any existing alerts. If that happens, we become the ones pushing the attack out. That sentence lands differently now than it did six months ago, because now there are named companies already hit.

Once an attacker gets inside a pipeline, they have our credentials and a direct path to our customers in a single move, which turns a security incident into a material breach.

Finally, it’s likely the board will pay attention.

Once that happens it's time to make the budget case: This is about controlling what the company ships. The tools we already pay for do not cover this surface, and this needs its own line in the budget. Losing control over what goes out under our name is the real cost of inaction.

So what exactly are we budgeting for? Pipeline security spend typically covers three things: runtime monitoring of what executes inside build environments; short-lived credential management so that a stolen token has a window of minutes rather than months; and integrity verification so that the action or tool our pipeline calls today is probably the same one it called yesterday.

But before any of that, there’s a more basic gap most teams miss: posture. Is our pipeline configured correctly in the first place? Pipelines are not just infrastructure, they are code. That code imports other code, just like any application, and it can carry vulnerabilities the same way. That’s exactly what attackers exploited in the Trivy incident. None of this surface was covered by traditional scanners, andd that’s why attackers are operating there with so little resistance.

Budgeting starts with understanding whether our pipeline was secure in the first place. Pipelines are code, and like any codebase, we need to analyze, test, and fix them. That means identifying misconfigurations, vulnerable dependencies, and unsafe integrations before an attacker does.

Pipeline security spend then extends to runtime visibility into what executes inside build environments, reducing credential lifetimes so stolen access expires quickly, and verifying the integrity of every tool and action our pipeline depends on. None of that’s covered by the scanning tools already in place. A board that understands it’s funding visibility and control over a system that currently ships code with no oversight represents a board that will likely spend the money.

When it comes time to address the board, condense the information to named incidents, dollar figures, and a pattern specific enough to explain in a single sentence.

The company needs visibility into the part of the software factory that currently runs with no oversight: the build environment itself, the credentials it touches, and the tools it trusts. Those blind spots cost money and reputation across every organization TeamPCP hit. And unlike most security investments, the ask maps directly to a documented, recent, ongoing attack campaign that many executives have already read about.

It made sense to wait when the risk was theoretical, but that time ended. The window to get ahead of this has arrived, but it won't stay open for much longer.

Zaid Al Hamami, founder and CEO, Boost Security

SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Each contribution has a goal of bringing a unique voice to important cybersecurity topics. Content strives to be of the highest quality, objective and non-commercial.

Get daily email updates

SC Media's daily must-read of the most current and pressing daily news

By clicking the Subscribe button below, you agree to SC Media Terms of Use and Privacy Policy.

You can skip this ad in 5 seconds