A new version field in Dependabot alerts can remove an extra lookup when syncing security tools. The dangerous shortcut is treating it as a complete, current inventory of installed versions. version_requirement can contain a resolved version, a declared constraint or no available value. One field name does not imply one uniform strength of evidence.

GitHub released this REST API improvement on October 20, 2026. For “Can version_requirement be used directly as the vulnerable dependency version?”, an original consumer model preserves source text and separates missing, unknown and stronger version interpretations. 中文版.

A version observation is not a new safety conclusion

The original announcement defines dependency.version_requirement as the version or constraint last recorded for an alert. Lockfiles and build submissions supply resolved versions; manifests without lockfiles can supply declared constraints. It can be null, represent only one of several vulnerable versions, or contain a truncated long constraint.

The change improves contextual data retrieval. An advisory range previously required another source for repository-side version information; an alert response can now carry one such observation. Last recorded is not the same instant as currently running, and one recorded value is not a complete set of dependency instances.

A consumer can reduce unnecessary lookups without automatically closing an alert, asserting that deployment was upgraded, or assigning zero risk. The parser below makes none of those decisions. It first keeps original strings and unknown states from disappearing during synchronization.

Keep advisory ranges and repository observations separate

Suppose an advisory affects versions below 2.0.0, while a repository observation is 1.2.3. These answer different questions: which versions are affected, and what was associated with this alert? If the observation is ^1.2.0, it describes a selection constraint rather than establishing the version resolved during a particular installation.

The REST documentation lists package context, manifest location and version_requirement inside dependency separately from security_vulnerability.vulnerable_version_range. Preserve that distinction in a consumer. Do not overwrite the advisory range with the new field or relabel an advisory’s first patched version as a version already installed in the repository.

Text sorting is another trap. Lexical ordering is not an ecosystem’s version semantics, and prefixes, prerelease labels and constraint operators cannot all be handled by extracting digits. The model deliberately implements no version solver: it preserves 1.9.0 and 1.10.0 instead of deciding from dictionary order which is repaired.

Exact-looking text still needs provenance

A string shaped like 1.2.3 establishes its text format, not its origin in a lockfile resolution. A manifest can declare an exact version too. If a downstream decision requires the actually resolved version, combine the observation with detection-source or build evidence rather than guessing provenance with a regular expression.

Likewise, one observation can describe a manifest, subproject or time. A repository can use several versions of the same package at different locations. Deduplicating only by package name collapses these contexts. Decide whether the consumer synchronizes alert objects, dependency instances or deployment inventories before choosing its identity key. A change in the stored object’s meaning also requires reviewing keys and deduplication rules.

The example stores alerts under a repository-and-alert-number key. It is not a complete dependency-inventory identity design. An instance-oriented system needs manifest paths, ecosystems and relevant build context. Do not add an unpromised completeness claim to a finite observation.

Do not collapse missing, null and invalid into an empty string

A missing field can occur in old snapshots, older consumer contracts or other input sources. A present null means that record has no available value. Neither means the dependency is absent or the alert fixed. Empty text and numeric values are format anomalies reported by this example, not silently converted into plausible version strings.

Preserving states helps diagnose a migration. Did the producer omit the field, did a JSON transformation drop it, or did consumer validation reject it? Mapping everything to an empty string erases that explanation. Unknown should remain a visible data state rather than an implicit low-risk default.

The model also does not reconstruct a potentially truncated long constraint. If a decision needs the complete range, obtain sufficient context before handing it to the ecosystem-appropriate parser. Appending an imagined missing boundary turns a guess into a false claim about what the API supplied.

Thirteen field-contract checks

The program handles the new field in synthetic alerts while retaining the original alert state. It assumes surrounding fields such as alert number already satisfy an upstream contract. It is neither a complete API client nor a general JSON-cleaning library. Missing and null have distinct states, invalid types are not silently coerced, and constraints remain unchanged.

# Synthetic alert-field consumer, not a version solver or an API client.
from copy import deepcopy

def normalize(repo, alert):
    dep=alert.get('dependency')
    raw=None
    if not isinstance(dep,dict):
        state='invalid-dependency'
    elif 'version_requirement' not in dep:
        state='missing'
    else:
        raw=dep['version_requirement']
        if raw is None:
            state='unknown'
        elif not isinstance(raw,str) or not raw.strip():
            state='invalid-value'
        else:
            state='recorded'
    return {'key':(repo,alert['number']), 'alert_state':alert.get('state'),
            'value_state':state, 'recorded_requirement':raw,
            'advisory_range':alert.get('security_vulnerability',{}).get('vulnerable_version_range')}

