## TL;DR

Find the OSV entry's fixed version, upgrade to it, and re-scan. If the vulnerable package arrives transitively, bump the direct parent or add an override pinning the fixed version - editing the transitive entry by hand does not survive the next install. When no fix is published yet, document the exception and consider replacing the dependency.

## The error

```text
$ osv-scanner --recursive .
...
1 vulnerable dependency found (see OSV entry for details)
```

(The table above names the package, installed version, severity, and the fixed version when one exists.)

## Fix it

1. Get the details. Run `osv-scanner --recursive .` locally and read the finding: package name, installed version, OSV ID, and fixed version.
   Expected: the entry names a version that resolves the CVE.
2. Upgrade. If it is a direct dependency, bump it. If it is transitive, bump the direct parent that pulls it in, or add an override or resolution rule in your package manager pinning the fixed version.
   Expected: the lockfile resolves to the fixed version everywhere.
3. Re-scan. Run `osv-scanner --recursive .` again.
   Expected: no vulnerable dependencies found, exit code 0, CI goes green.
4. If no fix is published yet, check the OSV entry's fix status, document the exception with a review date, and evaluate replacing the dependency if the risk matters.
   Expected: a tracked, time-boxed exception rather than a silent merge.

## Use this when

- osv-scanner blocks the PR on a newly introduced vulnerable dependency
- You see an OSV ID in the failing check
- You need the minimal upgrade that clears the finding

## Not for this skill when

- The scanner is snyk or dependabot - those have their own remediation flows
- osv-scanner crashes on a lockfile it cannot parse - that is a parser issue, not a vulnerability
- The finding is in a dev-only dependency your policy exempts - configure the exemption instead

## Variant phrasings

- osv-scanner vulnerable dependency
- osv scanner failed PR
- osv-scanner how to fix vulnerability
- OSV-2024 fix version upgrade

## Why it happens

OSV-scanner maps your lockfile against a distributed vulnerability database. Either your PR added a dependency that was already vulnerable, or a new CVE was published against a version you already had - both flip the gate red. The fix is almost always a version bump, because the database entry ships with the fixed version.

## Edge cases

- Transitive-only vulnerabilities need an override in the package manager; bumping the direct dep alone may not move the transitive pin
- Some ecosystems require regenerating the lockfile - hand-editing it gets overwritten on the next install
- OSV only knows what is in the database; brand-new CVEs can lag by hours or days
- If your config hides findings, re-run with ignores disabled once to see the full picture before triaging

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_edinbmXVuF90Vcy9p_zoiw