Dependabot Alerts, Security Updates, Version Updates, Dependency Review, and Policy: Concepts, Architecture, and Mental Model

1. The practical problem: “keep dependencies updated” is not a control

Chapter 21 distributed packages. A consumer now inherits the producer’s defects and vulnerabilities, and each manifest can pull a transitive graph of code the repository does not own. A bot that opens every possible update can create review fatigue; a bot that merges everything can turn upstream change into production change without human intent. The problem is therefore not merely finding a newer version. It is building an evidence loop that answers what is used, what is vulnerable or stale, which change is proposed, which policy applies, who reviewed it, and why an exception remains open.

Keep three GitHub mechanisms distinct from the start: the dependency graph inventories dependencies; Dependabot alerts/security updates react to known vulnerable dependencies; and Dependabot version updates proactively look for newer versions even when no advisory exists.

2. Dependency graph: the inventory underneath everything else

The dependency graph is a GitHub-hosted model derived from supported manifests, lock files, submitted dependency data, and some ecosystem-specific graph jobs. A manifest expresses dependency intent; a lock file records concrete resolved versions, including transitive dependencies when the ecosystem supports it. The default branch matters because alerts are based on the dependency graph of that branch.

Do not treat a graph entry as proof that a vulnerable code path is reachable. It is inventory evidence. Risk triage combines graph relationship, advisory facts, runtime context, exploitability signals, and application behavior.

3. Dependabot alert: advisory + dependency + repository state

When Dependabot alerts are enabled, GitHub compares dependencies on the default branch with GitHub Advisory Database data. An alert records the affected package/ecosystem, manifest path, vulnerable range, advisory identifiers, severity, remediation information when available, and lifecycle state such as open, fixed, dismissed, or auto-dismissed. The alert is a GitHub security resource—not an Issue and not a pull request.

Severity is input to policy, not an automatic business decision. A critical development-only dependency and a high-severity internet-facing runtime dependency can require different handling. Conversely, “low severity” is not permission to ignore an alert forever.

4. Security update versus version update

The same Dependabot pull request may carry tests, changelog links, compatibility notes, and advisory context, but it is still proposed code. Review responsibility does not transfer to the bot.

5. dependabot.yml is an update policy, not an alert database

The file lives at .github/dependabot.yml, uses syntax version 2, and defines one or more update entries. Each entry names a package-ecosystem, a directory or directories location, and a schedule. Optional controls include groups, allow/ignore, labels, open-PR limits, private registries, cooldowns, target branches, and versioning strategy.

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 3
    labels:
      - "dependencies"
    groups:
      routine:
        applies-to: version-updates
        patterns:
          - "*"

allow narrows the candidate set; ignore removes matches afterward. If both match, ignore wins. Keep exceptions visible in version-controlled configuration rather than relying on one-off bot comments that future maintainers cannot easily audit.

6. Dependency review is the admission gate

Dependency review compares the base and head revisions of a pull request and explains dependencies added, removed, or updated. The dependency-review Action can turn that analysis into a required check, for example failing when a newly introduced dependency has a high-or-critical known vulnerability. On public repositories this is a free-compatible control.

The action does not decide semantic compatibility for you. Passing dependency review means the configured dependency-risk policy found no blocking delta; it does not mean the update preserves your application contract.

7. Dependabot is an automation actor with a lower-trust workflow context

Dependabot-created pull requests normally have actor dependabot[bot]. Workflows triggered by Dependabot through common pull-request/push events receive a read-only GITHUB_TOKEN by default and do not receive ordinary Actions secrets. If Dependabot itself needs private registry credentials, configure Dependabot secrets, a separate secret store.

This restriction is intentional. A dependency update can change code executed during install/build/test. Giving those runs production credentials would let upstream package behavior meet privileged workflow identity at exactly the wrong boundary.

8. Mental model: inventory → signal → proposal → gate → decision

              flowchart TD
                M["Manifest + lock file on default branch"] -->|parsed/submitted| G["Dependency graph"]
                A["GitHub Advisory Database"] -->|matches vulnerable version| D["Dependabot alert"]
                G -->|scheduled version check| V["Version update proposal"]
                D -->|security update enabled| S["Security update proposal"]
                V -->|pull request| R["Dependency review + CI"]
                S -->|pull request| R
                R -->|evidence| H["Human/policy decision"]
            

The manifest/lock file supplies dependency state to the graph. Advisory matching creates an alert, while the schedule can independently create a version-update proposal. Both proposed changes become pull requests that pass through dependency review and ordinary CI. The final arrow is deliberately to a human/policy decision: automation creates evidence and proposals; governance decides what enters the default branch.

9. Read-only inspection before enabling anything

First prove repository identity and current configuration. These commands do not enable alerts or version updates.

REPO="OWNER/dependabot-policy-lab"
gh repo view "$REPO" --json nameWithOwner,visibility,viewerPermission,defaultBranchRef

gh api \
  -H "Accept: application/vnd.github+json" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  "repos/$REPO/contents/.github/dependabot.yml" 2>/dev/null \
  || echo "No dependabot.yml is committed yet."

gh pr list --repo "$REPO" --author app/dependabot \
  --state all --json number,title,state,headRefName,updatedAt

In the web UI, inspect the dependency graph and Advanced Security settings. On a public repository the graph is enabled by default; Dependabot alerts are not. Record that baseline before clicking Enable, because feature enablement is a repository security state change.

Knowledge check

Summary

Dependency governance is a pipeline: inventory current resolved state, correlate with advisory data, generate bounded proposals, evaluate dependency deltas and ordinary tests, then record the merge or exception decision. Security updates and version updates solve different problems, and Dependabot automation remains subject to review.

Next you will build a disposable public repository, configure weekly npm version updates, enable alert/security-update inspection, add an immutable dependency-review gate, and verify the resulting state with UI, CLI, API, and pull-request evidence.

Official references

• Dependabot alerts
• Dependabot version updates
• Dependabot security updates
• About dependabot.yml
• Dependabot options reference
• Dependency review
• Dependabot on GitHub Actions
• REST API for Dependabot alerts