How do I check if my version falls inside a vulnerable range?

Your version is affected if it is at or above the introduced version and below the fixed version for that range. A fixed version is the first release with the fix. Compare using the ecosystem's own ordering rules, and treat last_affected as a ceiling, not a promise that later versions are safe.

The vocabulary

The OSV schema describes affected versions as ranges built from events.

A version is affected if it matches any range or appears in the explicit versions list. A range type can be SEMVER, ECOSYSTEM or GIT. SEMVER uses strict SemVer 2.0.0 ordering, and ECOSYSTEM uses the ecosystem's own version rules.

Three worked examples

Suppose a record says: introduced 1.0.2, fixed 2.0.0.

• Version 1.0.1 is below introduced, so it is not affected.
• Version 1.5.0 is at or above introduced and below fixed, so it is affected.
• Version 2.0.0 is the fixed version, so it is not affected.

The npm documentation's own example reads the same way. A package vulnerable in the range greater than or equal to 1.0.2 and below 2.0.0 flags every release in that span.

Now suppose a record uses introduced 0 and fixed 3.4.1. Every version before 3.4.1 is affected, however old. That is common when a flaw has been there from the start.

Finally, suppose a record uses introduced 1.2.0 and last_affected 1.2.9. Versions 1.2.0 to 1.2.9 are listed as affected. Version 1.3.0 is outside the listed range, but the schema warns that last_affected is less precise than fixed and can allow false negatives. If 1.3.0 is a release your team just adopted, check the advisory text and the project's changelog before you assume it is safe.

Traps to watch for

1. Multiple ranges. A package can have several affected spans, for example one per supported branch, each with its own fixed version. Find the span that matches your branch. A fixed version in a higher branch does not cover you.
2. Ordering rules. Use the ecosystem's comparison. Version strings do not always sort the way you read them. A scanner that uses the right ordering for the ecosystem is doing real work, and you should do the same when you check by hand.
3. Distribution packages. A distribution may carry its own ecosystem value and fixed versions. Debian's FAQ explains that fixes are backported to the version shipped in the stable release, so the upstream version number can stay the same. Check the distribution's own record, not only the upstream one.
4. Mixed sources. If two records for the same flaw disagree on the fixed version, read both and decide which matches your package source.

A short hand-check routine

1. Get the exact version you run, from the lockfile or the installed package list.
2. Open the advisory and find the affected entry for your ecosystem and package name.
3. Read each range's events in order.
4. Decide, for your branch, whether your version sits inside a span.
5. If it does, note the first fixed version. If there is none, note that too.
6. Compare with the scanner output. If they disagree, the usual causes are the wrong range, wrong ecosystem or a backport.

Why record your reasoning

When your hand-check disagrees with a scanner, write a short note in the ticket with both versions and the advisory ID. If the scanner is wrong, you have material for a bug report. If you were wrong, the note shows why.

Safeguard's dependency scanning matches component versions against advisory ranges and shows the fixed version where one is listed, and its fix pull requests (off by default) can propose the upgrade. Try a free scan at gold.safeguard.sh/scan.

Try it yourself

Click through it at your own pace, or open it full screen. Check which version the fix points to.

Quick check

Sources

• OpenSSF, OSV schema
• npm Docs, npm audit
• Debian, Security FAQ

Last reviewed: 19 October 2026.