Keep Dependabot’s recorded dependency value separate from the advisory’s vulnerable range. When adding dependency.version_requirement to an alert report, preserve its raw text and distinguish a missing field from null; neither is evidence that a dependency is safe. Start with a read-only sample and a parser test before changing the report your team relies on.
What changed on October 20, 2026
GitHub added version_requirement to Dependabot alert REST responses and webhooks. It contains the dependency value last recorded for the alert: a resolved version from a lockfile or dependency submission, or a manifest’s version or constraint when no lockfile supplies it. The advisory’s vulnerable range is a different field. GitHub explicitly cautions that the value can be null, long constraints can be truncated, and one recorded value may not represent every vulnerable version covered by an alert. See the October 20 announcement.
This is useful report context, not a fresh inventory of everything installed. The practical task is to carry that context into your existing handoff without turning uncertainty into a confident-looking spreadsheet cell. The worksheet and proposed tests below are an editorial workflow, not a report from a live integration test.
Label the value without guessing its origin
Use a heading such as “Recorded dependency value,” not “Installed version.” Keep the exact returned string in a raw field. A tidy-looking number does not prove which detection route produced it. If provenance matters to a decision, inspect the repository evidence or build submission separately and record the evidence link.
For example, a synthetic value >=2.0, <3.0 is not one installed release. Do not remove the operators to make it fit a numeric column. Nor should a report assume that version syntax from one package ecosystem applies to every other ecosystem. Preserve meaning first; sort and format second.
A compact alert handoff record
Copy this record into your internal issue or review document. Keep repository details within your team’s approved destination. Fill only what you actually observed; an unanswered question gets an owner, not an invented answer.
| Field | What to record | Check before handoff |
|---|---|---|
| Identity | Host, repository and alert number | Can another reviewer open the same alert? Do not merge records merely because package names match. |
| Dependency context | Package, ecosystem and manifest path | Are similarly named dependencies in different paths still distinguishable? |
| Recorded value | Raw version_requirement plus present, null or missing status | Did any conversion replace an unknown with zero or an empty success? |
| Advisory context | Vulnerable range in its own field | Can the reader tell the advisory condition from the repository record? |
| Observation | Fetch time, response source and recorded alert update time | Fetch time describes this export, not when the dependency was last observed. |
| Follow-up | Unresolved question, evidence needed and responsible reviewer | Does the next person know what to check rather than merely seeing a blank? |
Keep unknowns visible
“Missing” means your input did not contain the key. “Null” means the key was present with a null value. Preserve that difference when reviewing old captured payloads alongside newer ones. If your transformation encounters an unexpected type, stop that row for review instead of silently coercing it into a plausible version.
A sensible display might show “Not supplied” for null and “Field absent in input” for missing, while retaining the original payload in an approved evidence location. These are suggested labels, not GitHub response values. Do not display either as “No vulnerable version.”
One row is not necessarily the whole dependency picture
Before a remediation decision, ask whether the alert’s recorded value is enough for the question being answered. If a reviewer needs to know every occurrence in a monorepo, a single displayed value is not an inventory. Keep the alert link and manifest path available so the reviewer can inspect the actual affected context.
Separate two deliverables: a faithful export of what the alert says, and an investigation of what the project currently contains. Completing the first does not complete the second. Likewise, adding a new column should not automatically dismiss alerts, edit manifests or approve upgrades.
Test the report before sending it downstream
The following are synthetic test cases to add to your own parser suite. They are not live API observations or actual package recommendations. Record the input, expected output and observed output for each.
| Synthetic input | Expected handling | Failure to catch |
|---|---|---|
| String “2.4.1” | Retain the exact string and present status | Numeric conversion or loss of punctuation |
| String “>=2.0, <3.0” | Retain the entire constraint as one value | Splitting at the comma or claiming one resolved release |
| Explicit null | Retain null status and an unknown-value label | Substituting zero or a safe result |
| Key absent | Retain missing status | Silently treating an older payload as a current null response |
| Two repositories, same alert number | Keep two separately identified records | Overwriting one row with another |
| Request fails | Report an incomplete collection | Turning a permissions or transport error into “zero alerts” |
For a real read-only collection, use the documented endpoint and access appropriate to its scope. The REST reference distinguishes repository, organization and enterprise endpoints. List responses are paginated; the maximum page size is 100, not a promise that one request contains every result. Follow the documented pagination links and record incomplete collection separately from a genuinely empty result.
A small release gate for the new column
- Compare a small approved sample with the original response, including at least one unknown-value case if available.
- Check that package, path and alert identity stayed attached to the right value.
- Review the exported file in its intended destination. A faithful raw-data file and a presentation view may need different handling; do not assume opening arbitrary strings in a spreadsheet is harmless.
- Ask the receiving reviewer to explain what the column means. If they read it as a current installed-version guarantee, change the heading and help text.
- Keep the previous report available until the sample review and parser checks pass. Note exactly what was tested and what remains unverified.
The win is not one more filled column. It is a report that helps the next person make the right distinction: what was recorded, what is unknown, and what still needs checking. For a related but separate dependency task, use our GitHub Actions lockfile review worksheet; it concerns workflow dependencies, not Dependabot alert exports.