Already recorded in CLAUDE.md under Known gaps:
OSV's unversioned second pass for MAL- advisories on yanked packages is not implemented; malicious advisories affecting the installed version still surface normally.
Raising it so it is visible outside the maintenance notes.
Why it is narrow but real
The ordinary case is already covered — a MAL- advisory whose affected range matches the installed version comes back from the normal versioned query and is handled properly (see #9 for how it is then rendered).
The gap is the aftermath of a takedown. Once a malicious release is caught it is typically yanked or removed from the registry, and the advisory's version metadata for a deleted release is not always something a versioned query lines up against. A project still holding that version in its lockfile is precisely the population that most needs telling, and is the one most likely to be missed.
Considerations
- Cost: an extra query per package, so it should be batched into the existing
querybatch flow rather than issued one-by-one, and probably restricted to a second pass over packages the first pass returned nothing for.
- Precision: an unversioned query returns every advisory for the package, most of which will not apply. Only
MAL- records should be promoted this way — pulling in unrelated CVEs would be a large over-report with no signal.
- Anything the second pass cannot complete must land in
scan_failed like everything else, never be quietly skipped.
- Cache keys must not let a versioned and an unversioned answer overwrite each other.
Acceptance criteria
Already recorded in
CLAUDE.mdunder Known gaps:Raising it so it is visible outside the maintenance notes.
Why it is narrow but real
The ordinary case is already covered — a
MAL-advisory whose affected range matches the installed version comes back from the normal versioned query and is handled properly (see #9 for how it is then rendered).The gap is the aftermath of a takedown. Once a malicious release is caught it is typically yanked or removed from the registry, and the advisory's version metadata for a deleted release is not always something a versioned query lines up against. A project still holding that version in its lockfile is precisely the population that most needs telling, and is the one most likely to be missed.
Considerations
querybatchflow rather than issued one-by-one, and probably restricted to a second pass over packages the first pass returned nothing for.MAL-records should be promoted this way — pulling in unrelated CVEs would be a large over-report with no signal.scan_failedlike everything else, never be quietly skipped.Acceptance criteria
MAL-advisory is reported when it is present in a lockfileMAL-advisories are not swept in by the unversioned pass