Listen to this Post
Introduction
The software supply chain has been rocked by yet another wake-up call: over 23,000 repositories had their secrets exposed when the immensely popular tj-actions/changed-files GitHub Action was compromised through a simple yet devastating technique—rewriting a tag to point to a malicious commit. This incident underscores a critical vulnerability that plagues modern DevOps pipelines: third-party actions and dependencies are imported blindly, trusted implicitly, and never audited. As organizations rush to adopt Chainguard’s newly announced hardened GitHub Actions, security professionals must recognize that securing individual building blocks addresses only half the equation—the assembly of those blocks within your workflows remains entirely your responsibility.
Learning Objectives
- Understand the mechanics of the tj-actions/changed-files compromise and the broader risks of third-party action consumption
- Master the implementation of Chainguard’s hardened GitHub Actions and complementary scanning tools (plumber, zizmor, poutine)
- Implement defense-in-depth strategies including SHA pinning, permission restriction, and secure workflow assembly validation
You Should Know
- The Tag Rewrite Attack Vector: How 23,000 Repositories Fell
The tj-actions/changed-files compromise represents a sophisticated supply chain attack that exploited a fundamental trust model in GitHub Actions. Attackers gained control over a maintainer’s credentials or leverage a vulnerability in the action’s repository to force-push a malicious commit and reassign a legitimate tag (e.g., v35, v36, v37) to point to the compromised SHA. When workflows referenced the action using uses: tj-actions/changed-files@v35, they unknowingly pulled the malicious version.
This attack vector is particularly insidious because:
- Tag immutability is a myth: Tags in Git are mutable by default and can be force-updated
- Semantic versioning (semver) references are dangerous:
@v1,@v2, or `@v35` resolve to the latest commit tagged with that version - Dependency confusion is amplified: Popular actions become high-value targets for adversaries seeking mass impact
How to verify your current exposure:
Check for any tj-actions/changed-files usage in your workflows grep -r "tj-actions/changed-files" .github/workflows/ --include=".yml" --include=".yaml" Examine the exact SHA referenced vs the latest tag gh api repos/tj-actions/changed-files/git/refs/tags/v35 --jq '.object.sha' gh api repos/tj-actions/changed-files/commits/HEAD --jq '.sha' List all tags and their commit SHAs git ls-remote --tags https://github.com/tj-actions/changed-files.git | grep -E "v[0-9]+.[0-9]+.[0-9]+$"
Windows PowerShell equivalent:
Search for action usage across workflows Get-ChildItem -Path .github/workflows -Recurse -Include .yml,.yaml | Select-String "tj-actions/changed-files" Query GitHub API for tag information $tagSha = (Invoke-RestMethod -Uri "https://api.github.com/repos/tj-actions/changed-files/git/refs/tags/v35").object.sha $headSha = (Invoke-RestMethod -Uri "https://api.github.com/repos/tj-actions/changed-files/commits/HEAD").sha Write-Host "Tag v35 points to: $tagSha" Write-Host "HEAD points to: $headSha"
2. Chainguard Actions: Securing the Ingredients
Chainguard’s response to this epidemic is both elegant and overdue. Chainguard Actions ingests the most popular GitHub Actions from their source repositories, applies comprehensive hardening measures, and republishes them as vetted, rebuilt versions. Their approach includes:
- Source code verification: Actions are rebuilt from original source, eliminating binary blobs or pre-compiled artifacts that could conceal malicious code
- Dependency scanning: Every transitive dependency is analyzed for vulnerabilities and suspicious patterns
- Minimal runtime requirements: Actions are stripped of unnecessary permissions, filesystem access, and network capabilities
- Immutable SHA pinning: Chainguard publishes every version with a fixed SHA that never changes
Implementation guide:
BEFORE (vulnerable): jobs: security-scan: steps: - uses: actions/checkout@v4 - uses: tj-actions/changed-files@v35 Compromised AFTER (hardened with Chainguard): jobs: security-scan: permissions: contents: read pull-requests: read steps: - uses: actions/checkout@v4 - uses: chainguard-dev/actions/changed-files@sha256:abc123def456... Specific SHA
Verifying Chainguard’s hardening:
Inspect the Chainguard action's dependencies gh api repos/chainguard-dev/actions/contents/changed-files/dependencies.json Compare with the original action's dependency tree docker run --rm alpine/apk -v /tmp/analysis:/analysis \ sh -c "apk add -q curl jq && \ curl -s https://raw.githubusercontent.com/tj-actions/changed-files/main/package.json | \ jq '.dependencies' > /analysis/original-deps.json && \ curl -s https://raw.githubusercontent.com/chainguard-dev/actions/main/changed-files/package.json | \ jq '.dependencies' > /analysis/chainguard-deps.json && \ diff /analysis/original-deps.json /analysis/chainguard-deps.json"
3. Workflow Scanning: Validating Your Assembly
While Chainguard secures the building blocks, the assembly of these blocks within your workflows remains a blind spot. Tools like plumber, zizmor, and poutine serve as static analyzers that inspect your CI/CD configurations for security anti-patterns.
zizmor (GitHub Actions security scanner):
Install zizmor via cargo cargo install zizmor Scan a specific workflow zizmor .github/workflows/deploy.yml Scan all workflows with detailed output zizmor --format=json .github/workflows/ > workflow-security-report.json Check for excessive permissions zizmor --rule=permissions-write-all .github/workflows/
plumber (cross-platform CI/CD pipeline scanner):
Install plumber (available for Linux/macOS/Windows via package managers) Ubuntu/Debian curl -L https://github.com/plumber/plumber/releases/latest/download/plumber-linux-amd64 -o /usr/local/bin/plumber chmod +x /usr/local/bin/plumber Scan GitHub Actions workflows plumber scan github --path .github/workflows/ Scan GitLab CI pipelines plumber scan gitlab --path .gitlab-ci.yml Generate a security report plumber scan github --path .github/workflows/ --output=report.html --format=html
poutine (advanced pipeline behavior analysis):
Install poutine go install github.com/safedep/poutine/cmd/poutine@latest Analyze workflow for risky constructs poutine analyze .github/workflows/ Check for pull_request_target abuse poutine check --rule=no-pr-target-from-untrusted .github/workflows/
Key issues these scanners detect:
- Workflows with `write-all` or overly broad `contents: write` permissions
- Insecure use of `pull_request_target` that processes untrusted code
- Secrets exposed in `run:` steps (via `echo` or environment variables)
- Actions referenced without SHA pinning
- Checkout of untrusted code before security scanning
- The SHA Pinning Deception: Why It’s Only One Layer
A common misconception is that SHA pinning alone solves the supply chain problem. While it’s a critical control, it’s merely the first layer of defense. The attack surface extends far beyond the action reference:
The reality of SHA pinning:
- A pinned SHA protects against tag rewriting, but doesn’t prevent a maintainer from pushing malicious code to the HEAD of the repository
- If the commit SHA you’re pinned to becomes compromised (via force-push or new commit), your workflow is still vulnerable
- SHA pinning doesn’t validate that the action’s behavior remains safe—it could legitimately update to include new functionality that introduces risk
Defense-in-depth approach:
Comprehensive workflow security configuration
name: Secure Deployment
on:
push:
branches: [bash]
jobs:
secure-build:
runs-on: ubuntu-latest
Principle of least privilege
permissions:
contents: read
packages: read
security-events: write
steps:
1. Authenticate securely
- name: Authenticate with OIDC
uses: actions/github-script@sha256:abc123...
with:
script: |
const token = await core.getIDToken();
// Use token for cloud provider access
<ol>
<li>Validate action integrity (defense-in-depth)
<ul>
<li>name: Verify action SHAs
run: |
for action in actions/checkout actions/setup-1ode; do
SHA=$(cat .github/actions/${action}/sha256sum.txt)
echo "Verifying ${action} with ${SHA}"
done</li>
</ul></li>
<li>Perform actual build
<ul>
<li>uses: actions/checkout@sha256:def456...</li>
<li>uses: actions/setup-1ode@sha256:ghi789...
5. Banning pull_request_target: A Non-1egotiable Security Boundary
The `pull_request_target` event is one of the most dangerous GitHub Actions triggers when misused. It allows workflows to run in the context of the target repository (the base branch) while having access to the pull request’s source code. This design flaw enables attackers to embed malicious code in a PR that executes with elevated permissions.
Why `pull_request_target` is dangerous:
- The workflow has access to repository secrets (including deployment credentials)
- The PR’s source code is checked out without security scanning (as it’s treated as “trusted” in the target context)
- Attackers can craft PRs that inject commands via file names, branch names, or PR descriptions
Secure alternative patterns:
DANGEROUS: Using pull_request_target with checkout
on:
pull_request_target:
types: [opened, synchronize]
jobs:
vulnerable:
runs-on: ubuntu-latest
permissions:
contents: write Excessive!
steps:
- uses: actions/checkout@v4
with:
ref: ${{ github.event.pull_request.head.sha }}
- run: npm install Runs untrusted code!
SECURE: Using pull_request with separate security validation
on:
pull_request:
types: [opened, synchronize]
jobs:
validate-pr:
runs-on: ubuntu-latest
permissions:
contents: read
pull-requests: read
steps:
- uses: actions/checkout@v4
with:
ref: ${{ github.event.pull_request.head.sha }}
- name: Scan for malicious patterns
run: |
Check for suspicious commands in PR
if grep -rE "(curl.bash|wget.|.sh|eval.\$()" .; then
echo "Suspicious pattern detected in PR!"
exit 1
fi
- name: Build securely
run: |
Build in an isolated environment without secrets
npm ci
npm run build
6. Pipeline Security Checklist: A Comprehensive Audit Framework
Based on the lessons from the tj-actions incident, implement this security checklist for all your CI/CD pipelines:
Action Dependency Management:
- [ ] All third-party actions are pinned to specific SHA256 hashes (not tags or versions)
- [ ] Only actions from verified organizations (Chainguard, GitHub official, your own hardened forks) are used
- [ ] All actions are scanned for known vulnerabilities (via Dependabot or Trivy)
- [ ] Internal actions are stored in private registries with access control
Workflow Permission Hardening:
- [ ] `permissions:` block explicitly defined at job level (never inherits from workflow level)
- [ ] `contents: read` as default, only elevated when absolutely necessary
- [ ] No use of `write-all` or `security-events: write` without justification
- [ ] OIDC used instead of static secrets for cloud provider authentication
Code Review and Validation:
- [ ] `pull_request_target` only used with additional security gates (e.g., label-based authorization)
- [ ] All external contributions are reviewed manually before pipeline execution
- [ ] Secrets are never echoed or logged in `run:` steps
- [ ] `env:` variables at step level not exposing sensitive data
Continuous Verification:
- [ ] Weekly automated scanning with zizmor, plumber, or poutine
- [ ] Quarterly security training for developers on secure CI/CD practices
- [ ] Incident response plan for compromised actions
What Undercode Say
Key Takeaway 1: The tj-actions/changed-files compromise represents a fundamental shift in how we must approach GitHub Actions security. It’s not enough to trust maintainers or assume SHA pinning provides complete protection. The attack demonstrated that even with SHA pinning, if the entire action’s source code is compromised, the security model fails. The root cause is the GitHub Actions ecosystem’s architecture that conflates trust in the action maintainer with trust in the action’s behavior. This is a classic supply chain security problem magnified by the scale of GitHub’s platform.
Key Takeaway 2: Chainguard Actions is a game-changer but requires a shift in mindset from “consume and forget” to “validate and verify.” Organizations must treat their CI/CD pipelines as critical infrastructure, not just developer convenience tools. The combination of Chainguard’s hardened actions with pipeline scanning tools like zizmor provides a comprehensive defense strategy—but only if organizations actively implement both layers and continuously audit their security posture.
Analysis: The industry is witnessing a maturation in CI/CD security. The knee-jerk response to tag rewriting incidents often focuses narrowly on SHA pinning, which addresses only one attack vector. The real vulnerability lies in the workflow assembly—the logic, permissions, and secrets management that organizations control themselves. Chainguard’s approach secures the ingredients, but the chef (you) still determines whether the final dish is safe to consume. The security community must emphasize that no single control is sufficient; defense-in-depth across the entire pipeline lifecycle is the only viable approach. This includes static analysis of workflows, runtime monitoring of actions, and regular third-party audits. The incident also highlights the need for GitHub to implement stronger tag immutability features and potentially introduce action signing to prevent supply chain attacks at the platform level.
Prediction
-P The demand for Chainguard Actions and similar hardened action registries will skyrocket, creating a new market segment for “verified CI/CD components.” Organizations that adopt these solutions early will see a 70% reduction in action-related vulnerabilities within six months, positioning them as security leaders in the DevSecOps space.
-P The open-source community will develop automated migration tools that scan workflows and automatically replace vulnerable actions with Chainguard equivalents, accelerating adoption and creating a new ecosystem of “security-aware” CI/CD configurations that become the default standard.
-1 However, adversaries will quickly pivot to targeting the workflow assembly itself, exploiting misconfigurations in permissions and secrets management rather than compromised actions. This will shift the attack surface from “which action you use” to “how you configure your workflows,” requiring organizations to invest heavily in pipeline security training and static analysis tools.
-1 The cost of CI/CD security incidents will increase significantly as attackers realize the compounding impact of pipeline compromises—one breached workflow can expose production environments, source code, and customer data simultaneously, potentially leading to regulatory fines and class-action lawsuits that dwarf the operational costs of implementing security controls.
-P Over the next 12-18 months, GitHub and GitLab will introduce native action signing and verification features, incorporating lessons from the Chainguard approach. This platform-level security enhancement will finally address the fundamental trust issue in third-party actions, making it easier for developers to consume actions safely without deep security expertise.
-1 Organizations that rely solely on Chainguard without implementing workflow scanning will experience a false sense of security, leading to an increase in assembly-related breaches. The security industry will see a surge in “workflow hardening” consultancies as companies realize that securing components is only half the battle.
-P The incident will trigger a cultural shift in DevOps teams, where CI/CD pipeline security becomes a mandatory discussion in sprint planning and code review processes. This cultural change will produce long-term security benefits that extend beyond actions to encompass the entire software development lifecycle, including cloud infrastructure, application code, and third-party integrations.
▶️ Related Video (82% Match):
🎯Let’s Practice For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
IT/Security Reporter URL:
Reported By: Stephanerobert1 Devsecops – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
