You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
the ability to ignore a specific dependency
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.
Sometimes it could be unnecessary to scan dev or build deps so such option can be useful.
The text was updated successfully, but these errors were encountered: