npm results returning a lot of false positives or are other tools missing stuff? #400
Comments
|
Thanks for the report! Is there any chance you can share the package.json / package-lock.json in your project? Also, do you have any stale/old |
|
Sure, I'll forward it over. To be sure before running the above tests I deleted node_modules folder inside the project and started over. And doing ripgrep I don't see any reference to the older version of lodash anywhere in the directory. |
|
@oliverchang It looks like the new osv scanner beta that uses scalibr behind the scene returns the same results as |
|
I realized ripgrep by default ignores anything in .gitignore as well as anything under hidden folders, i.e. prefixed with a I did find under However, npm should respect only what's in my If that's the case is there a way to get scalibr to ignore stuff like that? |
|
fwiw I have no idea if that is actually the issue, but you have reminded me that while working on other scalibr stuff I noticed the |
|
@mlieberman85 you should be able to confirm if that's the issue by manually removing the |
You can configure the extractors to run with the respective flag: As use cases become more specific, you can use this to hone down your results. For example, in Artifact Analysis registry scanning we only use |
|
sorry, I didn't think my phrasing had linked this issue with my pull request but apparently it did - I don't think this should be closed unless someone can confirm that my change does actually fix the problem |
|
I will try and test this out shortly and get back to you. |
|
So, It's hard for me to test by deleting the yarn.lock as the lodash issue was just one of about 1000 packages that seemed to be false positives. Switching to just the This might be a separate issue/request but is there the ability to configure this flag via a config file for a project? If this doesn't already exist I can open a issue. |
|
I've created an issue internally but we haven't had bandwidth to implement it yet. Please file an issue! I will link/mention it on the existing one internally. |
|
@mlieberman85 fwiw you should be able to do a looped delete of all yarn.lock and pnpm-lock.yaml files in the node_modules directory. E.g. this should do it If the output is still not what you're expecting, then there's something else going on we should dig into |
I was testing out scalibr on an older version of an app I was building where I knew about a few known vulnerabilities. I used
scalibrto generate an SBOM which I then fed intoosv-scanner.I generated sboms at the root of the npm project.
I ran the following commands:
scalibr -o spdx23-json=scalibr.spdx.json --root .and
npm sbom --sbom-format spdx > npm.spdx.jsonI have attached scalibr.spdx.json and npm.spdx.json.
npm.spdx.json
scalibr.spdx.json
The results of osv scanner on scalibr.spdx.json was:
The results on the npm generated sbom was:
For example scalibr thinks that
[email protected]is installed but in my package.json, npm generated sbom,npm ls --alland just searching around in the files I could only find a reference to[email protected]. I can't tell if this is a false positive or if scalibr detected something npm itself didn't know about. If it was the latter I want to see if there's an easy way to understand what it did to detect it.Here is the output of
npm ls --alljust for additional info:The text was updated successfully, but these errors were encountered: