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
Hi @fingeromer, thanks for the suggestion. We have an issue to track dependency relationships in more ecosystems, including Javascript: anchore/syft#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: anchore/syft#2348)
Here is a good outline of the different ecosystems and how we could organize the relationships for each one: anchore/syft#572 (comment)
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:
is associated with 572 that surfaces dev dependencies
is the follow up in grype that has the option to filter and prune those packages based on the new dev dependency relationship
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.
The text was updated successfully, but these errors were encountered: