Complete Guide to Dependabot for Dependency Security (2026)

Dependabot connects GitHub's dependency graph with advisory alerts, minimum-patch security pull requests, and scheduled version updates. Each feature starts at a different point in the dependency lifecycle and needs its own repository setting.

Product facts and plan requirements verified against official sources on July 28, 2026.

At a Glance

What	Detail
Features	Alerts, security updates, version updates
Ecosystems	Feature-specific support matrix
Pricing	Core features free
Platforms	GitHub only
AI layer	Agent-drafted fix pull requests
Malware detection	Opt-in npm malware alerts
Main limit	Advisory-based detection

• Alerts detect CVEs, Security Updates open fix pull requests, and Version Updates keep dependencies current.
• Supported ecosystems vary across dependency graphs, alerts, security updates, and version updates.
• Those three core features are free on every repository, while custom auto-triage requires GitHub Advanced Security and AI fixes also require a Copilot plan.
• Dependabot supports GitHub repositories, with no GitLab or Bitbucket option.
• Since April 2026, you can assign an alert to Copilot, Claude, or Codex for a draft fix pull request.
• The separate npm malware alerts launched in March 2026 and remain opt-in rather than part of the CVE alert stream.
• Unreachable vulnerability alerts create real noise because this CVE database layer does not scan malicious package behavior or zero-day threats.

The Three Features

Dependabot is three separate features that share the dependency graph as their foundation. You can enable any subset of them.

Alerts

Dependabot Alerts notify you when a dependency in your graph matches a known vulnerability in the GitHub Advisory Database. GitHub reviews advisories before publication.

Alerts fire in two situations: when a new advisory is added for a package you already depend on, and when your dependency graph changes and the new state introduces a known vulnerability.

Each alert shows the severity, the affected versions, the fixed version range, and the file where the dependency is declared. The alert also indicates whether the vulnerability is reachable from your code when that information is available, though reachability analysis is not always precise.

Alerts are free on all repositories, public and private, on every GitHub plan.

Security Updates

Dependabot Security Updates are the automated follow-through on an alert. When a fix is available, Dependabot checks whether it can upgrade the vulnerable dependency to the minimum patched version without breaking the rest of the dependency graph. If it can, it opens a pull request for you.

The key phrase is "minimum patched version." Dependabot does not bump you to the latest release. It moves you to the lowest version that resolves the advisory. That keeps breaking changes to a minimum and makes the PR easier to review and merge.

A security update PR may include a compatibility score. That score is the percentage of CI runs that passed when updating between those specific versions, calculated from CI results across public repositories using the same change. It is context from other projects, not proof that the update passes this repository. Run the local test suite before merging.

When Dependabot cannot open a security update, inspect the alert and dependency path before assuming there is no remedy. A version constraint, private registry, vendored dependency, grouped update, or lockfile conflict may prevent the automated pull request while a manual change remains possible.

Keep the failed update attempt with the alert record. Note the resolver error, manifest, direct parent, available patched range, owner, and next review date. That evidence lets another maintainer continue the remediation without repeating the same dependency-graph investigation.

Security Updates are also free on all repositories.

Version Updates

Dependabot Version Updates are the non-security layer. They keep your dependencies current even when no CVE is involved, and they run on a schedule you define in a dependabot.yml file committed to .github/.

Here is a minimal starting configuration you can drop into .github/dependabot.yml:

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    groups:
      production-dependencies:
        patterns:
          - "*"
        exclude-patterns:
          - "typescript"

  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "monthly"

The groups key lets you combine related updates into a single PR rather than getting one PR per package. A broader group reduces pull-request count but increases the review and rollback unit.

GitHub Actions are a separate ecosystem with their own schedule. Review major-version changes, pin immutable commit SHAs where policy requires them, and run the repository checks before merge.

Version Updates require you to commit the dependabot.yml file, and they are free on every GitHub plan.

Dependabot applies a default three-day cooldown before opening version-update pull requests. The cooldown setting can change or disable that window when the repository's release policy needs a different delay.

