Ghost in the Pipeline: CI/CD as the New Perimeter

Why modern pentesters are ignoring the app and going straight for GitHub Actions, Jenkins, and ArgoCD .

The App Is No Longer the Target

Imagine you could spend hours picking the front door lock… or you could just walk through the unlocked back door that the construction crew left open .

That’s basically what’s happening in modern hacking.

While developers are busy hardening their apps ; adding WAFs, patching CVEs, running SAST scans; attackers have quietly shifted their attention somewhere else: the CI/CD pipeline.

And honestly? It’s a goldmine.

Wait,

What Even Is a CI/CD Pipeline?

Quick refresher. CI/CD stands for Continuous Integration / Continuous Deployment. It’s the automated system that takes your code from a developer’s laptop → builds it → tests it → and ships it straight to production.

Tools like GitHub Actions, Jenkins, GitLab CI, CircleCI, and ArgoCD make this magic happen.

The problem? These systems need a LOT of trust and permissions to do their job. They need access to your cloud credentials, your secrets, your production environment, your container registry… basically everything.

They’re like the master key holder of your entire infrastructure ,and most companies treat them like a forgotten intern.

How Attackers Actually Exploit This ?!!!

Here are the most common (and scary) techniques being used in the wild:

1. Secrets Leaking in Pipeline Logs

This one is embarrassingly common.

A developer accidentally prints an env variable during debugging. The log goes to a CI system. The CI system is accessible to anyone with read access to the repo.

Suddenly, your AWS keys are just… sitting there.

echo $AWS_SECRET_KEY in a workflow file has caused more breaches than most malware.

2. Poisoning the Workflow File

In GitHub Actions, workflows live in .github/workflows/. These are just YAML files in your repo. If an attacker can open a pull request — or if your pipeline is triggered by external PRs — they can inject malicious steps directly into your build process.

This is called a pipeline injection attack. It’s elegant, low-noise, and devastatingly effective.

3. Compromising a Shared Runner

Many teams use shared CI runners (especially in GitHub’s free tier). A malicious job can leave behind artifacts, modify cached dependencies, or even persist access if the runner isn’t properly isolated. One dirty build environment can contaminate the next ten builds.

4. Dependency Confusion / Supply Chain Poisoning

Your pipeline pulls packages from npm, PyPI, or internal registries. Attackers publish a package with the same name as your internal one — on the public registry. Your pipeline picks up the wrong one. Your production build now contains malware. This is how the ua-parser-js and event-stream attacks worked.

5. Abusing ArgoCD / Kubernetes GitOps

ArgoCD syncs your Kubernetes cluster state from a Git repo. If an attacker gets write access to that repo, they can deploy anything they want to production. No exploit needed. Just a git push.

Real-World Examples (Because This Isn’t Theoretical)

SolarWinds (2020) : The most famous supply chain attack ever. Attackers compromised the build pipeline and injected malicious code into signed, legitimate software updates. 18,000 organizations were affected. The NSA was on the list.
Codecov Breach (2021) : Attackers modified a bash uploader script used inside thousands of CI pipelines to steal environment variables and secrets. Hundreds of companies were silently exfiltrated.
Travis CI (2021) : A vulnerability allowed public pull requests to access secret environment variables from forks. Developers had no idea their secrets were exposed for months.

These aren’t edge cases. This is the new normal.

Tools to Test Your Own Pipeline (Before Someone Else Does)

Here’s where it gets fun. If you’re a pentester or a security engineer, here are open-source tools to audit CI/CD security:

Recon & Discovery

Gitleaks : Scans git repos and CI logs for leaked secrets.
→ https://github.com/gitleaks/gitleaks
TruffleHog : Finds secrets buried deep in git history, S3 buckets, and CI output.
→ https://github.com/trufflesecurity/trufflehog

Attack Simulation

poutine : Analyzes GitHub Actions workflows for known vulnerable patterns (like script injection, dangerous triggers, etc.)
→ https://github.com/boostsecurityio/poutine
Semgrep : Static analysis that catches insecure workflow patterns before they hit production.
→ https://github.com/returntocorp/semgrep

Defense & Hardening

Legitify : Scans your GitHub/GitLab org settings for misconfigurations (public runners, weak branch protections, etc.)
→ https://github.com/Legit-Labs/legitify
Scorecard (by OpenSSF) : Evaluates the security posture of any open-source project, including its CI/CD hygiene.
→ https://github.com/ossf/scorecard

A Quick Pentester’s Checklist

When you’re assessing a CI/CD environment, hit these first:

Are secrets hardcoded or printed in logs?
Do workflow files accept untrusted input (like PR titles or branch names)?
Are self-hosted runners shared between projects?
Does the pipeline have more permissions than it needs? (least privilege)
Are third-party GitHub Actions pinned to a commit hash — or just a floating tag like @v1?
Is there branch protection on the repo that triggers deployments?
Who has write access to the GitOps repo?

If you can answer “no” to most of these ; Congrats, you’re in better shape than 80% of companies out there.

How to Actually Fix This

A few high-impact, practical fixes:

Pin your Actions to full commit SHAs, not tags. Tags can be moved. SHAs can’t.

uses: actions/checkout@v3 → bad

uses: actions/checkout@1e31de5234b9f8995739874a8ce0492dc87873e2 → good

Use short-lived credentials. Avoid long-lived AWS keys in secrets. Use OIDC to get temporary tokens per-run.
Limit permissions per job. GitHub Actions supports permissions: at the job level. Use it aggressively.
Separate build from deploy. Your test runner doesn’t need production cloud access. Your deploy job doesn’t need to run unit tests.
Audit your third-party Actions. That random setup-something@v2 action you added 18 months ago? Check if the repo still exists and who maintains it.

CI/CD pipelines are now the most privileged, most trusted, and most overlooked part of any modern tech stack. They have keys to everything — and most of them are running in environments that haven’t been reviewed by security in years.

Attackers figured this out. The question is whether defenders will catch up.

The perimeter didn’t disappear. It just moved to a YAML file.