# Dependabot alerts, security updates, and vulnerability-response guide: don't end at detection — operate with an SLA > A guide to operating GitHub's Dependabot alerts and security updates at production quality. Faithful to the official documentation (as of June 2026), it explains, with real code, the difference between alerts and security updates, the prerequisites for enabling them, how to prevent alert fatigue with auto-triage rules, grouped security updates, triage operations with an SLA, and observability via the REST API, including the role division between SCA and SAST/DAST. - Published: 2026-06-28 - Author: 友田 陽大 - Tags: Dependabot, サプライチェーンセキュリティ, 脆弱性管理, DevSecOps, セキュリティ, GitHub Actions - URL: https://tomodahinata.com/en/blog/dependabot-security-updates-alerts-vulnerability-management-guide - Category: Dependabot & dependency automation - Pillar guide: https://tomodahinata.com/en/blog/dependabot-production-guide ## Key points - Alerts are 'detection'; security updates are 'PRs that fix vulnerabilities with a patch.' alert → security update → merge auto-closes the alert. - Security updates have four prerequisites: dependency graph enabled, alerts enabled, a supported ecosystem, and the dependency listed in a manifest or lockfile. .gitignore'ing the lockfile is the typical miss. - auto-triage rules can auto-dismiss things like 'low-impact alerts on dev-scoped dependencies unlikely to affect production.' Rules apply before the notification, so noise is reduced at the root. - grouped security updates aggregate vulnerability fixes into one PR per ecosystem. But it doesn't mix across ecosystems or with version updates. - Introducing a tool isn't operation. It only works once you articulate the Critical/High response SLA, the handling of dev dependencies, and the dismiss criteria, and make the open count and the age of the oldest alert observable via the REST API. --- 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](/blog/dependabot-production-guide). It leaves the configuration talk (`dependabot.yml`) to the [complete configuration guide](/blog/dependabot-yml-configuration-complete-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](https://docs.github.com/en/code-security/dependabot/dependabot-alerts) 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.** 1. When **a new vulnerability is added to the [GitHub Advisory Database](https://github.com/advisories)** 2. 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): 1. **The dependency graph is enabled** 2. **Dependabot alerts are enabled** 3. **A supported ecosystem** 4. **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 `.gitignore` `package-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) - `groups` in `dependabot.yml` (`applies-to: security-updates`) to **control the granularity** (package name, dependency type, SemVer level) ```yaml # 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: ```bash # 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)](/blog/web-application-vulnerability-assessment-owasp-zap-sast-dast-guide), and AI-generated-code risk is in the [AI-generated-code vulnerability-assessment guide](/blog/ai-generated-code-vulnerability-assessment-vibe-coding-security-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.