Dependabot Adds Dependency Versions: What Does a Null Value Mean?
A new dependency-version column on the dashboard shows null for some Dependabot alerts and a version range for others. Which value tells you what’s actually installed?
- GitHub added dependency version information to Dependabot REST alert responses on October 20.
- The value can be a resolved version or a manifest constraint, depending on the detection source.
- Consumers need to handle nulls, multiple vulnerable versions and truncated constraints. The field does not establish what is running in production.
The recorded dependency and the vulnerable range are different facts
An advisory can tell a security dashboard which versions are vulnerable without telling it which requirement was found in a repository. GitHub’s October 20 update adds dependency.version_requirement: the version or constraint Dependabot last recorded for that alert.
Integrations can obtain that information without separately parsing a lockfile or querying GraphQL for vulnerableRequirements. They should still preserve the distinction between a requirement and an installed version.
The REST response also carries security_vulnerability.vulnerable_version_range and first_patched_version. Those describe the vulnerability and its fix. The new dependency field describes a recorded value associated with the repository’s alert.
A lockfile and a manifest do not supply the same kind of value
The detection source determines how to interpret the field.
| Source | Meaning of version_requirement |
|---|---|
| Lockfile | The resolved dependency version. |
| Manifest without a lockfile | The declared version or version constraint. |
| Dependency submission API | The resolved version supplied by build tooling. |
GitHub’s dependency graph combines manifest and lockfile information with submitted dependency data. A dashboard column labeled “installed version” would therefore promise too much. “Recorded version or constraint” is a more accurate label for a consumer displaying this field.
Null means unavailable, and one value may be incomplete
GitHub returns null when it has no value to supply. An alert can cover several vulnerable versions while the field holds only one recorded value. Long constraints can also be truncated. These are limits of the value, not signals that remediation is complete.
There is a separate boundary around deployment status. The Dependabot documentation describes scanning the default branch and generating alerts when the dependency graph changes or new vulnerability information arrives. That process does not turn this field into an inventory of packages inside a running service.
For an integration, replacing null with “not affected” would introduce a conclusion that the response never supplied. Keep the missing-value state visible and handle the alert’s state separately from its version string.
The field reaches both REST consumers and webhooks
Individual alert responses, repository, organization and enterprise lists, and dependabot_alert webhook payloads include the field. It is available on github.com and GitHub Enterprise Cloud with data residency; GitHub says Enterprise Server 3.24 will include it.
Access requirements still apply. The webhook reference requires a subscribing GitHub App to have at least read access to the repository’s Dependabot alerts permission.
A useful display keeps the package, manifest_path, recorded value and alert state together. That gives an operator enough context to locate the affected dependency rather than treating a bare package name and version as the whole finding. Confirming remediation still requires checking the dependency change and the relevant deployment.
Frequently asked questions
Can an integration close an alert when version_requirement is null?
No. Null indicates an unavailable value. It does not establish that the dependency is unaffected or fixed.
Does fixing the displayed version address every vulnerable copy?
Not necessarily. A single alert can cover multiple vulnerable versions, and the recorded value may not represent all of them.
The new field removes an extra lookup from many alert integrations. Keeping its source and limits visible is what makes that shortcut reliable.