Match advisory ranges to exact installed versions
Compare package ecosystem, resolved versions, advisory intervals, and vendor patches. Keep version matches separate from reachability and local impact.
An advisory match begins with package identity and an exact installed version. A similar name, a broad manifest range, or the newest version on a registry cannot establish which component is in your release. Start from the resolved inventory and the advisory's current record.
The OSV schema defines package ecosystems and affected ranges. Its fixed and last-affected boundaries have different meanings. Use ecosystem-aware version handling rather than comparing version strings alphabetically.
Complete the advisory worksheet
Record each installed occurrence separately. A release can contain a fixed direct dependency and an older transitive copy at the same time. Preserve the advisory revision or retrieval date so another reviewer can reproduce the comparison.
| Field | Evidence to attach | Question resolved |
|---|---|---|
| Ecosystem and package | Advisory identity and inventory identity | Are these the same package? |
| Installed occurrence | Exact version, path, artifact | Which bytes are under review? |
| Affected interval | Structured advisory data | Does the version fall inside it? |
| Fixed release | Maintainer advisory or patch reference | Is a corrective version identified? |
| Vendor modification | Distribution or backport evidence | Does upstream numbering describe this build? |
Mark an unresolved match as unknown. Do not convert a parser error or missing version into an unaffected result.
Check boundary and ecosystem cases
Test the matching tool against a version immediately before the fixed boundary and the fixed version itself. Include prereleases or ecosystem-specific suffixes when they occur in your inventory. Preserve separate intervals when an advisory affects more than one maintained release line.
For vendored or source-built components, locate an immutable revision or the relevant patch evidence. A product's marketing version may not identify the embedded package. Ask the responsible maintainer for the mapping rather than inventing one.
Keep the conclusion narrow
A version match establishes that the installed component falls in the advisory's stated affected set. It does not by itself show that an attacker can reach the vulnerable behavior in your deployment. Perform that applicability review as a separate step.
Likewise, a non-match for one advisory is not a general security assessment of the package. Save the matched occurrences, unresolved cases, source date, and reviewer decision. Reopen the record when the advisory range changes or a new artifact ships. This keeps corrections and backports visible without suppressing a real affected copy elsewhere in the dependency graph.
Know which dependency risks need a fix
Check affected versions, the build and deployment evidence. Use the update checklist, or discuss the dependency risks in your application review.