GitHub adds recorded dependency versions to Dependabot alert payloads
GitHub added a version_requirement field to Dependabot alert responses on October 20. The field sits inside the dependency object and returns the dependency version or version constraint that Dependabot last recorded for the alert.
Alert responses already contained the vulnerable version range from the security advisory. That range describes affected versions; the new field supplies a recorded value from the repository. GitHub says integrations no longer need to parse lockfiles or make a separate GraphQL request for vulnerableRequirements to retrieve that value.
What the field means depends on detection. Lockfiles supply a resolved version. Manifests without a lockfile supply a declared version or version constraint. Dependencies reported through the dependency submission API use the resolved version submitted by the build tooling.
The field is not a complete inventory guarantee. It can be null when no value is available. If an alert covers multiple vulnerable versions of a dependency, it contains one recorded value and may not represent all of them. Long version constraints can also be truncated.
GitHub includes the field in individual alert responses, repository alert lists, organization alert lists, enterprise alert lists, and dependabot_alert webhook payloads. The change is available on github.com and GitHub Enterprise Cloud with data residency, with GitHub Enterprise Server 3.24 named as a future release target.
For security integrations and coding-agent workflows, the added field can reduce a separate lookup when triaging an alert. Consumers still need to handle null, truncated and partial values. The announcement describes richer alert data, not automatic remediation or proof that a deployed application is safe.