Dependabot

## What an alert is A Dependabot alert is a repository-scoped notification that some package version your project resolves to is covered by a published security advisory. It is a *finding*, not a change: nothing in your repository is modified when an alert appears. Alerts live under the repository's Security tab and are also exposed through the REST API and webhooks, so they can be pulled into a ticketing system. ## Where the data comes from Two inputs combine. The first is the **dependency graph**. GitHub parses the dependency files you have committed for the ecosystems it supports and produces the list of packages the project actually resolves to. Lockfiles matter here: with a lockfile, the graph knows the exact resolved versions, including transitive ones. Without a lockfile, GitHub can only work from the ranges in the manifest, which makes the graph less precise. For some ecosystems the graph can also be enriched from build output that you submit yourself through the dependency submission API. The second is the **GitHub Advisory Database**, a curated set of advisories for open-source packages. Each entry has a `GHSA-` identifier, often a CVE alias, a severity, one or more affected ecosystems and package names, a vulnerable version range, and the first patched version. Advisories come from published CVE feeds, from maintainers who publish a repository security advisory, and from GitHub's own curation. When a package/version pair from the graph lands inside an advisory's vulnerable range, an alert is created. ## Direct versus transitive This is the part juniors most often miss. Most alerts in a mature repository are on **transitive** dependencies — packages you never wrote down, pulled in by something you did. That is exactly why the graph is built from resolved versions. It also explains why a fix sometimes cannot be a one-line manifest edit: you may need the intermediate package to release a version that requires the patched one, or you may need to pin an override in the ecosystem's own mechanism. ## What an alert does not do An alert does not open a pull request, does not fail a build, and does not prove you are exploitable. Vulnerability ranges are coarse: an advisory in a code path you never call is still reported. Severity is advisory-level, not application-level; a high-severity issue in a build-time-only dependency is usually less urgent than a medium one in a request-handling path. Interviewers like candidates who say this out loud rather than treating every alert as an incident. ## Enabling and access Dependency graph and Dependabot alerts are switched on per repository, and organisations can turn them on across many repositories at once through a security configuration. Alerts are visible to users with the right repository permission — typically write access and above — rather than to every reader of a private repository. Notification routing (email, web, ignore) is a per-user and per-organisation setting, which is why one team drowns in alert mail and another never sees any. ## Reading an alert A useful triage read of a single alert answers four questions: which package and version, which advisory (`GHSA-` id) and severity, whether the dependency is a runtime or development-scoped one, and whether a patched version exists at all. If no patched version exists yet, the alert is a monitoring item, not a task. If one does, the fix is a version bump — which is the job of Dependabot security updates, the sibling feature that turns alerts into pull requests. ## Common follow-through Teams that handle alerts well do three things: they enable the dependency graph everywhere so they have inventory, they route alerts to whoever owns the repository rather than to a central mailbox, and they agree an explicit response time by severity. Teams that handle them badly leave hundreds of open alerts and stop looking at the tab entirely, which is worse than not having the feature — it converts a signal into background noise.