Living Off the Pipeline: From Supply Chain 0-Days to Predicting the next XZ-like attacks

Living Off the Pipeline: From Supply Chain 0-Days to Predicting the Next XZ-Like Attacks

Speaker: François Proulx (BoostSecurity)

Conference: NorthSec 2025 — May 15–16, 2025, Marché Bonsecours, Montreal

Watch on YouTube: https://www.youtube.com/watch?v=FO8eIGu8EJo

Reading time: ~10 minutes

TL;DR

François Proulx, VP of Security Research at Montreal-based BoostSecurity, presents a systematic taxonomy of CI/CD attack vectors, a live walk-through of vulnerable GitHub Actions workflow patterns, and the architecture of two internal tools — Package Supply V3 and Package Threat Hunter — that have already caught real compromises in production. The talk extends last year's NorthSec presentation to include an adapted MITRE ATT&CK framework for CI/CD environments and introduces the concept of "living off the pipeline": abusing legitimate build tools as the attack vehicle rather than introducing foreign malware.

Introduction

In March 2025, the tj-actions/changed-files GitHub Action was compromised in a supply chain attack whose forensic trail, reconstructed independently by BoostSecurity in parallel with Wiz and Palo Alto Networks, pointed to Coinbase as the intended final target. When the attacker was interrupted before completing the operation, they responded by injecting a memory dump snippet into the workflow runner that printed all in-memory secrets to public workflow run logs — an act Proulx describes as "nuclear fallout," leaving credentials exposed for anyone monitoring public GitHub event streams.

This incident is the opening example, not a digression. Proulx uses it to establish the core premise of the talk: CI/CD pipelines occupy a uniquely privileged and uniquely neglected position in the software supply chain. They run with elevated credentials, accept untrusted inputs by design, and have historically been excluded from security scope by both security teams and development teams. The result, in Proulx's formulation, is that 2025's build pipelines resemble the average 2005 PHP web application in terms of secure coding maturity. The attack surface is real, richly documented, and largely undefended.

The SLSA Framework and Why CI/CD Is the Weakest Link

Proulx grounds the threat model in the SLSA (Supply Chain Levels for Software Artifacts) framework, which maps the software supply chain from developer laptop through source control, build pipeline, and artifact registry to the final consumer. The build pipeline sits precisely at the inflection point between trusted source code and trusted artifact — making it both the most critical component to secure and, because it must accept pull request triggers and untrusted inputs from forks, structurally difficult to harden.

▶ Watch: SLSA framework and the CI/CD threat model (2:00)

The threat model Proulx develops distinguishes four primary vulnerability classes. The first is the "POWN request" — a pull request containing files (Makefiles, configuration files, tool configuration) that modify the behavior of build tooling already present in the pipeline. This is the origin of the "living off the pipeline" terminology: the attacker does not introduce foreign tools but instead modifies how existing, trusted build tools behave. The second class is template injection — the use of GitHub Actions' mustache expression syntax (${{ ... }}) to inject arbitrary shell commands into workflow steps. The third is bot-mediated confused deputy: exploiting trust relationships granted to automated identities such as Dependabot to bypass authorization checks on privileged operations like merging to a protected branch. The fourth is persistent self-hosted runners — VMs that survive across job executions and can therefore be used as lateral movement pivots or secret exfiltration targets from other unrelated jobs.

Anatomy of a Vulnerable Workflow

Proulx walks through a concrete vulnerable workflow step by step, making the attack surface legible for practitioners who do not routinely read GitHub Actions YAML.

▶ Watch: Anatomy of a vulnerable GitHub Actions workflow (8:01)

The representative vulnerable workflow exhibits several compounding weaknesses. First, it triggers on pull_request_target — an event type that, unlike pull_request, grants write access and exposes repository secrets even when executed against code from an untrusted fork. Second, it does not explicitly set the permissions key on the GitHub token, leaving the token with the repository's default permissions, which in many configurations include write access. Third, it checks out the fork's code — including the fork's Makefile — and then invokes make, giving the attacker complete control over what the runner executes. Fourth, it uses a named secret with apparent cross-repository write access. Fifth, the trigger does not specify a branch filter, meaning the vulnerability can be exploited against stale remote branches that were never cleaned up after the main branch was patched — a class of "zombie vulnerability" Proulx considers particularly dangerous.

A secondary vector visible in the same example is git branch name injection: GitHub Actions interpolates the branch name as a mustache expression in several contexts, meaning that a branch named to include shell metacharacters can achieve code execution when the workflow runs.

Proulx emphasizes that none of this is GitHub-specific. GitLab, Azure DevOps, CircleCI, OpenShift Pipeline-as-Code, Travis CI, and Jenkins are all potentially vulnerable when configured to trigger on pull request events from untrusted sources. The specific trigger semantics and permission inheritance models differ across platforms, but the structural risk is identical.

Package Supply V3 and the Poutine Scanner

The operational backbone of BoostSecurity's research is Package Supply, an internal pipeline scanning system rebuilt in Go in the months after last year's NorthSec presentation. The rewrite was motivated by the need to use Poutine — BoostSecurity's open-source pipeline vulnerability scanner — as a core building block, enabling sub-hour rescans of the entire curated dataset.

