How would you roll out Dependabot across 200 GitHub repositories without drowning teams?
answer
- Two programmes, not one rollout
- Signal everywhere, work where owned
- Apply settings once, not per repository
- Dismissal rules make open mean real
- Measure remediation time, not backlog size
basics
~20 sSplit the rollout in two: turn dependency graph, alerts and security updates on everywhere through an organisation security configuration, and make scheduled version updates an opt-in choice per repository with a named owner, grouping, and a cadence that team can absorb.
solid answer
~40 sTreat the advisory path and the freshness path as different programmes. **Alerts and security updates** are cheap, high-value and should be enabled organisation-wide via a security configuration applied to all repositories including new ones — that gives you inventory and a vulnerability signal everywhere. **Version updates** create sustained human work, so they are opt-in per repository, always with an owner, always with `groups:` and a cadence proportional to how actively the repository is maintained. Then govern by outcome: measure **time to remediate by severity**, not open pull-request count. Use Dependabot auto-triage rules to dismiss classes of alert you have decided not to act on, so "open" means "real". Archive or explicitly mark unmaintained repositories rather than letting them accumulate alerts nobody owns, and configure `registries:` centrally so internal packages resolve at all.
go deeper
Know that these features are switched on per repository and that an organisation can apply them broadly rather than one repository at a time.
Be able to explain why security updates scale without any per-repository file while version updates need a committed configuration, and what that difference means for a large rollout.
Show the operational plan: coverage first, credible triage second, then targeted update work with grouping and cadence matched to how maintained each repository actually is.
Own the tradeoff and the metric. Defend enabling the signal everywhere while rationing the work, name what you would archive or accept as risk, and commit to a severity-based response time that engineering has actually agreed to.
## Why this is a governance problem, not a configuration problem At one repository, Dependabot is a settings toggle. At two hundred, the constraint is human attention. Every enabled repository produces a stream of work items; if the aggregate exceeds what teams will actually do, the entire signal is discarded — including the vulnerability alerts you actually cared about. The design goal is therefore not maximum coverage of updates, it is maximum coverage of *alerts* with a *sustainable* amount of update work behind them. ## Separate the two products **Enable everywhere, unconditionally:** dependency graph, Dependabot alerts, and Dependabot security updates. The graph gives you organisation-wide inventory — when the next widely-exploited library advisory lands, the question "who uses this" is answerable in minutes instead of days. Alerts are the signal. Security updates turn alerts into small, targeted, minimum-version pull requests. None of this requires a per-repository configuration file, which is exactly why it scales. **Enable deliberately, per repository:** version updates. These require a committed `.github/dependabot.yml`, and they produce continuous work. Grant them where there is an owner who wants them. ## The mechanisms that make it stick - **Security configurations.** Define one at organisation level with the security features you want, apply it to all repositories, and set it as the default for newly created ones. This is what stops the rollout decaying the moment someone creates repository 201. - **Auto-triage rules.** Dependabot auto-triage rules let the organisation automatically dismiss classes of alert you have decided are not worth acting on — the standard example being low-impact issues in development-scoped dependencies. This is the honest version of ignoring them: the decision is written down and applied uniformly rather than each team quietly not looking. - **Grouping and cadence.** Where version updates are on, require a `groups:` block and pick a schedule that matches maintenance reality: weekly for actively developed services, monthly for stable libraries. A daily interval on a repository with one part-time maintainer is a decision to be ignored. - **Private registries.** If internal packages come from your own registry, `registries:` plus Dependabot secrets must be configured or the ecosystem simply fails to resolve and produces nothing. At fleet scale this shows up as "Dependabot doesn't work here" reported by teams who never saw an error. - **Ownership routing.** An alert with no owner is not a task. Whatever your ownership mechanism is, the rollout must answer "who gets this repository's alerts" before it turns them on, or you will centralise every finding onto one security engineer. ## What to measure Open alert count is a terrible metric: it rewards dismissal and punishes coverage. Measure instead: - **Time to remediate, bucketed by severity** — the number that actually describes exposure. - **Coverage** — proportion of repositories with a dependency graph and alerts enabled. - **Aging** — alerts older than the agreed response time for their severity, which is the real backlog. - **Merge rate of Dependabot pull requests** — if it collapses on a team, version updates there are noise and should be re-tuned or turned off rather than left to rot. ## Sequencing a real rollout A workable order: enable graph and alerts everywhere first and *do not* ask anyone to fix anything yet; spend a cycle on inventory and on writing auto-triage rules so the alert list is credible; agree severity-based response times with engineering leadership; enable security updates so the fixes arrive as pull requests rather than tickets; then pilot version updates on a handful of willing teams, refine the grouping and cadence template from what they report, and offer it as an opt-in with a supported default configuration. ## The uncomfortable parts to name Say these out loud in an interview, because they are what distinguishes a plan from a slogan. Unmaintained repositories will produce alerts nobody will fix; the honest answer is to archive them or accept the risk explicitly, not to leave the alerts open forever. Some advisories will have no patched version, so a portion of your backlog is monitoring, not work. Auto-merging patch bumps only helps teams whose required checks are trustworthy, so it is a per-repository judgement, not a fleet-wide switch. And a fleet-wide policy that engineering did not agree to is just a dashboard: the rollout succeeds on the response-time agreement, not on the toggles.
- Why enable alerts everywhere but version updates only where asked?Alerts cost almost nothing per repository and give organisation-wide inventory plus a vulnerability signal. Version updates create a continuous stream of human work; enabling them where nobody has committed to the work converts a useful bot into noise, and teams generalise that dismissal to the alerts too.
- What do you do about repositories where alerts pile up and nobody responds?Treat it as an ownership question, not a tooling one. Either the repository has an owner and needs a response-time agreement, or it does not and should be archived or explicitly accepted as risk. Leaving thousands of unowned open alerts corrodes trust in every other alert you raise.
- Why is open alert count a poor programme metric?It falls when people dismiss alerts and rises when you improve coverage, so it rewards exactly the wrong behaviour. Time to remediate by severity, plus the count of alerts aged past their agreed response time, describes actual exposure and cannot be improved by turning the scanner off.
saying these in an interview costs you the question
- Enables scheduled version updates everywhere at once
- Reports open alert count as the programme metric
- Leaves unmaintained repositories quietly accumulating alerts
- Assumes new repositories inherit settings without a default configuration
- Turns Dependabot off entirely when teams complain about noise