Satisfied after installing a vulnerability scanner, while the alert badge stays in the double digits and no one looks — this is the most common failure in security operations. Dependabot's alerts are merely detection. Value emerges only after "detection → triage → fix → close" starts running with an SLA.
This article focuses on vulnerability response as a topic of the Dependabot production-operations guide. It leaves the configuration talk (dependabot.yml) to the complete configuration guide and digs into the operation of alerts, security updates, and triage here.
Rules for this article: feature names and prerequisites are based on the GitHub official documentation (as of June 2026). Since vulnerability response is an area heavily affected by spec changes, always confirm the latest in the official Dependabot alerts documentation before production operation.
1. Alerts and security updates are "detection" and "fix"
| Dependabot alerts | Dependabot security updates | |
|---|---|---|
| Role | Detection: notify of vulnerable dependencies | Fix: auto-generate a PR to fix vulnerabilities with a patch |
| Target | All vulnerable dependencies in the dependency graph | Those of which a fixed version exists |
| Code change | No | Yes (updates the manifest / lockfile) |
| How to enable | ON in security settings | ON in security settings (alerts as a prerequisite) |
What generates an alert — per the official docs, two triggers.
- When a new vulnerability is added to the GitHub Advisory Database
- When you push a commit that updates the repository's dependencies (the dependency graph changes)
GitHub continuously scans the default branch. An alert includes a link to the affected file, the vulnerability's details and severity, and (if any) the fixed version.
And what's nice operationally is auto-close: "when a Dependabot security-update PR is merged, the corresponding alert is auto-closed." There's no incident of forgetting to close it by hand.
2. Enabling and prerequisites (miss these and "no PRs come")
The four conditions for security updates to work (official):
- The dependency graph is enabled
- Dependabot alerts are enabled
- A supported ecosystem
- The dependency is listed in a manifest or lockfile
Where to configure:
- Per repository: turn alerts and security updates ON in Settings → Advanced Security (Code security).
- Per organization: apply defaults to all repositories in Global settings (Advanced Security). Here if you want it to auto-apply to new repositories too.
The most common pitfall: "the security update doesn't meet prerequisite 4." For example, if you
.gitignorepackage-lock.json, it doesn't meet the official "listed in a manifest or lockfile" and falls out of the update target. Commit the lockfile.
3. auto-triage rules: cut alert fatigue at the root
As detection grows, alert fatigue kills operations next. auto-triage rules is a mechanism that auto-dismisses/snoozes alerts before the notification flies.
3.1 GitHub presets
Rules curated by GitHub. Representative examples:
- Dismiss low impact issues for development-scoped dependencies: auto-dismiss low-impact alerts on npm dev dependencies unlikely to affect production.
- Dismiss package malware alerts: auto-dismiss malware judgments (disabled by default).
An important property: rules apply before the notification, so an alert auto-dismissed at creation doesn't even send a notification. This is the essence of noise reduction. Not "filter the notification later" but "don't raise it at all."
3.2 Custom rules
You can create your own rules matching on metadata like severity, scope (dev/prod), package name, and CWE per the organization's policy. Examples:
- "Auto-dismiss Low/Medium alerts on dev dependencies (development scope), keep production dependencies."
- "Snooze alerts on specific allowed packages."
Custom rules are available on public repositories and on organization repositories with GitHub Code Security enabled.
Design guideline: limit auto-dismiss to things you can argue 'don't affect production.' "Dismiss everything because it's annoying" erases the meaning of detection. Start from dev scope and low impact, and make it an operation where the reason you dismissed is left in the log.
4. grouped security updates: bundle fix PRs
When multiple vulnerabilities come at once, PRs arrive one by one and review breaks down. grouped security updates aggregate multiple vulnerability fixes into one PR per ecosystem.
There are three places to configure:
- The repository's Advanced Security settings
- The organization's Global settings (Advanced Security)
groupsindependabot.yml(applies-to: security-updates) to control the granularity (package name, dependency type, SemVer level)
# dependabot.yml — セキュリティ更新を1PRにまとめる例
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "daily"
groups:
security:
applies-to: security-updates
patterns: ["*"]
Official constraints (remember these):
- It doesn't group across different ecosystems.
- It doesn't mix security updates and version updates in the same PR.
5. Triage operations with an SLA (the heart of operations design)
From here it's about operations, not the tool. If you claim world-class, articulate the following.
5.1 Decide an SLA per severity
| Severity | Response SLA (example) | Policy |
|---|---|---|
| Critical | Within 1–2 business days | Top priority. Patch & deploy immediately if possible |
| High | Within 5 business days | Respond without waiting for the next sprint |
| Medium | At the next regular update | Ride the version-update wave |
| Low / dev-scope | Consider dismiss via auto-triage | Suppress if production impact can be argued |
The numbers change with the organization's premises (public service or internal, regulated industry). What matters is "don't leave it ambiguous."
5.2 What to do with unfixable vulnerabilities
A vulnerability with no fixed version yet doesn't get a security-update PR. The options you can take then:
- Snooze: record the decision to wait until a fix comes out.
- Mitigation: block the reachable path (disable the relevant feature, add input validation, a WAF rule).
- Migrate to an alternative library: if it's a Critical you can't leave alone with no prospect of a fix, replace the dependency itself.
Triage is not "leave it because it can't be fixed" but leaving a decision.
6. Observability: make the unresolved "visible"
A running operation needs measurement. Since Dependabot alerts can be exported via the REST / GraphQL API, dashboard the following metrics.
- The number of open (unresolved) alerts (by severity)
- The age of the oldest alert (an early warning of SLA violation)
- The average dwell time of security-update PRs
A minimal example of fetching a repository's alerts via the REST API:
# Critical / High の未対応アラートだけを抽出
gh api \
-H "Accept: application/vnd.github+json" \
"/repos/{owner}/{repo}/dependabot/alerts?state=open&severity=critical,high" \
--jq '.[] | {number, severity: .security_advisory.severity, package: .dependency.package.name, ghsa: .security_advisory.ghsa_id}'
If you want to aggregate across an organization, use /orgs/{org}/dependabot/alerts and flow the result to BI / a spreadsheet / a Slack notification. A state where you can see at a glance "whether the unresolved keeps increasing" is the last bastion against becoming a formality.
7. Don't mistake Dependabot's scope (SCA ≠ SAST/DAST)
This is a point frequently misunderstood even in project consultations.
- What Dependabot sees is known vulnerabilities in "dependencies (SCA: Software Composition Analysis)." It detects CVEs/GHSAs attached to libraries like npm/pip/gem by matching against the Advisory Database.
- Vulnerabilities in the code you wrote — SQL injection, XSS, SSRF, broken authorization (IDOR), secret leakage — are outside Dependabot's scope and are the domain of SAST (static analysis) / DAST (dynamic testing).
The two are complementary. Automate the supply chain (dependencies) with Dependabot, and diagnose the app's own logic with SAST/DAST. This full picture is in the practical guide to web-app vulnerability assessment (SAST/DAST/SCA), and AI-generated-code risk is in the AI-generated-code vulnerability-assessment guide. "We're safe because we put in Dependabot" is only half right — being able to explain this boundary to the buyer leads to trust.
8. FAQ
Q. Alerts come out but no security-update PRs come. A. It's highly likely that no fixed version exists for that vulnerability, or that one of the prerequisites (dependency graph, alerts enabled, target ecosystem, manifest/lockfile listing) isn't met.
Q. There are too many alerts to look through.
A. Start with auto-triage rules to "auto-dismiss low-impact alerts on dev dependencies," and bundle fix PRs with grouped security updates. Since it's suppressed before the notification, noise is reduced at the root.
Q. Can I increase the number of concurrent security-update PRs?
A. The open-pull-requests-limit for security updates is fixed at 10 and can't be changed. The design is "don't let vulnerability fixes pile up."
Q. Isn't auto-dismiss dangerous? A. Limited to things you can argue don't affect production, it's effective noise reduction. Start from dev scope and low impact, and make it an operation where the dismiss reason is left.
Q. Is Dependabot alone enough for security? A. No. Dependabot sees dependencies (SCA). Vulnerabilities in your own code need SAST/DAST. Only with both wheels does it become defense in depth.