▶ Watch: Package Supply V3 architecture and Poutine scanner (10:00)

Poutine accepts a read-only GitHub or GitLab token, automatically discovers repositories, indexes their workflow files, and applies a rule set written in Rego — the Open Policy Agent policy language. The Rego-based DSL makes custom rule authoring accessible and composable: practitioners can clone and extend existing detection logic without modifying core scanner code. One significant capability added recently is stale-branch scanning: because pull_request_target workflows can be triggered against any remote branch, not just the default branch, a workflow vulnerability patched in main may still be exploitable via a stale feature branch. Poutine can enumerate and scan these branches, surfacing what Proulx calls vulnerabilities "revived from the dead."

The scale of Package Supply V3's dataset provides the second data point. The system currently covers entities — corporations, government agencies, universities, and major open-source foundations — rather than raw repository counts. Under this model, Google maps to over 100 GitHub organizations; Red Hat to 120; US federal and state government entities to 340. The entity-centric approach also provides a structured responsible disclosure target: rather than discovering a vulnerability in an unknown repository, the system identifies a Google or Red Hat workflow and routes the finding through the appropriate VRP or security disclosure program.

From the full dataset, Package Supply V3 produces over 200,000 findings at low confidence (broad Poutine detections). After applying high-confidence internal rules that filter on exploitability criteria — risky trigger present, secrets exposed, secrets have non-read-only access — the population contracts to roughly 10,000. Of those, 24% are assessed as immediately exploitable and routed to responsible disclosure; another 42% are exploitable pending an environmental condition (disabled workflow, crashing dependency) that could resolve at any time.

The Ultralytics Miss and the Package Threat Hunter

The talk's most self-critical section describes how BoostSecurity's own system failed in the Ultralytics case — and what they built in response.

▶ Watch: The Ultralytics miss and building Package Threat Hunter (16:00)

In August 2024, Package Supply V3's first operational version flagged a vulnerability in the Ultralytics GitHub Action — a regression of a previously reported and patched workflow issue. With Google VRP findings requiring attention simultaneously, the Ultralytics finding was deprioritized and ultimately forgotten. In December 2024, Ultralytics was compromised using that exact vulnerability, with a Monero cryptocurrency miner injected into published packages via the compromised CI/CD pipeline.

The response was Package Threat Hunter: a near-real-time system that ingests GitHub's public event firehose (delayed approximately five minutes by GitHub API constraints), cross-references events against the Package Supply vulnerability dataset, and attempts to detect active exploitation as it happens rather than after the fact. Barely ten days after the internal hackathon that produced the system's prototype, the Kon Kubernetes ingress controller was compromised over the Christmas holiday. Most observers, including Kon's own maintainers, did not notice until January. When the news broke, Proulx's team reviewed Package Threat Hunter's data and found that the forensic timeline of the attack was already present in their logs — more detailed than many contemporaneous accounts — because they had been ingesting the relevant GitHub events in near-real-time throughout the holiday period.

Notable Quotes

"Twenty twenty-five's build pipelines look like the average two thousand and five PHP web app in terms of secure coding. It's a real dumpster fire."

"I'd like to rename CI/CD: RCE as a service."

"We can basically revive from the dead vulnerabilities that have been fixed in the main branch but have been forgotten on stale branches."

"We had all the data to make a forensics timeline — even more detail than many other folks — because we had been ingesting the events in near-real-time."

"The final intended target was Coinbase. Since the attacker was not allowed to finish the job, they got mad and just put a simple memory dump snippet that logged all secrets in plain text for anyone to grab."

Key Takeaways

• CI/CD is the new soft underbelly. Build pipelines run with high privilege, accept untrusted inputs by design, and have historically been excluded from security testing scope. This combination makes them a preferred target for supply chain attackers.

• Living off the pipeline is the dominant TTP. The most effective attacks do not introduce novel malware; they modify existing build tool configuration (Makefiles, workflow YAML, tool configs) to redirect the pipeline's own execution toward attacker-controlled outcomes.

• pull_request_target is the highest-risk trigger. Unlike pull_request, this event exposes repository secrets even against untrusted fork code. Combine it with unconstrained permissions, Makefile invocation, and cross-repo secrets and the result is zero-click RCE with full secret exfiltration.

• Stale branches resurrect patched vulnerabilities. Fixing a workflow in main does not fix it in every remote branch. Tools that only scan the default branch will miss exploitable pull_request_target workflows in forgotten feature or release branches.

• Near-real-time event ingestion enables forensic reconstruction. The Package Threat Hunter architecture — consuming GitHub's public event stream and crossing it against a vulnerability dataset — produced a more complete forensic timeline of the Kon ingress controller compromise than most after-the-fact investigations, and did so before the public became aware the incident had occurred.

• Poutine is open source. The pipeline vulnerability scanner underlying BoostSecurity's research is publicly available and accepts read-only tokens for GitHub and GitLab. Organizations can deploy it against their own repositories using the existing Rego rule set or custom rules.