The Dependabot alerts API now returns a version_requirement attribute for each dependency, showing the exact version or constraint that triggered the alert. This change reduces the friction of integrating Dependabot data into security pipelines, which is directly relevant to AI, cloud, DevOps, and security teams that automate vulnerability management.
New version_requirement field
Every alert’s dependency object now carries a version_requirement entry. The value reflects the version Dependabot recorded when it identified the issue. How the value is derived depends on the source of the dependency:
- Lockfiles: the resolved version from the lockfile.
- Manifests without a lockfile: the version or version constraint declared in the manifest.
- Dependency submission API: the resolved version supplied by the build tooling.
If no version can be determined, the field is null. When an alert spans multiple vulnerable versions, only a single recorded value is returned, which may not cover the full range. Very long constraints may be truncated.
Impact on tooling and automation
Previously, alert payloads only included the advisory’s vulnerable version range, requiring downstream tools to read lockfiles or issue a separate GraphQL request for vulnerableRequirements. With version_requirement present, a single API call now provides both the advisory range and the concrete version used in the repository. This streamlines data ingestion for security dashboards, CI/CD gate checks, and automated remediation bots, reducing latency and code complexity.
Operational considerations
The field appears in individual alert responses, as well as in repository, organization, and enterprise alert list endpoints, and in the dependabot_alert webhook payload. It is already live on GitHub.com and GitHub Enterprise Cloud (including data‑residency deployments) and will be added to GitHub Enterprise Server starting with version 3.24. Consumers should be prepared for null values and possible truncation, and should not assume the field represents every vulnerable version when multiple versions are affected.
Related CloudNinjas coverage: hands-on guides.
What This Means For Practitioners
Update any scripts or integrations that currently parse lockfiles or issue GraphQL queries to retrieve dependency versions; switch to the REST endpoint and read version_requirement instead. Add handling for null and truncated values, and verify that your alert‑correlation logic can tolerate a single recorded version when multiple vulnerable versions exist. Finally, test the change in your staging environment before rolling it out to production pipelines.