You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Note: this is an in-house item already being handled by the maintainer - not open for contribution. Filed for tracking only.
Summary
The scan pipeline pairs OSV querybatch results to the queried packages purely by array position, in two places, and ignores the package identity it already carries. If OSV ever returns a results array that is out of order or shorter than the query list, vulnerabilities are attributed to the wrong package, or packages are silently recorded as clean.
OSV's API contract guarantees one result per query in query order, so this does not fire in normal operation. But it is an unguarded positional assumption in security-critical code, and the identity needed to make it robust is already available.
Where
src/advisory/osv-advisory-source.ts (queryBatch): builds rows as data.results.map((r, i) => ({ package: packages[i].name, version: packages[i].version, vulnerabilities: r.vulns || [] })) - pairs results[i] with packages[i] by index.
src/scanner.ts (~184-190): reads const row = rows[j] and attributes row.vulnerabilities to chunkItems[j], ignoring the row.package / row.version that queryBatch attached.
Failure modes
Out-of-order results -> package A is reported with package B's vulnerabilities (misattribution).
Match results to packages by identity rather than position: either have scanner.ts key off the package/version that queryBatch already attaches, or assert results.length === packages.length and verify per-entry identity in queryBatch. When the response does not line up, surface a descriptive failure or a scan-completeness diagnostic (tie into #907) rather than silently mis-pairing.
Context
Found while reviewing #985. Latent (depends on OSV violating its own contract), so low urgency, but cheap to harden given the identity is already in hand.
Summary
The scan pipeline pairs OSV
querybatchresults to the queried packages purely by array position, in two places, and ignores the package identity it already carries. If OSV ever returns aresultsarray that is out of order or shorter than the query list, vulnerabilities are attributed to the wrong package, or packages are silently recorded as clean.OSV's API contract guarantees one result per query in query order, so this does not fire in normal operation. But it is an unguarded positional assumption in security-critical code, and the identity needed to make it robust is already available.
Where
src/advisory/osv-advisory-source.ts(queryBatch): builds rows asdata.results.map((r, i) => ({ package: packages[i].name, version: packages[i].version, vulnerabilities: r.vulns || [] }))- pairsresults[i]withpackages[i]by index.src/scanner.ts(~184-190): readsconst row = rows[j]and attributesrow.vulnerabilitiestochunkItems[j], ignoring therow.package/row.versionthatqueryBatchattached.Failure modes
results-> package A is reported with package B's vulnerabilities (misattribution).results(fewer entries than queries) -> the tail packages getrows[j] === undefined, so they are recorded as having no vulnerabilities and cached as clean (a silent false-negative). Related to [Bug] TypeError crash when OSV API returns 200 OK with missingresultsfield #984/Fix crash when OSV API returns error in 200 response #985.Suggested direction
Match results to packages by identity rather than position: either have
scanner.tskey off thepackage/versionthatqueryBatchalready attaches, or assertresults.length === packages.lengthand verify per-entry identity inqueryBatch. When the response does not line up, surface a descriptive failure or a scan-completeness diagnostic (tie into #907) rather than silently mis-pairing.Context
Found while reviewing #985. Latent (depends on OSV violating its own contract), so low urgency, but cheap to harden given the identity is already in hand.