Fixed-Version Verification

Summary

A fixed version may mean a first-fixed release, a package revision, a KB, a hotfix, or a superseding update. The useful question is not merely which number is larger; it is whether a vendor-confirmed update applies to the product, branch, platform, architecture, and deployment being reviewed.

Why it matters

"A fixed version is recorded," "the asset installed that update," "the vulnerable component is reachable," and "risk has been validated as reduced" are different claims. Collapsing them can close work too early or create misleading urgency.

When to use this guidance

Use this after an affected-version review, before patch closure, and whenever advisories list multiple product branches, superseding updates, or unclear support status.

Prerequisites and core concepts

Identify product edition, platform, architecture, branch, deployment model, and relevant component.
Keep affected range, first-fixed version, update identifier, and superseding release as separate fields.
Use vendor-confirmed references; a numerically later build is not automatically proven fixed.

Practical workflow

Read the advisory scope and identify explicitly fixed branches.
Record the first-fixed version or update reference for each applicable branch.
Check supersedence and whether a later cumulative update includes the security correction.
Collect installed-state evidence from the asset and confirm it maps to the applicable branch.
Retest the affected component or document why a different validation control is used.

Decision points

Use confirmed only where the vendor source and installed evidence align. Use unresolved when a branch is unsupported or the update mapping is unclear. Use not applicable only with product, edition, or component evidence; do not infer it from an omitted table row.

Evidence to collect

Vendor advisory, release notes, update or KB identifiers, and supersedence statement.
Installed version, package/update inventory, platform branch, architecture, and collection timestamp.
Asset owner evidence, retest result, and residual-risk or exception record where needed.

Common mistakes

Do not label a version safe because it is later numerically. Do not assume a superseding update applies to every edition. Do not treat a completed change ticket as proof that the component was updated and risk reduced.

Worked example

A fictional advisory covers Branch A and Branch B. It explicitly lists Update 12 as fixed for Branch A; Branch B is unsupported and has no clear statement. Update 14 supersedes Update 12 for Branch A. An asset inventory confirms Update 14 on a Branch A server, while a Branch B appliance needs vendor clarification. The conclusion records Branch A as update evidence confirmed pending retest, Branch B as unresolved, and a third asset as not applicable because it runs a different product edition.

Closure or output expectations

Closure should name the advisory, applicable branch, installed update evidence, validation method, owner, collection time, residual questions, and retest result. It should not overstate fleet coverage.

Limitations

Vendor tables can change and asset inventories can be stale. Update presence does not by itself prove exposure was removed or a compensating control is effective.