In GitHub, what is a Dependabot alert and where does its data come from?
answer
- It reports, it does not fix
- Two inputs are being compared
- Your resolved packages, their advisory list
- GHSA entries and the dependency graph
- Transitive dependencies count too
basics
~20 sA Dependabot alert is GitHub telling you that a package your repository depends on has a known vulnerability. It comes from matching the repository's dependency graph, built from committed manifests and lockfiles, against the GitHub Advisory Database.
solid answer
~40 sGitHub builds a **dependency graph** for a repository by parsing the manifests and lockfiles you commit (`package-lock.json`, `pom.xml`, `go.sum`, and so on). It compares every resolved package and version against the **GitHub Advisory Database**, whose entries carry `GHSA-` identifiers and often a CVE too. When a version you depend on falls inside an advisory's vulnerable range, GitHub raises a **Dependabot alert** on the Security tab, with a severity, the affected manifest, and the first patched version. Alerts cover **transitive** dependencies as well as direct ones, because the graph is built from resolved versions, not just your top-level declarations. An alert is only a notification: opening a fix pull request is a separate feature (Dependabot security updates) that you enable on top of alerts.
code
json · 21 linesGET /repos/OWNER/REPO/dependabot/alerts
[
{
"number": 12,
"state": "open",
"dependency": {
"package": { "ecosystem": "maven", "name": "org.example:widget" },
"manifest_path": "pom.xml",
"scope": "runtime"
},
"security_advisory": {
"ghsa_id": "GHSA-xxxx-xxxx-xxxx",
"severity": "high"
},
"security_vulnerability": {
"vulnerable_version_range": "< 2.4.1",
"first_patched_version": { "identifier": "2.4.1" }
}
}
]go deeper
Be able to say in one sentence that GitHub compares your resolved dependencies against a database of published advisories and flags matches on the Security tab. Know that an alert is a notification, not a code change.
Explain the two inputs — the dependency graph from manifests and lockfiles, and the GitHub Advisory Database with its GHSA identifiers — and why transitive dependencies show up.
Show triage judgment: reachability, runtime versus development scope, whether a patched version exists, and what you do when no fix has been released yet. Interviewers want to hear you prioritise rather than chase every alert.
Own the inventory and routing question: alerts are only useful if every repository has a graph, every alert has an owner, and severity maps to an agreed response time. Be ready to argue what you would measure instead of open-alert count.
## 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.
- Why do most alerts land on packages that are not in your manifest at all?Because the dependency graph is built from resolved versions, including transitive ones. A single direct dependency can pull in dozens of packages, and any of them can be covered by an advisory. That is also why the fix is sometimes to upgrade the intermediate package rather than the vulnerable one directly.
- Does a Dependabot alert mean your application is exploitable?No. It means a version you resolve to falls inside an advisory's vulnerable range. Whether the vulnerable code path is reachable from your application, and whether the dependency is runtime or build-time only, are questions the alert cannot answer. Severity is advisory-level context, not an application risk score.
- What happens to alerts if the repository has no lockfile?GitHub can still build a graph from the manifest, but it only knows the declared ranges rather than the exact resolved versions, so coverage of transitive dependencies is weaker and matches are less precise. Committing a lockfile for applications materially improves what the dependency graph and therefore the alerts can see.
saying these in an interview costs you the question
- Thinks an alert automatically opens a fix pull request
- Assumes only direct dependencies produce alerts
- Treats every high-severity alert as an active incident
- Believes the advisory data is scanned from your source code
- Says alerts appear without the dependency graph enabled