The AI Layer

GitHub documents assigning a Dependabot alert to a supported AI coding agent. The agent receives the alert and repository context, then can open a draft pull request with a proposed fix. Availability depends on GitHub Code Security and a Copilot plan with coding-agent access.

GitHub warns that AI-generated fixes may be incorrect. Treat the draft as untrusted code: inspect the dependency diff, run the repository's checks, and keep the pull request behind the normal review and branch-protection rules.

This feature requires two things to be in place: GitHub Code Security (the GHAS product that covers Dependabot custom features and code scanning) and a Copilot plan that includes coding agent access. It is not available on the free GitHub plan.

Separately, Copilot Autofix applies to code scanning alerts rather than Dependabot alerts. It suggests targeted fixes for SAST findings flagged by code scanning, and it is also gated behind GitHub Code Security.

npm Malware Detection

On March 17, 2026, GitHub extended Dependabot to cover malware advisories in the npm ecosystem alongside CVE-based vulnerabilities. Malware alerting is opt-in; you enable it via a toggle in your repository, organization, or enterprise security settings.

When enabled, malware alerts appear as a distinct subcategory inside Dependabot alerts, separated from the CVE-based ones. That separation matters because the remediation is different. A CVE alert usually means bumping to a patched version. A malware alert often means the package itself is compromised and removal is the right move.

The current feature is opt-in and supports configurable rules by malware type. GitHub documents npm as the supported package ecosystem for these malware alerts. Do not infer coverage for another registry from the broader Dependabot ecosystem list.

This covers package versions that match a reviewed malware advisory. GitHub says publication can take time because reports are reviewed first. Socket can add package-behavior signals during that interval, but those signals are evidence to review rather than a universal malware guarantee.

The Noise Problem

Dependabot alerts cover every vulnerable dependency identified in the full dependency graph. GitHub's documentation does not promise that application code can reach the vulnerable function, so the queue can include findings that need more exploitability review.

Triage starts with the dependency path, affected version range, severity, exploit information, and available patch. Application ownership and call-path evidence then decide urgency. A patch remains the preferred removal of the vulnerable version when the repository can accept it.

Go teams can add govulncheck when symbol-aware reachability fits their build. npm teams can add Socket for package behavior, release signals, and install-time policy. These are different controls with different evidence, so neither is a universal equivalent for the other ecosystem.

Measure noise on the repository instead of assigning a general quality score to Dependabot. Record how many alerts are direct, transitive, patched, exploitable, accepted, or blocked by an incompatible update. That sample gives the team a defensible triage rule.

Keep one record for every dismissal or acceptance. Include the advisory, dependency path, current version, affected range, owner, compensating control, review date, and condition that reopens the decision. A free-text dismissal without an expiry can hide a changed dependency path or newly available patch.

Test auto-triage rules against known alerts before organization-wide rollout. A rule that matches severity alone can suppress a direct dependency beside an unreachable transitive one. Use the narrowest documented conditions and preserve the alert history needed to review the result.

Configure the default auto-dismiss rules for the documented low-risk cases, keep version updates active, and pair the advisory queue with a control that covers the remaining threat class.

What Dependabot Does Not Cover

Dependabot operates through the GitHub Advisory Database. It reports vulnerabilities and, when enabled for npm, reviewed malware advisories after publication. A new malicious release can therefore exist before the matching advisory reaches the repository.

The threat model it does not address well:

• Malicious packages before advisory publication. A typosquat or compromised update can reach a lockfile before GitHub publishes a matching vulnerability or malware advisory.
• Transitive unreachable vulnerabilities. Alerts fire on the full dependency graph, not on the code paths your application actually uses.
• GitLab, Bitbucket, and self-hosted repos. Dependabot is GitHub-exclusive. Repositories hosted elsewhere need a separate update and security-alert workflow.

