GitHub's Dependabot alerts REST API now includes the version or version constraint that Dependabot last recorded for the vulnerable dependency. The new dependency.version_requirement field removes a common integration chore: parsing lockfiles or making a separate GraphQL request just to discover what your repository actually uses.
This is especially useful when you sync Dependabot data into a security dashboard, ticketing system, asset inventory, or release gate. The advisory still tells you which versions are vulnerable. The new field adds the repository-side value needed to decide what to fix first.
What the new field means
The field is called version_requirement and lives inside each alert's dependency object. Its value depends on how Dependabot found the dependency:
For a lockfile, it is the resolved version.
For a manifest without a lockfile, it is the declared version or version constraint.
For the dependency submission API, it is the resolved version submitted by your build tooling.
That distinction matters. A value such as 4.2.1 is usually a concrete resolved version. A value such as ^4.2.0 is a constraint, not proof that the repository installed exactly 4.2.0.
Where you can read it
GitHub includes version_requirement in responses for individual alerts, repository alert lists, organization alert lists, enterprise alert lists, and dependabot_alert webhook payloads. You can use the same normalization code for polling and event-driven integrations.
For an alert fetched from the repository endpoint, look under dependency.version_requirement. Keep the existing dependency.package.ecosystem, dependency.package.name, manifest_path, scope, and relationship fields alongside it. Those fields give the version context needed to group alerts correctly.
Build a safer security sync
Store the alert number, repository, ecosystem, package name, and manifest path as the stable identity for your record.
Store version_requirement separately from the advisory's vulnerable_version_range.
Label the value as resolved, declared, or submitted based on the source of the alert.
Reconcile the record when a webhook or later poll changes the alert state or version.
Do not use the new field as a replacement for the advisory range. A useful security record keeps both values: the version your project reports and the range GitHub says is affected.
Handle the edge cases
version_requirement can be null when no value is available. Treat null as unknown, not as safe and not as an empty version. Keep the alert visible and fall back to the manifest, lockfile, or dependency submission data you already trust.
If an alert covers more than one vulnerable version of a dependency, GitHub may return one recorded value that does not represent every version covered by the alert. Long version constraints may also be truncated. Store the raw value and avoid making exact-version claims when the value is a range or is incomplete.
A practical prioritization rule
Prioritize alerts where the recorded dependency value is concrete, falls inside the vulnerable range, and is used at runtime. Then use severity, exploitability, internet exposure, and whether a patched version exists to order the work. A declared constraint without a lockfile deserves a different confidence label from a resolved lockfile version.
This lets a security dashboard answer a better question than 'does this repository have a Dependabot alert?' It can answer 'which recorded dependency version is affected, where is it declared, and how confident are we that this is the installed version?'
Availability and rollout
The field is available on github.com and GitHub Enterprise Cloud with data residency. GitHub says it will be included in GitHub Enterprise Server 3.24. If your integration supports multiple GitHub deployments, keep the field optional until every target version exposes it.
Ship the parser before changing your workflow gates. First collect the field, monitor null and truncated values, and compare it with the versions you already derive from lockfiles. Once the data is stable, use it to improve prioritization rather than silently blocking builds on an unknown value.
The practical takeaway
Dependabot alerts now carry more of the project-side dependency context security tooling needs. Read dependency.version_requirement, preserve whether it is resolved or declared, handle null and truncated values, and keep it next to the advisory's vulnerable range. That is enough to remove a brittle lockfile-parsing step from many alert pipelines.
Sources: GitHub Changelog: Dependabot alerts now include dependency versions; Dependabot alerts REST API documentation; dependabot_alert webhook documentation.