Scaling vulnerability management across thousands of services and more than 150 million findings

From scattered tooling to a single pipeline

GitHub’s security organization operates across a large, mixed infrastructure spanning multiple cloud providers and data centers. Each asset carries its own risk profile, and the team’s findings historically lived in bespoke per-team processes. A security analyst who uncovered a vulnerability would document and track it using whatever workflow their group happened to maintain. That approach produced two structural problems.

First, it created significant operational overhead: teams repeatedly built overlapping automation and lost time to context switching between remediation work and tool maintenance. Second, it produced an inconsistent developer experience. A service owner might see one finding auto-updated, while another required a chat intervention and a third needed manual effort, depending on which security group had filed it. The cumulative result was difficulty measuring program effectiveness, constrained scalability and a higher chance of human error.

What the replacement had to do

When GitHub set out to replace this patchwork, the team applied the same user-centric principles used in building GitHub Advanced Security (GHAS). Five requirements drove the design:

• Automation of repeatable steps to reduce context switching and eliminate manual delay or mistakes.
• Broad intelligence ingestion from GHAS, the internal Bug Bounty program, third-party cloud security posture management platforms, and container scanners—with room for the security tooling landscape to shift.
• Just-in-time context that goes beyond patch status to supply curated signal such as exploitation likelihood and material business impact.
• Clear ownership for every finding so accountability and next steps are unambiguous.
• On-demand analytics to steer mitigation decisions.

The choice was a custom-built platform called Security Findings, which ingests and normalizes data from all those sources, creates actionable findings and manages their full lifecycle.

Consolidating every source into one place changed what the team could do with the data. Deduplication removed the noise created by overlapping detection capabilities across vendors. If a security tool is deprecated or swapped out, the transition now affects only the Security Findings integration layer, not engineering teams downstream. Security staff get a single view of open findings per service regardless of origin, and the aggregated data supports mining operations that identify technical debt hotspots and the best returns on new safeguards.

UX and access control

Security Findings was built with a dynamic UI that renders different views depending on the deployment context. Engineers tackling a containerized application see vulnerable images and their deployment locations; the same finding against a datacenter VM surfaces IP addresses and hostnames instead. Managers can pull a high-level org status while an engineer drills into a single finding. The framework is structured so new scenarios can be added as they appear.

Access is governed by role-based access controls, restricting users to findings about services they own. That granularity also lets GitHub honor Traffic Light Protocol constraints, including TLP:Red, where visibility is limited to a very small group.

Security Findings also lives inside the developer workflow rather than apart from it. Because GitHub is already the platform where engineering work happens, findings plug into GitHub Issues so teams can @mention owners and manage remediation alongside their normal work, and CI results surface live scan status without any tool switch.

Exceptions become first-class data

As finding volume grew, the original approach to security exceptions—false positives, remediation extensions and risk acceptances—broke down. Exceptions stored in YAML files were hard for non-YAML users to work with, and reporting and lifecycle management were difficult. GitHub folded exceptions into Security Findings to create one end-to-end experience.

Service owners get a comparable list view for exceptions against their services, which is especially useful when inheriting a service from a colleague or onboarding to a new scope: the security posture is assessable immediately. For long-running remediation extensions, owners record monthly milestones indicating whether they are on track, which keeps an active conversation going and distributes accountability. Approvals themselves are captured through pull requests; required approvers are calculated per exception from factors such as exception type and risk level.

For more urgent notification, Slack is integrated into Security Findings—reminders about upcoming exception milestones or state changes for current findings arrive as simple Slack messages.

Scale achieved and next steps

GitHub continuously scans images, virtual machines, cloud resources and other assets to keep everything in view. Since Security Findings went live, it has processed over 150 million findings, each passing through automated analysis and, where needed, manual triage to enrich it and decide whether action is warranted.

The shift away from bespoke processes has changed how the security team functions: analysts focus on critical work and set context, developers get the finding details they need without leaving the tools they already use, and the program has become measurable and expandable in a way the earlier ad hoc tooling never was.