bun.lock: git dependencies with short commit hashes cause "Invalid hash" API error

[epipav]

Bug

Scanning a project with a bun.lock that contains git dependencies with short commit refs causes the scan to fail:

error when retrieving vulns: client error: status="400 Bad Request"
body={"code":3,"message":"Invalid hash."}

Reproduction

1. Clone https://github.com/activepieces/activepieces
2. Run:

   osv-scanner scan ./ --format json -L bun.lock .

3. Observe the error:

   error when retrieving vulns: client error: status="400 Bad Request" body={"code":3,"message":"Invalid hash."}
   

The repo's bun.lock contains the following git dependency with a short hash:

"@dust-tt/client/@modelcontextprotocol/sdk": ["@modelcontextprotocol/sdk@github:dust-tt/typescript-sdk#bca26e4", ...]

Version

osv-scanner --version
osv-scanner version: 2.3.3
osv-scalibr version: 0.4.2
commit: n/a
built at: n/a

[G-Rath]

ok so that is coming from this package

Unfortunately it doesn't look like Bun stores the full sha in a structured way, so I don't think there is much we can do on the scanner side - technically in this case the full sha is available in the dependency constraint of the original package, so in theory we could try and resolve it, but I'm pretty sure (among other things) you can use a short sha there so we still need to decide how to handle this as a general situation 🤔

[G-Rath]

also fwiw for this particular package it looks like they moved off the git dependency in v1.2.6, so if you can get updated to that you should be able to use the scanner without issue

[epipav]

Just to add some context — I'm hitting this across more than one repo. We use osv-scanner to power the vulnerabilities section of LFX Insights, which scans open source projects at scale, and I've seen this come up a handful of times with repos that have bun.lock files containing git dependencies with short commit hashes.

Updating the dep fixes it in some cases, but that's not always practical when you don't control the repo being scanned.

Would it be worth having osv-scanner skip unresolvable dependencies and continue scanning the rest? That way, we'd still get results for the other packages in a repo

[cuixq]

Here is the code that logs the error that comes from the vulnerability matcher, so I do think dependencies are extracted but the vulnerability matching fails and the error is returned.

@epipav are you suggesting that osv-scanner returns vulnerabilities matched for other dependencies if the matching fails for some dependency?

[epipav]

@cuixq Optimally, yes — I'm not deeply familiar with the codebase internals, but skipping packages whose commit hashes can't be resolved and emitting a warning, rather than letting that error abort the scan, seems like the ideal behavior. This way, vulnerability data for the rest of the dependencies is still returned. That said, I completely understand if there are constraints or design decisions I'm not aware of that make this more complex