How can we make Grype's output more focused?

Grype
1

We have had a few issues on GitHub requesting, essentially, that Grype omit certain things from its output. This feels like general signal that Grype’s output has a lot of noise, and that the tool would be more valuable if it focused on displaying the more urgent and actionable subset of its findings.

Maybe there are feature requests, documentation improvements, or changes to defaults to be made here. Let us know what you think!

Some examples

There are probably others.

2

Why its important for my case (filter output by severity), i have automatic scans inside my clusters where a lot of deployments, and i send scan results (upload json) to devsecops platform via rest API to manage and mitigate them. If all severities in output - this leads large json file and send to api process is too long and more difficult to operate (or you need post-process). Filters by severities can help make automation more flexability and faster. Grype is powerful and my images benchmarks is better than another one (scans quality), this feature can help me to migrate fully to Grype. Thank you!

1 Like
3

Thanks @maskitron!

It sounds like the goal with this change is to make the output JSON smaller. I wanted to confirm this, because a lot of our discussions were about ideas that would make the standard table output smaller, but would not actually make the JSON smaller (because matches would be moved from the matches key in the JSON to the ignoredMatches key).

I’m going to propose a few changes to Grype. We’ll try discussing these at the next community meeting.

  1. Add a min-severity flag, that takes any severity level (negligible, low, medium, high, or critical) and ignores every severity below that level. So grype --min-severity low my-image would scan the image and ignore negligible severities, grype --min-severity medium would ignore low and negligible, etc.
  2. Change show-suppressed config value to affect JSON output. This value will default to “false” for the table format and “true” for other formats, but will be respected by the presenter of any format.
  3. Change the config file to enable adding an entry like - severity: negligible to the ignore node in Grype’s config file. (You can see a sample of the current file by running grype config).

At the next community meeting (tomorrow) we’ll try to discuss the pros and cons of making this particular change to Grype.

@maskitron for your use case, you would do something like GRYPE_SHOW_SUPPRESS=false GRYPE_MIN_SEVERITY=low grype ... and it would make JSON that includes none of the ignore vulnerabilities. Would that meet your us case?

4

First thing: I like the idea of excluding suppressed things by default, and only including them with --show-suppressed, and my vote would be to make this consistent across all outputs – table and JSON, so a user does not get a large set of ignored matches by default.

As we talked about, this has overlap with a desire to consolidate parameters (such as --only-fixed and kin) and avoid making a large number of flags. See Grype issue 197 for the similar discussion/suggestion.

As such, I think most users understand the ignore feature, and I would think adding an ignore flag might be a relatively simple path forward. Here’s what it looks like today in the config file:

ignore:
  # This is the full set of supported rule fields:
  - vulnerability: CVE-2008-4318
    fix-state: unknown
    # VEX fields apply when Grype reads vex data:
    vex-status: not_affected
    vex-justification: vulnerable_code_not_present
    severity: medium # this doesn't exist today
    package:
      name: libcurl
      version: 1.5.1
      type: npm
      location: "/usr/local/lib/node_modules/**"

Let’s say the user just wants to ignore a vulnerability ID, this could potentially be mapped to a CLI flag like:

grype --ignore vulnerability:CVE-2008-4318

The CLI could be a bit smarter about it and allow for some specific known single values to omit the qualifier and/or specify multiple values with a list separated by something, e.g.:

grype --ignore CVE-2008-4318 --ignore not-fixed --ignore package-name:libcurl,package-version:1.5.1,package-type:npm

… as for the severity ignore, I can’t really think of a reason a user would want to ignore a specific severity but include “lower” severities, so I’d vote to make something like: --ignore medium identify that medium is a known severity keyword (or --ignore severity:medium with the qualifier), and ignore all matches with medium and below.

Perhaps there could be an flag to do opposite things, so --only fixed or --only severity:medium could behave as you might expect.

1 Like
5

In our case, we built a meta distribution based of several distros. We have different flavors for each and scan each one. This results in a very high number of reports that we upload to github scan which makes it very difficult to then navigate as its slows down the UI, makes the report huge to even check it manually and forget about showing the table, as its a huge wall of text.

In our case, having 7 distros + arm variations, makes the final alerts between all of the to be about 6000 items :smiley:

Some of those as very low or medium reports which we are not really interested on, so a switch to only shown and only report the severities wanted (or exclude the ones not wanted ) would be really helpful.

In fact, I just checked and the github UI even craps out when trying to show the +5000 issues, after trying to load them for a while :smiley:

And the report for Rockylinux-9 wont even show any results as its over 6000 items

image
image1908×865 77.1 KB

6

Thanks for the input @Itxaka - that sounds like a cool use case.

The discussion here has fizzled a bit but I want to keep the momentum going and drive towards a decision, because lots of people want this in various forms.

So I have 2 questions:

  1. Does anyone have strong reasons not to do @kzantow’s suggestion?
  2. Does anyone have a use case that suggestion wouldn’t cover?

If there are no strong reasons not to do the suggestion and no one speaks up with a use case it doesn’t cover, I vote we do that soon-ish.

I especially like that it elevates --ignore to a command line flag, so that it can be used more conveniently when running grype interactively.

7

I take the output and then have to hack together an output via awk, sed and grep. I am sure my scripts have bugs and that my script will break upon a newwr release of Grype. Some fine grain “advanced” parameters would go a long way to avoid having to hack together a bash script OR have to write a small program in GoLang to parse the JSON

Managment is always asking me 3 questions -

How many Critcal and High vulnerabilities do we have in total?

How many critical and High Vulnerabilites do we have that are Older than 90 days SLA.

How many critical and High Vulnerabilites do we have that are Younger than 90 days SLA.

Use Case:

By Number of Vulnerabilites:
Jenkins Job to run the Grype Docker container on a Docker host and then output the # of Critical vulnerabilities. If # of Critical vulnerabilities is greater than X fail the Jenkins job, which in turn sends a email notification with appropriate severity.

Jenkins Job to run the Grype Docker container on a Docker host and then output the # of High vulnerabilities. If # of High vulnerabilities is greater than X fail the Jenkins job, which in turn sends an email notification with appropriate severity.

Jenkins Job to run the Grype Docker container on a Docker host and then output the # of Medium vulnerabilities. If # of Medium vulnerabilities is greater than X fail the Jenkins job, which in turn sends an email notification with appropriate severity.

By number of Vulnerabilities and newer than a certian number of days.
Jenkins Job to run the Grype Docker container on a Docker host and then output the # of Critical vulnerabilities newer than X days. If # of Critacl vulnerabilities is greater than X fail the Jenkins job, which in turn sends an email notification with appropriate severity.

Jenkins Job to run the Grype Docker container on a Docker host and then output the # of High vulnerabilities newer than X days. If # of Critacl vulnerabilities is greater than X fail the Jenkins job, which in turn sends an email notification with appropriate severity.

Jenkins Job to run the Grype Docker container on a Docker host and then output the # of Medium vulnerabilities newer than X days. If # of Critacl vulnerabilities is greater than X fail the Jenkins job, which in turn sends an email notification with appropriate severity.

8

In my cases above, I manual keep a list of CVE’s that management wants to ignore and parse them out of the output.

Currently these ignores are a minor inconvenience for us, but I could definitely see that this would be important for larger organizations that have tons of apps and CVE’s to track.

9

Maybe a --countonly parameter that would return the counts and not the actual CVE records?

10

@TimBrown1611 had a great suggestion:

I think grouping by RPM source, so that direct matches on source RPMs and indirect matches on RPMs derived from them are grouped together, is something we should strongly consider here. It also might reduce the confusion people have around indirect matches.