GitHub 20 🌐 GitHub Dependabot and Automated Security Alerts - KandZ

⏱️ Estimated read: 9 min | |

Dependabot is not a single feature. It is three distinct mechanisms that share a common foundation: the dependency graph. Dependabot alerts notify you when a dependency in your project has a known vulnerability. Dependabot security updates automatically open pull requests to fix those vulnerabilities. Dependabot version updates keep dependencies current even when no vulnerability exists, reducing the window of exposure when a new CVE is published . The dependency graph is the prerequisite for all three. It is enabled by default on public repositories and must be activated manually on private ones .

Key point: Alerts notify. Security updates fix. Version updates maintain. The configuration file .github/dependabot.yml is only required for version updates. Alerts and security updates are toggled in repository settings and do not require a YAML file.

Why Dependabot exists

The inherited vulnerability problem. Every dependency you add to a project brings its own dependencies, and those bring theirs. A vulnerability in a transitive dependency—a package you never directly imported—is still a vulnerability in your application. Dependabot reads the dependency graph, cross-references it against the GitHub Advisory Database, and creates an alert when a match is found .

The manual tracking problem. Without automation, tracking CVEs for every dependency in a project is a full-time job. A new advisory is published, and someone must check whether the affected version is in use, whether a patch exists, and whether upgrading breaks anything. Dependabot automates the detection and, with security updates enabled, the remediation .

The version drift problem. Security updates only trigger when a vulnerability exists. A project can run on outdated, unsupported versions for years if no CVE is filed against them. Version updates keep dependencies current on a schedule, which reduces the blast radius when a vulnerability is eventually discovered. The default cooldown of three days allows new releases to stabilize before Dependabot proposes them .

The noise problem. A repository with fifty dependencies can generate a flood of pull requests. Dependabot provides controls: open-pull-requests-limit caps the number of concurrent PRs, ignore rules suppress updates for specific dependencies or version ranges, and dependency groups combine related updates into a single PR .

The trade-off. Dependabot reduces manual effort but does not eliminate review. Every pull request it creates must be reviewed, tested, and merged. Auto-merge can handle low-risk updates, but only after CI passes and the team has configured the conditions under which merging is safe .

a. Enabling alerts and security updates

Alerts and security updates are toggled in the repository’s security settings. The dependency graph must be enabled first; on public repositories, it is enabled by default.

Settings → Security and analysis → Dependabot alerts → Enable
Settings → Security and analysis → Dependabot security updates → Enable

When alerts are enabled, GitHub scans the dependency graph against the GitHub Advisory Database. When a match is found, an alert appears in the Security tab with the severity, the affected package, the vulnerable version range, and the patched version . The severity levels are derived from CVSS scores: Critical (9.0–10.0), High (7.0–8.9), Medium (4.0–6.9), and Low (0.1–3.9) .

When security updates are enabled, Dependabot opens a pull request that updates the vulnerable dependency to the minimum version that resolves the vulnerability. The PR description includes a link to the advisory, the changelog, and the compatibility score .

Organization administrators can enable both features across all repositories from the organization’s security settings .

b. Configuring version updates with dependabot.yml

Version updates require a configuration file at .github/dependabot.yml. The file specifies the package ecosystems to monitor, the directories containing the manifest files, and the update schedule.

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 10
    reviewers:
      - "team/frontend"
    labels:
      - "dependencies"

The package-ecosystem field accepts values for every supported ecosystem: npm, pip, cargo, bundler, maven, gradle, nuget, gomod, composer, pub, docker, github-actions, and others . The directory field points to the location of the manifest. The schedule.interval accepts daily, weekly, or monthly .

The ignore option suppresses updates for specific dependencies or version ranges. This is useful for pinning a dependency that is known to break at a certain version.

    ignore:
      - dependency-name: "lodash"
        versions: ["4.x"]

The open-pull-requests-limit caps the number of open PRs. The default is 5; the maximum is 10 . The reviewers, assignees, labels, and commit-message options control the metadata applied to each PR .

Multiple ecosystems can be configured in the same file. Each entry is independent and has its own schedule and directory.

c. Reviewing and responding to alerts

An alert is not a fix. The Security tab shows the list of open alerts, and each alert links to the advisory, the affected manifest, and the security update PR if one has been created.

