TL;DR: We've been quiet lately—despite recent Supply Chain drama—because we wanted a clearer picture before chiming in. Attacks on popular GitHub Actions (tj-actions/changed-files and reviewdog/action-setup) have shocked us, but not surprised us. They simply proved the point we had warned about. Alarmingly, reviewdog automatically promoted “typo-fixers” to maintainers overnight. Combine that with GitHub's audit logging gaps—attackers can update releases leaving no trace—and we've got a real mess. It’s time we reassess our threat models and demand better visibility.

Why the silence?

You might’ve noticed we’ve been a bit quiet over the past few months—but it’s not for lack of material. We’ve been deep in the work, focused on strengthening our Package Supply and pushing forward with the Living Off The Pipeline project. We wanted to see the full picture by gathering as much tangible evidence as possible before sounding the alarm louder. Like fellow researchers, we’ve hit a dead end in completing full forensics. There are crucial pieces of the puzzle missing, particularly in GitHub Public Events.

In fact, exactly one year ago, we published Opening Pandora’s Box - Supply Chain Insider Threats in Open Source Projects, highlighting the troubling fact that attackers could tamper with release artifacts without leaving any audit trail—a concern that was, unfortunately, foreshadowing.

March 14th—The Day GitHub Actions Stood Still

On March 14, 2025, one of the most impactful supply chain attacks targeting GitHub Actions occured—more specifically the heavily-used tj-actions/changed-files action was compromised. The malicious code indiscriminately leaked sensitive secrets from the runner’s memory, dumping them directly into public workflow logs for anyone to see.

That’s exactly why, more than two years ago, we eradicated long-term secrets from our own internal workflows, in favor of ephemeral credentials, generated on demand using OIDC. In fact, Chainguard developed OctoSTS in parallel, which is very similar and is now Open Source.

My recent LinkedIn post captured the recklessness quite well:

🌶️ 🥵 Hot take: tj-actions/changed-files hack is the opposite of a targeted attack, it’s like fishing with nuclear bombs! All the “secrets” (runtime) of the ocean lay dead on the beach (workflow run logs). Perfect plausible deniability if really you only really truly cared about your main victims. Vultures will have free secrets in logs for a while. Thank god GITHUB_TOKEN expires automatically, but PATs, NPM, PyPI publish tokens etc nope. 🙂‍↔️

But it didn't even start there! Several days earlier, on March 11th, the popular GitHub action reviewdog/action-setup was also compromised. In fact, this initial breach acted as a critical stepping stone that enabled attackers to escalate their capabilities, ultimately leading to the compromise of tj-actions/changed-files on March 14th.

This sequence of events underscores not just the attackers' persistence, but also how the real target was probably lost in the turmoil for most of you. Based on our independent forensics, we concur with fellow researchers that an attempt at hacking a well-known Web3 company was most likely the impetus for even considering to hack tj-actions.

Reconsidering the Threat Model?

The reviewdog hack also revealed a particularly facepalm-worthy security practice. The maintainer openly admitted to a now deprecated CRON job service that automatically and blindly granted write access to the repository to anyone who had a PR merged, even for a tiny contribution like a typo fix. As I highlighted in our March 2024 article, the mere act of getting a "typo fix" PR merged normally grants you a CONTRIBUTOR association, but in this case you then become a COLLABORATOR, with full write access to the repository. This is like leaving the keys to your castle under the welcome mat! This level of access allows attackers to modify releases without leaving a trace in the audit log—completely flipping the threat model on its head.

GitHub’s Audit Logs—Not Fit for Purpose

Adnan Khan hit the nail on the head with his recent tweet: 

"@github needs to make the audit log API, audit log streaming, and git event audit log free for OSS organizations. Tag updates are considered git events, so they are not included in the audit log export that non-Enterprise plans can access. This is why both tj-actions and reviewdog didn’t see anything in their audit logs. Another event that is not included in audit logs is deleting and re-uploading a release asset. This is one of the most common attack vectors in the wild and detecting it requires running an external tool to continuously monitor the release assets."

We couldn't agree more—the lack of comprehensive audit logs and public events has been a major roadblock for us in gathering intelligence.

As we prepared to publish this article, anonymous sources close to the action told us that improvements in this regard should be made in the near future…

The first quarter of 2025 is barely over…

This isn't just about these two incidents. We've seen a disturbing trend. Back in December, Ultralytics YOLOv5 was hit by a supply chain attack that injected a cryptocurrency miner into their PyPI package. The attack exploited a GitHub Actions injection vulnerability. The same month, Kong's Kubernetes Ingress Controller was exploited due to a Deputy Confusing vulnerability, leading to the unauthorized publication of a malicious Docker image with a cryptominer.

We're not just sitting here pointing fingers—we're actively building new tools to complement Package Supply. We're taking a proactive approach to identify and stop these attacks before they cause widespread damage. We'll be diving deep into our findings and strategies at NorthSec 2025 in May. Our session, "Living Off the Pipeline: From Supply Chain 0-Days to Predicting the next XZ-like attacks," will showcase how we're adapting MITRE's ATT&CK framework for CI/CD environments to get ahead of these threats.