Mastering Git Hub Security Campaigns Scaling Remediation Across Hundreds of Repositories
Back to blog
What Is a GitHub Security Campaign?
Step-by-Step: How to Launch a Security Campaign
Step 1: Define a Focused Goal and Scope
Step 2: Create the Campaign
Step 3: Campaign Managers Own the Communication
Step 4: Developers Execute the Fixes
Step 5: Track Progress and Close the Campaign
What's Changed Recently (2026)
The Real Gap: Visibility Isn't Enforcement
Conclusion
Sources
Mastering GitHub Security Campaigns: Scaling Remediation Across Hundreds of Repositories
In the modern enterprise software landscape, security engineering is rarely a game of finding a single, isolated bug. More often, it's a logistical challenge. A routine audit — or a new CVE like the Log4j flaw — reveals a systemic issue that doesn't live in one application, but across hundreds of distributed repositories and microservices.
For years, the default response was the "ticket cannon": security teams scripting hundreds of individual Jira tickets and firing them at engineering squads. The result was predictable — alert fatigue, duplicated effort, no shared view of burn-down progress, and missed deadlines.
GitHub built a native answer to this problem directly into GitHub Advanced Security: security campaigns, a feature for grouping related alerts into a single, trackable remediation effort instead of a scattershot of tickets. Below is a current, verified walkthrough of how the feature works, what's changed recently, and where its limits are.
What Is a GitHub Security Campaign?
A security campaign is a way to group code scanning or secret scanning alerts and share them with developers so a security team and engineering can collaborate on remediation, rather than treating every alert as an isolated incident.
Security campaigns are part of GitHub Code Security (for code scanning alerts) and are also available, in public preview, for secret scanning alerts. The feature reached general availability for code scanning campaigns in 2025, and GitHub has continued shipping refinements since — including draft campaigns and automated issue creation, which let security managers build out a campaign's scope privately before making it visible to developers.
A campaign is useful when:
Multiple repositories share the same vulnerable dependency or pattern (a Log4j-style event, or a specific CVE).
An organization needs to drive a coordinated dependency upgrade across many teams at once.
Compliance or audit deadlines require a documented, time-bound remediation effort with a named point of contact.
Security leadership wants a single dashboard tracking debt reduction instead of dozens of untracked tickets.
You're not limited to one campaign at a time — a security team can run several concurrently (for example, one for a dependency upgrade, another for exposed secrets, another for a specific vulnerability class), each with its own scope, owners, and deadline.
Step-by-Step: How to Launch a Security Campaign
Step 1: Define a Focused Goal and Scope
"Fix all vulnerabilities" isn't a campaign. "Upgrade every instance of a specific vulnerable library to a patched version across our Java services" is. Before touching the GitHub UI, decide:
Scope — organization-wide, a set of repositories affected by one vulnerability class, or repositories owned by a specific team.
Timeline — a concrete due date, not an open-ended goal.
Success threshold — e.g., resolving a defined percentage of included alerts by the deadline.
Step 2: Create the Campaign
Campaigns are created and managed from the Security and quality tab at the organization level (organization owners, security managers, and org members with the admin role can do this). From there:
Go to your organization's Security and quality tab → Campaigns → Create campaign.
Choose the alerts to include, either with a campaign template (pre-built filters for common cases — GitHub ships templates based on lists like MITRE's Top 10 Known Exploited Vulnerabilities) or by selecting alerts manually. For code-scanning campaigns, templates only surface alert types that Copilot Autofix supports.
Set a campaign due date.
Assign one or more campaign managers — these must be users or teams that already hold owner or security-manager permissions in the organization — as the named point of contact.
Optionally add a contact link (e.g., a GitHub Discussions thread) so developers have somewhere to ask questions.
Save it as a draft first if you want to refine scope before anyone sees it, then use Review and publish when it's ready. For code campaigns, you can optionally have GitHub auto-create a tracking issue in each affected repository.
Step 3: Campaign Managers Own the Communication
The campaign manager isn't just a label on a dashboard — it's the accountable contact who reviews pull requests, answers developer questions, and keeps the campaign moving. A campaign with no engaged owner tends to stall regardless of how well it's scoped.
Step 4: Developers Execute the Fixes
Once published, affected developers see the campaign in their normal workflow — via the repository's Security tab or a link in the campaign notification email. From there:
Clicking an alert shows the vulnerable code and, where available, a Copilot Autofix suggestion.
If a fix is already available and the Copilot coding agent is enabled for the repository, alerts can be assigned directly to it — the agent explores the codebase, generates a fix, validates it, and opens a pull request with the developer added as a requested reviewer.
Before starting manual work, developers can check for git status icons on each alert (draft PR, open PR, active branch) to avoid duplicating another developer's in-progress fix.
Where an autofix suggestion exists, a developer can apply it directly via Commit autofix.
GitHub reports that Copilot Autofix has cut mean time to remediation by up to 60% compared with manual fixes, based on internal analysis shared in its 2025 announcement of general availability for security campaigns.
Step 5: Track Progress and Close the Campaign
Throughout the campaign window, the security team monitors the same security overview dashboard used for the org's broader risk posture — tracking percentage remediated, resolved-vs-active ratios, and per-repository completion. Campaign data can be exported to external BI tools for executive reporting. Once the campaign hits its resolution threshold, the security team closes it out.
What's Changed Recently (2026)
A few developments worth knowing if you're planning a campaign now:
Secret scanning campaigns are in public preview — the same grouping-and-tracking model now extends to leaked credentials, not just code-scanning findings, though the feature is still subject to change.
GitHub Advanced Security is no longer one bundle. Since April 2025, it's sold as two separate, per-active-committer add-ons: GitHub Code Security (US$30/active committer/month — includes CodeQL scanning, Copilot Autofix, security campaigns, and Dependabot features) and GitHub Secret Protection (US$19/active committer/month — push protection, secret scanning, AI-assisted password detection). Both are available to organizations on the GitHub Team plan, not just Enterprise.
Secret scanning has moved earlier in the workflow. As of May 2026, secret scanning through the GitHub MCP Server is generally available, letting an MCP-compatible AI coding agent (e.g., in VS Code or Copilot CLI) check a diff for exposed credentials before a commit is even made.
Public Monitoring (public preview, launched July 2026) extends enterprise secret scanning beyond an org's own repositories — GitHub now watches all of GitHub.com's public content and attributes any matching leaked credential back to the owning enterprise, at no extra cost for Enterprise Cloud customers with Secret Protection.
The Real Gap: Visibility Isn't Enforcement
GitHub's tooling solves the how of remediation extremely well — grouping alerts, generating fixes, and giving developers a single place to work. What it doesn't do natively is force a deadline to matter. A campaign due date is a target on a dashboard; whether it survives contact with a sprint planning meeting depends entirely on the organization's own process discipline. When a feature deadline and a security campaign deadline compete for the same developer's time, the security work is the one that's easiest to quietly slip.
That's the gap that has created a small market of third-party tools that sit on top of GitHub's native security alerts and add explicit ownership, deadlines, and escalation — treating remediation as tracked, accountable work rather than an item in an alert feed.
One example is InstaSLA, a GitHub-native SLA management tool. Based on its published feature set, it lets teams:
Assign individual security alerts to a person, team, or repository owner, with an audit trail of assignment changes.
Apply severity-based remediation deadlines (critical, high, medium, low) and see breach status in a live queue.
Group repeated, duplicate package advisories across repositories into coordinated fix campaigns.
Configure email reminders and escalation policies as deadlines approach.
Export remediation history — including risk-acceptance records — for SOC 2 or ISO 27001 audit evidence.
That's a genuinely different layer from what GitHub ships natively, but it's worth being precise about what it is: an alert-ownership and reporting layer, not a replacement for GitHub's scanning or fix tooling, and — per its own public documentation — it doesn't claim to block deployments or CI/CD pipelines on an SLA breach. If automated deployment gating on unresolved security debt is what you're after, that's a policy you'd need to build separately (e.g., via a required status check tied to your own tracking system), not a feature to assume any SLA tool ships out of the box. It's also one option among a broader category of vulnerability-management and GRC tools that integrate with GitHub's alert APIs — worth evaluating against your specific compliance and workflow needs rather than treating as the only choice.
Conclusion
GitHub Security Campaigns solve the coordination problem that made mass remediation so painful — no more spray of disconnected tickets, no more guessing who owns what. Combined with Copilot Autofix and, increasingly, the coding agent, GitHub has made the fix itself fast. The remaining work for most security teams is organizational: turning a campaign due date into something engineering leadership actually plans around, whether that's through internal process, a dedicated SLA/ownership tool, or both.
Sources
GitHub Docs — About security campaigns
GitHub Docs — Creating and managing security campaigns
GitHub Blog — Found means fixed: Reduce security debt at scale with GitHub security campaigns
GitHub Changelog — Introducing GitHub Secret Protection and GitHub Code Security
GitHub Changelog — Secret scanning with GitHub MCP Server is now generally available
GitHub Docs — Managing security managers in your organization
InstaSLA — Features
Top comments (0)