fix: use commit query for npm packages resolved from git URLs

[johnsaurabh]

Overview

Fixes #2850

pkgToQuery queried OSV.dev by npm ecosystem+name for all npm-ecosystem packages, including those resolved from git URLs in yarn.lock. These packages were never published to the npm registry, so the query returns false positives from unrelated packages that share the same name on npm.

Details

The yarnlock extractor already populates SourceCode.Commit for git-pinned dependencies via commitextractor.TryExtractCommit. When a commit hash is present for an npm-ecosystem package, pkgToQuery now returns a commit query instead of an ecosystem query.

```go
if imodels.Commit(pkg) != "" && imodels.Ecosystem(pkg).Ecosystem == osvconstants.EcosystemNPM {
return &api.Query{
Param: &api.Query_Commit{
Commit: imodels.Commit(pkg),
},
}
}
```

The gate is specific to npm. Other ecosystems are unaffected.

Testing

• Added `TestPkgToQuery` with two cases: a regular npm package (uses ecosystem query) and a git-pinned npm package (uses commit query).
• Tested against the `closure-net` entry from the issue. Without the fix it reports `MAL-2026-276` as a false positive. With the fix, no vulnerabilities are reported.
• All existing tests pass.

Checklist

• I have signed the Contributor License Agreement.
• I have run the linter using `./scripts/run_lints.sh`.
• I have run the unit tests using `./scripts/run_tests.sh`.
• I have made my commits and PR title follow the Conventional Commits specification.

[another-rex]

Thanks, LGTM! Can you add an e2e test for this as well? In cmd/osv-scanner/scan/source/command_test.go

[johnsaurabh]

Hi @another-rex, thanks for the update.
Added an e2e test yarn_lock_with_git_pinned_dep_no_false_positive to TestCommand in cmd/osv-scanner/scan/source/command_test.go. It scans a synthetic yarn.lock with a git-pinned dependency and asserts Exit: 0 (no false positive). The VCR cassette confirms the scanner is sending a commit query rather than an npm version query.

Let me know if anything else is needed. Thanks!

[0xTaoZ]

Thanks for working on this. The direction makes sense to me, especially keeping the ecosystem as npm and changing only the OSV query shape when a commit is available.

One small edge I think is worth guarding with a unit test: pkgToQuery currently switches any npm package with SourceCode.Commit to a commit query. That matches the yarn.lock git-pinned case, but a future extractor could plausibly populate SourceCode.Commit for a normal npm registry package/version as source metadata. If that happened, the npm ecosystem+version query would be skipped and npm advisories that are not tied to git commits could be missed.

Could you add a regression case that documents the intended boundary here? Either a normal npm registry package with a commit should still use the ecosystem query, or, if commit should always win for npm, a short comment/test name explaining why that is safe would make the behavior much easier to maintain.