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

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:

1. Scan - Runner Guard identifies findings with rule ID, file, line number, severity, and affected action reference
2. Generate fix - The autofix engine resolves the finding (currently: SHA pinning for RGS-007, the 74.5% majority)
3. Submit PR - An automated PR is created with:
4. What was found (rule ID, description, severity)
5. Why it matters (attack scenario, blast radius)
6. The exact fix (diff showing the change)
7. How to verify (run Runner Guard locally to confirm)
8. 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 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