GitHub Dependabot API Adds version_requirement for Vulnerable Dependency Versions

What changed​

Before this change, the API gave only the advisory's vulnerable version range, not what was in your repository. So an alert could say "versions below 2.8.19 are affected" without saying which version your project actually used.

The new field sits inside each alert's dependency object. GitHub's REST documentation shows it next to manifest_path, scope and relationship. The examples in that documentation use values like = 2.8.18 and >= 2.0.0, < 2.0.2. The second example is a range rather than a single pinned version, which matters for the caveats below.

Where the value comes from​

The value depends on how Dependabot found the dependency, according to the GitHub changelog:

• Lockfiles: the resolved version.
• Manifests without a lockfile: the version or version constraint declared in the manifest.
• Dependency submission API: the resolved version your build tooling submitted.

The field is null when no value is available. GitHub also warns that if an alert covers more than one vulnerable version of a dependency, the field holds one recorded value. That value may not represent all of them. Long version constraints may be truncated.

Don't treat the field as an authoritative inventory. In a manifest-only setup it can be a constraint such as a range, not the version actually installed. Treat it as "what Dependabot last recorded."

Why API consumers should care​

If you sync alerts to other security tools, you no longer need to parse lockfiles or make a separate GraphQL request for vulnerableRequirements to get that version. In practice, that can remove a second API call and a custom lockfile parser for every ecosystem you ingest. The announcement covers only this one value. It doesn't claim that all lockfile parsing or all GraphQL use cases go away.

Where it appears​

It appears in individual alert responses, alert lists, and dependabot_alert webhook payloads. The changelog lists repository, organization and enterprise alert lists. Webhook receivers get the field too, so event-driven integrations don't need a follow-up fetch.

Availability​

The field is live now on github.com and GitHub Enterprise Cloud with data residency, and is coming to GitHub Enterprise Server 3.24. The announcement doesn't say it is available in earlier Enterprise Server releases. It also doesn't name a required REST API version. The documentation example I reviewed uses the X-GitHub-Api-Version: 2026-03-10 header, but that is only an example, not a stated prerequisite.

Access requirements​

The new field doesn't change who can call these endpoints. Per GitHub's documentation:

• Organization alert list: classic personal access tokens and OAuth app tokens need the security_events scope. public_repo is enough if you only use public repositories. Fine-grained tokens and GitHub App tokens need the "Dependabot alerts" repository permission (read).
• Enterprise alert list: the caller must be an enterprise member. Alerts are returned only for organizations where you are an owner or security manager. The endpoint doesn't work with GitHub App user or installation tokens, or with fine-grained personal access tokens.

What to do now​

1. Update your parsers or schemas to accept a new optional property inside dependency.
2. Handle null explicitly. Don't coerce it to an empty string or treat it as "not vulnerable."
3. Don't assume the value is a single exact version. Check for operators like >= or < before comparing it with an advisory range.
4. Keep any existing fallback logic for alerts that cover several vulnerable versions, or where the string may be truncated.
5. If you run GitHub Enterprise Server, plan around 3.24 before depending on the field.

The announcement doesn't say whether alerts that already exist are backfilled. It also doesn't give a field-length limit or a rollout percentage. Test against real alerts in your own environment before retiring any parsing code.

Bottom line​

This is a quiet API improvement, not a headline feature. It closes a gap that integrators have had to work around, and it comes with enough caveats that you should read the field carefully. Teams that feed Dependabot data into other security tools get one of the cheaper wins of the month.