How 23,000 Repos Got Their Secrets Stolen Through Their Own CI/CD Pipeline

Been thinking about writing this one for a while. Supply chain attacks against CI/CD pipelines have been picking up pace over the past two years and the March 2025 tj-actions incident was the one that finally made me sit down and document everything properly. This is how I think about hardening GitHub Actions pipelines and what I actually do in practice. Original is on my blog but happy to have the conversation here too.

On a regular Tuesday morning, your engineering team pushes code, the pipeline runs like it always does, and somewhere in those automated logs, your AWS access keys, your GitHub tokens, your RSA private keys, are being quietly printed out and collected by someone you have never met. You are not notified. No alarm goes off. GitHub does not send an email. Your pipeline shows green.

That is not a hypothetical. That is exactly what happened to over 23,000 teams in March 2025.

I have spent years working at the intersection of software engineering and security, where pipelines were moving over a billion dollars in monetary transactions, and more recently building or , where encrypted GitHub OAuth tokens are stored rather than long-lived deploy keys sitting in plain text.

3. Restrict GITHUB_TOKEN to the Minimum It Needs

Think of the GITHUB_TOKEN like a master key that GitHub automatically hands to every workflow when it starts. In many default configurations, that key has write access to your entire repository. A compromised workflow with that key can push to your main branch, publish releases, and modify your deployment configuration, all without your knowledge.

The fix is to start from zero permissions and then explicitly add back only what each job actually needs.

First, go to your repository settings under Settings → Actions → General → Workflow permissions and set it to read-only as the default.

Then in your workflow files, declare permissions explicitly:

# Lock down the whole workflow by default, nothing is permitted

permissions: {}



jobs:

  build:

    runs-on: ubuntu-latest

    permissions:

      contents: read    # Only needs to read code

      packages: write   # Needs to push a container to the registry

      id-token: write   # Needs to request an OIDC token

    steps:

      # build steps here...



  deploy:

    runs-on: ubuntu-latest

    permissions:

      contents: read    # This job genuinely only needs to read code

    steps:

      # deploy steps here...

When you do this, even if one job in your workflow is compromised, the attacker is limited to what that specific job was permitted to do. A breach of your build job cannot automatically become a write to your main branch.

4. Treat Workflow Files Like Production Code, Because They Are

Here is something I have noticed over the years. Engineering teams will require two or three reviewers to approve any change to their core application code. But a change to a .github/workflows/ file, which controls what runs in their entire CI/CD pipeline, sometimes gets merged with a single click.

That inconsistency is a problem. Workflow files are your production infrastructure. A change to a workflow file can introduce a new third-party Action, relax permissions, or add a new deployment step. It deserves the same scrutiny as your application code.

The simplest way to enforce this is through CODEOWNERS, a GitHub feature that lets you specify which team must review changes to specific files or directories:

# .github/CODEOWNERS

# Any changes to workflow files require review from the security team

/.github/workflows/    @your-org/security-team @your-org/platform-engineering

/.github/actions/      @your-org/security-team

With this in place, no workflow change, including the introduction of a new third-party Action, can be merged without a review from someone who knows what to look for.

Additionally, use GitHub's Environments feature to add a human approval gate before any workflow deploys to production. This means even a fully compromised workflow has to stop and wait for a real human to click approve, which is often enough time to spot the anomaly.

5. Use Automated Tools to Scan Your Workflows

Manual review of workflow files is valuable but does not scale. Add automated scanning to your security toolchain so problems are caught before they ever reach your main branch.

takes a different approach. Instead of analysing your workflow files, it monitors what your workflow actually does at runtime. It can detect and block unexpected outbound network connections from your pipeline steps, the kind of monitoring that would have caught the tj-actions attack sending your secrets to an attacker's server while your pipeline was still mid-run.

The principle here is the same as application security. It is always better to fail at CI than to fail in production.

6. Mirror Critical Actions and Use a Private Container Registry

For environments where the stakes are high, such as fintech, healthcare, or critical infrastructure, depending on public GitHub Actions is an unnecessary risk. The solution is to fork the Actions you depend on into your own organisation's repositories, review the code, and pin to SHAs within your fork. That way you are not dependent on an external maintainer's account security.

For container images, which are the self-contained software packages that most modern deployments are built around, use a private registry like , a self-hosted deployment platform I have been working on quietly for a while now.