Open another-rex opened 1 year ago
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?
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:
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.This issue has not had any activity for 60 days and will be automatically closed in two weeks
Automatically closing stale issue
Add the ability to scan manifest files e.g.
package.json
in addition topackage-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