Dependabot now reports dependency versions. A recorded value still needs context.

GitHub announced on October 20 that Dependabot alerts now include dependency.version_requirement in REST responses. The value is the version or constraint Dependabot last recorded for the alert, rather than the advisory's range of affected versions. GitHub says it also appears in dependabot_alert webhook payloads.

The source matters: a lockfile supplies a resolved version; a manifest without a lockfile supplies its declared version or constraint; build-tool dependency submissions supply their submitted resolved version. The field can be null. GitHub also warns that a single recorded value may not represent every vulnerable version covered by an alert, and long constraints can be truncated.

This is useful information for an integration, but its meaning should travel with it. A report that renames every value 'installed version' would erase distinctions the announcement explicitly preserves.

A vulnerable-version range describes which versions an advisory concerns. A repository value describes what the detection source recorded. Neither label, by itself, establishes exactly what is running in every environment.

Consider a hypothetical team that copies dependency alerts into an internal work queue. A manifest constraint and a resolved lockfile version are both useful, but they answer different questions. Putting them in the same column without a source label makes the record harder to interpret.

The example is a proposed reporting structure, not an OrangeHat customer result or evidence of a specific vulnerability. Its point is narrow: preserving the original meaning is part of the integration work, even when collecting the data becomes easier.

The following is an editorial recordkeeping framework, not a GitHub configuration requirement:

A missing value is a useful state to preserve. An integration can display 'not available from this response' rather than substituting a guessed version, a zero or a reassuring green status. Similarly, a field documented as potentially truncated should not be treated as a complete constraint without further evidence.

For the hypothetical work queue, a reviewer could investigate the original repository evidence when a value is absent or insufficient. That is a separate task from deciding whether the alert applies to a deployed service. Keeping the questions distinct makes the next action easier to explain.

GitHub's general alert documentation says Dependabot checks the default branch and has detection limitations. It cannot catch every security issue, and new vulnerabilities can take time to appear in its advisory database. An empty alert list is therefore not a complete security assessment.

A proposed dependency update, a changed repository record and a verified production deployment are separate milestones. An internal report can track those milestones without claiming that one automatically proves the others.

In an illustrative workflow, the owner records the reviewed update, relevant test evidence and the deployed revision or inventory evidence appropriate to that system. If one part is missing, the report can state that limitation instead of promoting a partial result to 'fixed everywhere.' This is an analytical example, not a universal remediation procedure.

The new API field helps teams carry better context into that process. It does not remove the need to identify the affected system, evaluate the change and verify the outcome within the team's existing responsibilities and permissions.