search

G-Rath / osv-detector

MIT License
61 stars 9 forks source link

There is no option to skip dev or build dependencies #148

Open skhokhlov opened 2 years ago

skhokhlov commented 2 years ago

Sometimes it could be unnecessary to scan dev or build deps so such option can be useful.

G-Rath commented 2 years ago

While I personally wouldn't be using this sort of feature, I'm not against trying to support it in some form - really there are two aspects to this:

  1. the ability to ignore a specific dependency
  2. the ability to ignore dependencies that are only used for development or building

For 1. we could either extend the existing --ignore flag or add a new one (e.g. --ignore-package), and we should probably take the standard CSV format - that'd give you some extra flexibility since we might as well support versions too. It would be up to you to manage that list though e.g. if a dev-only package later becomes used outside of dev.

For 2. the information on what is and is not a dev dependency is only included in about half of the lockfiles we currently support even though you can still specify that for most package managers (e.g. Bundler lets you have as many groups as you want, but none of that is included in the lockfile) so it'd be an inconsistent behaviour. However it's probably fine to have so long as the cost of supporting it isn't that high, if people would find it useful.

Why I don't think you should be skipping dependencies: depending on what ecosystem you're in it can be common for a large number of vulnerabilities to be in dev-only dependencies (e.g. npm) but that cannot be exploited - a common reaction to this is to ignore such dependencies, but this doesn't account for the fact that there can still be relevant vulnerabilities in those packages, especially with the rise of package hijacking and "protestware".

A very plausible example of this is a build dependency (like a webpack plugin) getting hijacked and made to add a small amount of malicious code to the resulting build - while I would expect this to get caught very quickly on the maintainer side, most ecosystems don't let you yank packages so if you don't hear of this from a social source (e.g. Twitter) then

Another (realworld) example is GHSA-mh6f-8j2x-4483 - that's on a dependency that is used by a number of common build tools in the npm ecosystem.