def sample(value):
    return {'number':1,'state':'open',
            'dependency':{'package':{'ecosystem':'npm','name':'fictional-demo'},
                          'manifest_path':'package.json','version_requirement':value},
            'security_vulnerability':{'vulnerable_version_range':'< 2.0.0'}}

exact=sample('1.2.3'); before=deepcopy(exact)
r=normalize('example/repo-a',exact)
assert r['value_state']=='recorded' and r['recorded_requirement']=='1.2.3'
assert normalize('example/repo-a',sample('^1.2.0'))['recorded_requirement']=='^1.2.0'
missing=sample(None);del missing['dependency']['version_requirement']
assert normalize('example/repo-a',missing)['value_state']=='missing'
unknown=normalize('example/repo-a',sample(None))
assert unknown['value_state']=='unknown'
assert unknown['alert_state']=='open'
assert normalize('example/repo-a',sample(123))['value_state']=='invalid-value'
assert normalize('example/repo-a',sample(' '))['value_state']=='invalid-value'
bad=sample(None);bad['dependency']=[]
assert normalize('example/repo-a',bad)['value_state']=='invalid-dependency'
assert exact==before
assert r['key']!=normalize('example/repo-b',exact)['key']
second=sample('1.9.0');second['number']=2
assert len({r['key'],normalize('example/repo-a',second)['key']})==2
assert r['advisory_range']=='< 2.0.0' and r['recorded_requirement']!='< 2.0.0'
assert [normalize('example/repo-a',sample(v))['recorded_requirement']
        for v in ('1.9.0','1.10.0')]==['1.9.0','1.10.0']
print('13 field-contract checks passed; no account or dependency queried')

Thirteen executed checks cover exact text, constraint text, missing, null, an unchanged open alert state, numeric and whitespace anomalies, malformed dependency structure, input immutability, repository isolation, multiple alerts for one package, preservation of the advisory range and unchanged version strings. No real repository was queried, dependency installed or vulnerability evaluated.

recorded means only that a nonempty string was received. It does not mean complete resolved version or successful semantic parsing. It also does not detect whether a server truncated the string; nonempty data alone cannot become evidence of completeness. Make few inferences at ingestion and leave stronger decisions to stages with enough context. This matters because a field containing the word version can otherwise be promoted straight into an inventory column with a stronger meaning than its source supports.

Test coexistence of old and new records

An existing sync can first preserve the extra field without changing alert-state logic, then compare old and new fixtures to ensure a strict parser does not reject an entire alert merely because information was added. Missing data must not become safe-by-default, and historical observations must not be overwritten as if they established the current version.

For webhook consumers, arrival time alone does not replace source-record update ordering. Retry and out-of-order events need the existing synchronization contract. This article claims no cross-system transactional consistency supplied by GitHub. Design idempotence and update rules from actual event metadata, retaining enough evidence to explain overwrites.

The first acceptance targets are information preservation: old records remain readable, null remains unknown, a constraint is not relabeled as a resolution, and keys do not collide across repositories. Any reduction in requests or elapsed time needs measurement under the consumer’s real workload. A teaching fixture supplies no credible performance-saving estimate.

Observation, admission and repair are separate steps

The earlier GitHub package firewall analysis concerns installation admission. This article concerns synchronized alert context. Knowing a recorded version does not establish that a current installation was admitted or a patch passed regressions. Different tools’ green statuses should not be combined into one unbounded claim of safety.

A clearer sync record keeps the advisory range, observed source text, provenance and timing context, current alert state and missing evidence separately. A reader can then see which decisions the record supports and which need further checking.

If this field model helps prevent version-sync mistakes or information loss, voluntary support through the section below is welcome. The reusable result is keeping what is known and what remains unknown explicit in the data.

Sources and article date

October 20 announcement · Dependabot REST API

Discovered through Google News and checked against the original announcement, published before the planned slot. Examples and diagrams are original teaching material, not a product benchmark or real account operation. The planned article date is 2026-10-21 at 11:30 Beijing time. Scheduling or actual public release is verified separately; a backfilled date does not imply earlier publication.