Security → Dependabot alerts → [alert] → See advisory

The alert page displays the severity, the CVSS vector, the CWE classification, the CVE identifier, and the GitHub Advisory Database (GHSA) identifier. If a security update PR exists, a “Review security update” button appears .

Merging a security update follows the same workflow as any pull request: review the diff, confirm CI passes, and merge. For low-risk updates—patch versions with passing tests—auto-merge can be configured. A GitHub Actions workflow can enable auto-merge on Dependabot PRs after required checks pass .

Alerts can be dismissed with a reason: “fix started,” “no bandwidth,” “not used,” or “tolerable risk.” Dismissing an alert does not remove it from the audit trail; it removes it from the open list .

Complete Example Session

# ============================================
# PART 1: ENABLE ALERTS AND SECURITY UPDATES
# ============================================

# Navigate to Settings → Security and analysis
# Enable "Dependabot alerts"
# Enable "Dependabot security updates"
# The dependency graph is enabled automatically.

# ============================================
# PART 2: VIEW AN ALERT
# ============================================

# Navigate to Security → Dependabot alerts
# Click the alert for "lodash" with severity "High"
# The alert shows:
#   Vulnerable version: < 4.17.21
#   Patched version: 4.17.21
#   Advisory: GHSA-35jh-r3h4-6jhm

# ============================================
# PART 3: REVIEW THE SECURITY UPDATE PR
# ============================================

# If security updates are enabled, a PR exists.
# Click "Review security update"
# Review the diff: package.json and lockfile changed.
# CI runs automatically.

# ============================================
# PART 4: CREATE dependabot.yml
# ============================================

mkdir -p .github
cat > .github/dependabot.yml <<'EOF'
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 5
EOF

# ============================================
# PART 5: COMMIT AND PUSH
# ============================================

git add .github/dependabot.yml
git commit -m "Add Dependabot version updates config"
git push origin main
# Dependabot begins monitoring on the next schedule.

# ============================================
# PART 6: ADD A SECOND ECOSYSTEM
# ============================================

# Append to dependabot.yml:
#   - package-ecosystem: "docker"
#     directory: "/"
#     schedule:
#       interval: "weekly"

# ============================================
# PART 7: IGNORE A SPECIFIC DEPENDENCY
# ============================================

# Add under the npm entry:
#     ignore:
#       - dependency-name: "lodash"
#         versions: ["4.x"]

# ============================================
# PART 8: CONFIGURE AUTO-MERGE
# ============================================

# Create .github/workflows/auto-merge.yml
# Triggers on pull_request
# Condition: github.actor == 'dependabot[bot]'
# Runs: gh pr merge --auto --squash

The eight parts trace the lifecycle: enabling alerts, reviewing an alert, reviewing the security update PR, creating the configuration file, committing, adding a second ecosystem, suppressing a dependency, and configuring auto-merge.

Quick Reference

Dependabot Features

Feature	Trigger	Configuration
Alerts	Vulnerability found	Settings toggle
Security updates	Alert with available patch	Settings toggle
Version updates	Schedule	`.github/dependabot.yml`

dependabot.yml Keys

Key	Purpose
`package-ecosystem`	Package manager (`npm`, `pip`, `cargo`)
`directory`	Location of manifest files
`schedule.interval`	`daily`, `weekly`, `monthly`
`open-pull-requests-limit`	Max concurrent PRs (default 5)
`ignore`	Suppress updates by name/version
`reviewers`	Auto-assign reviewers
`labels`	Auto-apply labels

Severity Levels

Level	CVSS Range
Critical	9.0–10.0
High	7.0–8.9
Medium	4.0–6.9
Low	0.1–3.9

Best Practices

✅ Do This:

open-pull-requests-limit: 5
<!-- Cap PR volume to avoid maintainer overload -->   # ✅

reviewers:
  - "team/security"
<!-- Route dependency PRs to the right reviewers -->  # ✅

ignore:
  - dependency-name: "lodash"
    versions: ["4.x"]
<!-- Suppress known-breaking updates -->             # ✅

❌ Don’t Do This:

# Enable version updates without configuring limit
<!-- Flood of PRs overwhelms maintainers -->         # ❌

