The ignore-base, ignore-unchanged, only-fixed, only-severities parameters should add-up together

[gustavovalverde]

Issue

I've been implementing this action to ensure our engineering team is informed if new vulnerabilities are introduced into our Docker image through the development process, particularly in PRs.

We want to avoid overwhelming the team with action comments in the PRs, as this could lead to warning fatigue. If notifications aren't actionable, they will likely be ignored over time.

Expected behavior

To address this, I would expect the ignore-unchanged option to prevent cves, recommendations, or compare information from being displayed when no new vulnerabilities have been introduced compared to the base image.

Additionally, the following options should work together: ignore-base, ignore-unchanged, only-fixed, only-severities.

Here’s what I envision:

with:
  command: quickview,cves,recommendations,compare
  image: <built-image>
  to: <base-image>
  ignore-base: true
  ignore-unchanged: true
  only-fixed: true
  only-severities: critical,high

This configuration would only display information in a PR if: there are new fixable high or critical vulnerabilities in the built image. Otherwise no information is displayed in the PR.

Current behavior

Even with all these parameters, comments will be displayed under the above condition.

[eunomie]

HI @gustavovalverde

Very interesting point.
Right now that can't work that way. Basically the condition is based on the comparison between the two images. But the 3 other commands are on the analyzed image. There's no kind of link between the commands and their output.

I haven't tried it yet, but one temporary solution might be to use write-comment: false and exit-on: vulnerability (or exit-on: policy if you're organisation is enrolled on scout.docker.com). That way the build step will fail. And in a next step in the GHA to react on failure and create a comment based on the Docker Scout step output (that contains the message, it's the text version and not the markdown one).
Not a perfect solution, but can be a way to start to enable it.

I'll open a discussion on this idea, to see if that's something we can improve.

[gustavovalverde]

I haven't tried it yet, but one temporary solution might be to use write-comment: false and exit-on: vulnerability (or exit-on: policy if you're organisation is enrolled on scout.docker.com). That way the build step will fail.

I might be mistaken, but if I do this, considering our image already has a critical vulnerability caused by gosu, more info here:

• Build gosu with a supported version of GO tianon/gosu#136

Then this step will always fail, as this is being triggered on the analyzed image. But it's not a new vulnerability compared with our latest image, it's an existing and acknowledged one. In any case, can I make exit-on: vulnerability fail just if a new high or critical has been introduced into the analyzed image (which would require a comparison with the the image in to: <base-image>?

Extra information

Based on what gosu's author suggest, this specific vulnerability should be treated as a false positive. Considering their Security README states the following:

As above, if you have a "security scanning" tool which does not agree with this policy, please take that up with your scanning tool vendor (report as a false positive, improve the tool to use govulncheck, etc).

But this is feedback for Scout, and not for this action.