Dependabot also does not prove that an update is compatible with the application. The compatibility score summarizes public-repository CI for a version pair, not this repository's build, runtime, or deployment. Keep local checks, review, and rollback evidence attached to every security update.

Version Updates solve a maintenance problem rather than an advisory problem. Their schedule, grouping, ignore rules, cooldown, and open-pull-request limits change the review queue. Treat those settings as repository policy and review them when ownership, release cadence, or package-manager behavior changes.

Test the handoff when no patched version exists. The alert still needs an owner, an exposure decision, a compensating control where possible, and a date to review the exception when the advisory or dependency graph changes.

For the pre-advisory supply-chain threat class, Socket operates at the package behavior level and reports signals that may exist before an advisory is published. Running both keeps the advisory queue and package-risk evidence available at separate decision points.

What Is Free vs What You Pay For

GitHub's security feature documentation confirms that core Dependabot alerts, security updates, and version updates remain available without buying GitHub Code Security. Paid controls sit on top of that baseline.

Feature	Free on all repos	Requires paid plan
Dependabot Alerts	Yes
Default auto-dismiss (low-risk alert rules)	Yes
Dependabot Security Updates (auto-PRs)	Yes
Dependabot Version Updates (dependabot.yml)	Yes
Custom auto-triage rules		GitHub Code Security (GHAS)
AI agent fix assignment		Code Security plus Copilot
Copilot Autofix for code scanning		GitHub Code Security (GHAS)

The default auto-dismiss behavior suppresses certain low-severity alerts before notification and is included without GitHub Code Security. The paid product adds custom rules that can snooze, dismiss, or trigger a security update under configured conditions. Test the rule against known alerts before applying it across an organization.

Verdict

Enable Dependabot as the GitHub baseline for known dependency advisories and update pull requests. Alerts and Security Updates cover a defined class of published vulnerability. Version Updates require a dependabot.yml file and can reduce version drift before an advisory arrives.

Tune the queue with supported triage rules and repository evidence. Start by enabling the default auto-dismiss rules so low-risk alerts stop consuming attention. Group version update PRs by dependency type when that review unit matches the repository.

Treat a low compatibility score as a signal to read the changelog before you merge, not as a reason to skip the update entirely. Review the first week of results with an assigned owner before expanding the rollout.

Add Socket when package-behavior signals or supported install-time blocking are requirements. Keep Dependabot for GitHub advisory context and security-update pull requests.

One limitation stays regardless of configuration: Dependabot is a GitHub product. If your team works on GitLab or Bitbucket, this guide is not for you. Look at Renovate for version updates and a dedicated SCA tool for security alerting.

FAQ

Do I need to configure anything to get Dependabot Alerts?

Repository administrators can enable them from the repository's Code Security settings page, or organization owners can enable them across all repositories at once. On new repositories created after a certain date, Dependabot Alerts may already be enabled by default. Check your repository's Security tab to confirm the state.

Does Dependabot update GitHub Actions workflow files?

Yes. Set package-ecosystem: "github-actions" in dependabot.yml and Dependabot can open pull requests to update action references in workflow files. Review major-version changes, resolve the release tag to an immutable commit SHA where policy requires it, and run the repository checks before merging.

Can I group Dependabot PRs to reduce the volume?

Yes. The groups key in dependabot.yml lets you combine multiple version updates into a single PR. Group by production vs development dependencies, by package name patterns, or by semantic version bump type (patch, minor, major).

Does Dependabot work on GitLab or Bitbucket?

No. Dependabot is a GitHub product. Repositories hosted only on GitLab or Bitbucket need a different update and security-alert workflow. Compare those products by supported ecosystem, advisory source, update behavior, and enforcement point.

What happens if a security update breaks my build?

The compatibility score reports how often public-repository CI passed for the same version change. It does not test your repository. Read the changelog, run your checks, and keep manual review unless an explicitly tested auto-merge rule covers that update class.

Related

• Application Security hub
• AI Code Review hub
• CodeRabbit guide

Next

• Application Security hub