# Merge security updates without CI passing
<!-- The patch may break the application -->         # ❌

# Assume alerts are enabled on private repos
<!-- They require manual activation -->              # ❌

Common Pitfalls

Pitfall	Why It Happens	Fix
No alerts on private repo	Alerts not enabled	Enable in Settings → Security
No security update PR	Security updates not enabled	Enable separately from alerts
Too many PRs	No `open-pull-requests-limit`	Set limit in `dependabot.yml`
Version updates not running	No `dependabot.yml`	Create the file in `.github/`
Ignored dependency still updates	`ignore` syntax incorrect	Verify `dependency-name` and `versions`

Real-World Examples

1. Enable Alerts

Settings → Security → Dependabot alerts → Enable

2. Enable Security Updates

Settings → Security → Dependabot security updates → Enable

3. Basic dependabot.yml

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"

4. Multiple Ecosystems

  - package-ecosystem: "docker"
    directory: "/"
  - package-ecosystem: "github-actions"
    directory: "/"

5. Ignore a Dependency

    ignore:
      - dependency-name: "express"

6. Ignore Version Range

      versions: ["4.x", "5.x"]

7. Set PR Limit

    open-pull-requests-limit: 3

8. Assign Reviewer

    reviewers:
      - "alex"

9. View Alert

Security → Dependabot alerts → [alert]

10. Dismiss Alert

Alert page → Dismiss → Select reason

Visual

Dependabot Architecture

┌──────────────────────────────────────────────┐
│  Dependency Graph                            │
│  (all dependencies, direct and transitive)   │
└──────────────────┬───────────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────────┐
│  GitHub Advisory Database                    │
│  (known CVEs and GHSAs)                      │
└──────────────────┬───────────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────────┐
│  Dependabot Alerts                           │
│  (match found → notification)                │
└──────────────────┬───────────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────────┐
│  Dependabot Security Updates                 │
│  (alert + patch → pull request)              │
└──────────────────────────────────────────────┘

┌──────────────────────────────────────────────┐
│  dependabot.yml                              │
│  (schedule → version updates)                │
└──────────────────────────────────────────────┘

Alerts and security updates are reactive. Version updates are proactive.

Alert to Fix Flow

┌──────────────────────────────────────────────┐
│  Vulnerability published in advisory         │
└──────────────────┬───────────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────────┐
│  Alert created (Security tab)                │
└──────────────────┬───────────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────────┐
│  Security update PR opened (if enabled)      │
└──────────────────┬───────────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────────┐
│  CI runs → review → merge                    │
└──────────────────────────────────────────────┘

The alert is the notification. The PR is the remediation.

Summary

Item	Value
Prerequisite	Dependency graph
Alerts	Notify of vulnerabilities
Security updates	Auto-fix vulnerable dependencies
Version updates	Keep dependencies current on schedule
Configuration file	`.github/dependabot.yml`
Default PR limit	5
Severity levels	Critical, High, Medium, Low
Public repo default	Alerts enabled
Private repo default	Alerts disabled

Key takeaways:

Dependabot is three features, not one. Alerts notify, security updates fix, and version updates maintain. Each has its own activation path .
The dependency graph is the foundation. Without it, Dependabot cannot detect vulnerabilities. Public repositories have it enabled by default; private ones require manual activation .
Security updates are separate from alerts. Enabling alerts does not enable automatic PRs. The security updates toggle must be enabled explicitly .
Version updates require dependabot.yml. The file specifies the ecosystems, directories, and schedules. Without it, no version update PRs are created .
open-pull-requests-limit prevents PR floods. The default is 5, and the maximum is 10. Teams with large dependency trees should tune this setting .
Auto-merge is possible but requires CI. A workflow can enable auto-merge on Dependabot PRs after required checks pass. The merge is still gated by the test suite .

Remember: Dependabot alerts you to the problem and, if configured, fixes it. The alert is the signal. The security update is the response. The version update is the maintenance. All three depend on the dependency graph, and all three require review before merging. The automation reduces the tracking burden, but the decision to merge remains human.

Was this helpful?

Stop using slow, ad-bloated tool sites! 🤮

🔎 Search “KandZ Tools” on Google to use many professional utilities for free.

KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)

⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free

🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!