Securing GitHub’s own software supply chain with Dependabot

GitHub’s internal Product Security Engineering team frequently leverages the company’s own security features to harden the platform. A recent example is the organization-wide rollout of Dependabot, which was managed to keep GitHub’s internal codebases free of vulnerable dependencies.

Keeping dependencies current is a critical part of supply chain security, a concern highlighted by incidents such as the malicious flatmap-stream package and the log4shell vulnerabilities. Dependabot helps by alerting developers when a repository relies on a known-vulnerable dependency. GitHub’s internal effort aimed to reduce this risk across all repositories, not just the ones already closely monitored.

Principles for introducing new security tooling

The Product Security Engineering team evaluates new tools against a set of guiding questions: Does the security benefit outweigh the engineering impact? How can the rollout be incremental? What are the clear expectations for engineers? For Dependabot, the answers were straightforward—it is a native GitHub feature that fits existing workflows, and the benefit of better supply chain visibility outweighs the overhead.

The rollout followed a three-phase plan: first, measure the current alert landscape; second, enable Dependabot incrementally; and third, drive remediation of open alerts across services.

Understanding the baseline

Before acting on individual repositories, the team built internal tooling to query the public GraphQL API and gather statistics on Dependabot alerts across the entire organization. This early investment in metrics allowed continuous tracking of trends before, during, and after the rollout.

Although Dependabot can be enabled org-wide from the administration page, doing so at GitHub’s scale—thousands of repositories—would have had a broad impact on engineering teams. To mitigate this, the team chose a staged rollout combined with frequent, clear communication.

Phased enablement and communication

A staged rollout reduced risk by collecting feedback from an initial set of repository owners before wider enablement. The team first shipped to 200 of the most active repositories, expanded to an additional 1,000 after 30 days, and enabled the feature organization-wide at the 45-day mark. The "automatically enabled for new repositories" setting was also turned on to ensure future repos follow best practices by default.

For a distributed, asynchronous company, communication was handled through GitHub Issues and Discussions. Announcements explicitly answered four questions: What are we doing? Why? When? And, most importantly, what does each engineer need to do? The team was clear that while repository owners were encouraged to upgrade dependencies, fixing every alert immediately was not expected. These channels also served as a prompt for related housekeeping, such as archiving unused repositories. Early adopters were welcome to enable Dependabot on their own repos ahead of the scheduled rollout.

Focusing remediation on live services

Once Dependabot was active everywhere, metrics showed the alert count was flat rather than declining. The team shifted from measurement to active remediation, leveraging GitHub’s internal Service Catalog—the authoritative record of which repositories correspond to running services, who owns them, and how to reach the owners.

Only a small subset of GitHub’s total repositories are actually deployed in production. By tying Dependabot data to the Service Catalog, the team could concentrate efforts where vulnerabilities posed real risk. Custom tooling continuously pulled alert data via the REST API and uploaded it to the catalog:

The Service Catalog supports service level objectives (SLOs) on metrics. Realistic grace periods were assigned so that service owners are not expected to fix every alert immediately; a metric is only marked failing after that window passes.

At this stage, roughly one-third of services had alerts requiring action. The team integrated these metrics into GitHub’s Engineering Fundamentals program, which tracks baseline expectations for well-maintained, available, and secure services. This program prioritizes foundational work across the company, making dependency upgrades visible against other required tasks. It also clarified the risk of keeping deprecated services running, prompting some owners to accelerate shutdowns.

The Engineering Fundamentals program anchors on a monthly synchronous meeting with engineering leadership and service owners. Each month, realistic four-week goals are set and progress is reviewed. This turned the broad mandate of “fix all alerts” into a structured, measurable effort over several months, with Dependabot metrics as a quarter-long focus for engineering teams.

Results and ongoing use

The focused effort produced measurable results. The percentage of services with zero Dependabot alerts rose from 68% to 81%, meaning roughly 50 core services were remediated within three months, including several large Rails upgrades. Because the Engineering Fundamentals program runs continuously, this is not a one-off achievement; alert metrics are tracked over time and intervention happens if trends regress.

Following the Dependabot rollout, the same approach has been applied to other GitHub Advanced Security features, including CodeQL. By aggregating more sources of security alerts into the program, GitHub gains a fuller picture of service health across the company, enabling clearer prioritization of security work.

The experience of measuring organization-wide metrics internally influenced product design as well. Feedback from this rollout informed the Security Overview feature, which gives GitHub Enterprise users a consolidated view of Advanced Security alerts across their own organizations.