Dependabot adds a version field: distinguish recorded data from deployed versions

A security ticket with a package name and advisory range still leaves the owner asking which version the repository uses. On October 20, 2026, GitHub added dependency.version_requirement to Dependabot alert REST responses. This can remove a round trip in an integration, but labeling the string as the exact version currently installed in production would introduce a different error. The useful change is better context for investigation. This article separates the announced behavior from proposed team practices for keeping that context intact through a ticketing system.

Keep advisory scope and repository evidence in different columns

The existing vulnerable_version_range describes versions affected by an advisory. The new field contains the dependency version or constraint Dependabot last recorded for the alert. Keep both values, together with package, ecosystem and manifest_path. A constraint is not a single installed version that can safely be sorted as a release number. A label such as “recorded version or requirement” encourages the reviewer to ask where it came from instead of treating the display as a complete inventory of running software. Preserve the original semantics when exporting to a spreadsheet or another security tool.

Detection determines what the string means

The announcement distinguishes resolved lockfile versions, versions or constraints declared in manifests without lockfiles, and resolved versions submitted by build tooling through the dependency submission API. The field appears in individual alerts, repository, organization and enterprise lists, and dependabot_alert webhooks. It is available on github.com and Enterprise Cloud with data residency, with Enterprise Server 3.24 planned to include it. That does not establish support on an older Server installation. Verify the host and the response you actually receive before making the field mandatory in an ingestion schema.

Treat null and partial coverage as ordinary inputs

GitHub documents null when no value is available. For an alert covering multiple vulnerable versions, one recorded value may not represent them all, and long constraints can be truncated. A proposed parser should preserve strings and null, distinguish unknown from safe, and avoid replacing an old ticket’s missing value with a fabricated version. The fact that an integration imported the same number of alerts does not prove version information is complete. Keep an explicit unknown state so the investigator can request a lockfile or build record when the alert alone is insufficient.

Verify the integration with representative alerts

Start with a representative repository. Retain redacted response evidence, collection time, alert identifier, manifest path and recorded value. Exercise a lockfile value, a manifest constraint and a null case through the ticket UI. If both webhooks and list polling feed the system, reconcile repository and alert identifiers so one event does not create duplicate tickets. Check endpoint-specific permissions in the REST documentation instead of broadening every token for convenience. These are operational proposals, not promises of a new automatic remediation feature or a substitute for testing.

For current deployment evidence, inspect build and deployment records separately. After updating a dependency, rerun the existing tests and read the alert state again. The extra field may reduce investigation work, but it cannot attest to the current installation in every environment. Simplifying alert synchronization does not require removing release verification. A useful acceptance criterion is that a reviewer can tell a constraint, an unknown value and a representative recorded version apart, then identify the next evidence needed to close the issue.

Official sources

GitHub Changelog · Dependency versions

GitHub Docs · Dependabot alerts REST API

Checked October 21, 2026. Compare one alert response with the version label shown in its security ticket.