Hi!
I’m using grype in order to scan large VMs. The issue is that the SBOM size can’t indicate the size of results grype will generate, so some times the memory which is stored on grype increases and crashes my process on OOM.
my suggestion is using a flag, I’ll be able to filter out during runtime vulnerabilities which already existed in the results.
I know it is not the best practice, since a CVE can appear in multiple packages, but it can simplify the way we can run grype without crashing the process.
what do you think?
Hi @TimBrown1611 thanks for the suggestion!
My concern with this feature is that it would frustrate users, because they might see a CVE, and then upgrade the affected package, and then see it again.
I think a better workaround in the meantime is probably to run Grype and Syft on a subset of the system at a time. For example, you could run Syft with only the RPM cataloger enabled and pass the result to Grype, and then run Syft again with the RPM cataloger disabled and pass the result to Grype. Or maybe it makes sense to use directories instead of catalogers. Will this workaround help you in the meantime?
Also, I want to link back to the existing thread at Improvements to scanning whole machine because these conversations are related.
Hi @willmurphy
thanks for the suggestion, but this practice is not practical, since I don’t want to change the configuration each time I run grype.
currently the results are too large in some cases, and I need to find a way to make the process finish and not crush due to OOM, without changing the configuration each time I want to run it.
exclusion is same as filtering catalogers…
lots of the results are duplicated (kernel for example) and machines with 1000 dups for each package (which are the same) is making the results very large. maybe switching the schema to CVE point on a package can solve it?
this issue is a huge blocker for me 
1 Like