Scan manifest files as well (not just lockfiles)

[another-rex]

Add the ability to scan manifest files e.g. package.json in addition to package-lock.json. Possibly using deps.dev dependency graph data to scan transitive dependencies.

Motivation: Some projects don't check in their package-lock.json files, breaking automated repo scanning that's done by projects like scorecard. E/.g see #410

Related #352

[spencerschrock]

Would this also help with cases where the project being analyzed is the one with vulnerabilities (as opposed to dependencies)?

For example, consider the archived npm package parsejson, which has an advisory against it.

$ osv-scanner -r .
Scanning dir .
Scanning /tmp/parsejson/ at commit d2986dc30989377409102516ecdebbfd06cbf28f
No issues found

Or is osv-scanner intended to be used only to find vulns in your dependencies, not in the project being analyzed?

[another-rex]

It'll be good to add support to find vulns in the project being analyzed. The only way we are doing it currently is by git commit, which we only really enumerate for C/C++ advisories, which is why osv-scanner did not return a result.

Couple issues I can think of:

• If we scan the package.json/package-lock.json, and it returns a vulnerable version, since it's a project you are editing, it could have been already patched, just the version has not been bumped up yet, but maybe that's an expected behavior.
• A local package name (that has not been published) might be the same as a published package, but that doesn't mean they are the same package, and this false positive matching could be pretty common.

[github-actions]

This issue has not had any activity for 60 days and will be automatically closed in two weeks

[github-actions]

Automatically closing stale issue

[andrewpollock]

Motivation: Some projects don't check in their package-lock.json files, breaking automated repo scanning

Silly question: why not just generate the package-lock.json at scan time? Is the desire to not have to clone the repo and do this?

[cuixq]

I think to generate the lockfile at scan time is more like "relock" - the generated lockfile may be different.