In GitHub, how do Dependabot security updates differ from version updates?

## Two features, one bot Dependabot shows up in a repository as one bot account opening pull requests, which is why candidates often merge the two ideas. They are configured, triggered, and scoped differently. ## Security updates The trigger is a **Dependabot alert**: a package/version in the dependency graph matched an advisory in the GitHub Advisory Database. If security updates are enabled, GitHub attempts to open a pull request that raises that dependency to the **lowest version that is no longer in the vulnerable range** — deliberately the smallest jump that fixes the problem, so the blast radius stays small. Important properties: - No `dependabot.yml` is needed. Alerts plus the toggle are enough, which is why a repository with no configuration file can still receive Dependabot pull requests. - A fix requires a patched version to exist. If the advisory has no fix, you get an alert and no pull request. - For a transitive dependency, the bump may have to happen in the intermediate package, and Dependabot can only open a PR if the ecosystem lets it express that. - Security PRs describe the advisory, its severity, and the range being escaped. ## Version updates The trigger is a **schedule you declare**. Version updates exist only if `.github/dependabot.yml` is committed on the default branch. Each element of `updates:` is one job: which ecosystem (`npm`, `maven`, `gradle`, `pip`, `docker`, `github-actions`, `gomod`, `nuget`, `bundler`, `cargo`, and others), which `directory` the manifest lives in, and how often to run via `schedule.interval` (`daily`, `weekly`, `monthly`). Options on the same entry shape the output: `open-pull-requests-limit` (default 5) caps how many version-update PRs stay open at once, `target-branch` sends them somewhere other than the default branch, `labels` and `milestone` route them, `commit-message` controls the subject prefix, and `versioning-strategy` decides whether a manifest range is widened, increased, or left alone with only the lockfile moving. Version updates do not care about advisories. Their value is that being current is what makes a future security bump a one-line change instead of a migration project. ## Why the distinction matters operationally The common failure is a team that disables Dependabot because "it opens too many PRs", not realising they have just turned off their vulnerability-response path along with the noise. The right move is almost always: keep alerts and security updates on everywhere; make version updates a deliberate, tuned, per-repository choice with grouping and a sensible cadence. The second distinction that matters is the pull-request limit. `open-pull-requests-limit` governs version updates; security fixes are not meant to be starved by a backlog of routine bumps, so a repository sitting at its version-update limit should still see security work surface. If you want to be precise in an interview, say that the limit is a version-update control and that you would not rely on it to throttle security fixes. ## Enabling Both features are switched on per repository under the security settings, and organisations can apply them across many repositories at once through a security configuration. Security updates depend on alerts, which depend on the dependency graph — the chain is graph → alerts → security updates. Version updates depend only on the config file being present and parseable; a malformed `dependabot.yml` shows up as an error on the repository's Dependabot page and silently means nothing runs. ## Private registries Both kinds of update need to be able to resolve your dependencies. If the project pulls from an internal registry, a top-level `registries:` block declares it (with credentials stored as Dependabot secrets, which are separate from Actions secrets) and each `updates:` entry references it. Without that, Dependabot fails to resolve and quietly produces nothing for that ecosystem — a very common reason teams believe the feature is broken. ## The interview answer Summarised: security updates are event-driven, advisory-scoped, minimum-viable bumps, and need no file. Version updates are schedule-driven, breadth-scoped, and need `dependabot.yml`. Run both, and tune only the second one when the noise gets bad.