search

anchore / grype

A vulnerability scanner for container images and filesystems
Apache License 2.0
8.7k stars 569 forks source link

Option to filter out vulnerabilities of dev dependencies #1643

Open fingeromer opened 10 months ago

fingeromer commented 10 months ago

What would you like to be added: I would like to add an option to exclude dev dependencies of being scanned.

Why is this needed: For ecosystems like NodeJs, there are dev packages that are not relevant for running applications in production.

tgerla commented 9 months ago

Hi @fingeromer, thanks for the suggestion. We have an issue to track dependency relationships in more ecosystems, including Javascript: https://github.com/anchore/syft/issues/572 -- once implemented, we could use those relationships to filter out the dev dependencies.

Are you scanning a built production image, or are you scanning a directory on disk? If you're scanning a finished image, we shouldn't be picking up the dev dependencies at all.

(Dev note: this issue seems to be asking for something similar: https://github.com/anchore/syft/issues/2348)

omerfinger commented 9 months ago

Thank you! I'm using it for scanning code, not image.

spiffcs commented 9 months ago

Here is a good outline of the different ecosystems and how we could organize the relationships for each one: https://github.com/anchore/syft/issues/572#issuecomment-1000412163

For anyone who comes across this issue and wants to pick up note that this would be a syft change first which would allow grype to key off of the relationships which would cause a package to be excluded.

@fingeromer are there cases where certain dev dependencies should be considered for analysis (vulnerabilities during build/bundling) or is the very simple YES/NO dev dependencies the only filter needed for the source scanning?

I think the feature would be OFF by default given that there are instances where dev dependencies have SOME affect on the final production artifact. A user should probably not feel 100% secure if this option is enabled and some dependency that could cause an unwanted change in the final production artifact is otherwise ignored.

There are two PRs we would expect for this issue to close:

  1. is associated with 572 that surfaces dev dependencies
  2. is the follow up in grype that has the option to filter and prune those packages based on the new dev dependency relationship