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.