Ignoring stuff

[itaysk]

There's a bit of confusion around how to ignore things, and what is supported (#3490, #3486, #3572)
I think the docs needs rewriting around that area. I had a chat with @knqyf263 and we realized this is more involved than just rewriting the doc. Here's how I currently see things. I'm sharing it here for feedback, and if there aren't objections we can create issues and follow this plan.

Terminology

The words we used around "policy", and "ignore" were ambiguous. I propose the following (for now just for this doc, in the future maybe more)

1. check: something that Trivy can detect. for example - misconfiguration issue
2. policy: some business logic to make a decision. NOT a rego check.
3. skip: tell trivy to not try to scan something
4. ignore: tell trivy to not report something that was detected

Skipping (inputs)

Skipping is supported on the following:

1. scanned files:
   1. --skip-files
   2. --skip-dir
2. checks :
   1. --policy. A rego file can contain conftest-inspired exception policy.
      1. Rename --policy to --checks
      3. TODO: Rename exceptions rule to skip
   2. --ignored-licensed

Ignoring (outputs)

Ignoring is supported on the following:

1. results:
   1. --ignorefile ~/.trivyignore: ignore by any ID
2. --ignore-policy: rego policy on results
3. --ignore-unfixed
4. //tfsec:ignore inline declaration. TODO: turn into //trivy:ignore Support Inline Filtering #2961

[AnaisUrlichs]

That makes sense to me. I just want to raise one thing that is confusing to me as a user

2. TODO: Alias as --checks as --skip-checks. If a user wants to just skip some built-in check, it's awkward they need to use the --checks flag for this.

So far, to me, the --policy flag refers to anything I define through rego -- whether that is to check something specific or to skip a check so I am not sure I follow the reasoning behind having to divide it into --checks and --skip-checks?

Also, --ignore-policy currently refers to Rego which tells the vulnerability check to ignore a vulnerability in the reported scan result, which is different to what we currently call exceptions. How does this translate, if there is a difference in scanning, would it be confusing for users if it is all names --skip-checks?

as a next step, we have to discuss the different sections in the docs that need to be updated or rewritten.

[itaysk]

not sure I follow the reasoning behind having to divide it into --checks and --skip-checks

The suggestion is not to divide them but to support both options. you are right that --checks points to a dir with both "checks to include" and "checks to skip", and I thought it might be confusing for someone who wants to just skip checks and has to use --checks for that, so I suggested to allow calling the flag with both names --checks and --skip-checks. BUT after reading your comment I realize it might be too much, we can leave --checks to be mean which checks to include or skip, depending on which files are given. I've edited my suggestion to reflect this.

would it be confusing for users if it is all names --skip-checks

not sure I understand the suggestion. to rename --ignore-policy to --skip-policy?

Regardless, you made me realize that I had a mistake in the first message, and the rego rule for ignoring results is called ignore not exception as I thought, so I removed the TODO to rename it as well.

[simar7]

Just wanted to add my 2c here. As far as ignoring particular policies are concerned, we could add support for more granular checks that could be potentially scoped per file, if need be.

So for example:

---
  AVD-DS-123
  - "path/to/dockerfile1"
  - "path/to/dockerfile2"
  CVE-2023-456
  - "someimage:latest"
  AVD-DS-789

In this case, both AVD-DS-123 and CVE-2023-456 are scoped to particular elements. Elements here can imply, docker files, image names, k8s primitives etc.

For this particular example it is the two Docker files and one image with a tag respectively. In these two cases, these two will only be ignored within the specified elements.

As for the AVD-DS-789 it is ignored on a global basis. Which is the existing behaviour today.

[AnaisUrlichs]

I like this option

[AnaisUrlichs]

How would I specify multiple IDs to be ignored in the same file
Would it be possible to write it the other way around:

---
"path/to/dockerfile1"
  -   AVD-DS-123
"someimage:latest"
 - CVE-2023-456
AVD-DS-789

just because I imagine that people would want to specify multiple vulnerabilities to be ignored in the same file vs the vulnerability to be ignored in multiple files?

[simar7]

How would I specify multiple IDs to be ignored in the same file

Something like this could work:

---
  AVD-DS-123
  - "path/to/dockerfile1"
  - "path/to/dockerfile2"
  AVD-DS-456
  - "path/to/dockerfile1"

just because I imagine that people would want to specify multiple vulnerabilities to be ignored in the same file vs the vulnerability to be ignored in multiple files?

Yes and no. If there is an "unfixable" vulnerability, it's more likely to be noise than signal, in which case you'd have the same vulnerability show up in different places. That I assume you'd like to silence/ignore with the above approach where keys are the vulnerability IDs.

But you can also argue if there are limited files (maybe 1 or 2) that are being scanned and lots of vulnerabilities amongst them, then the above approach will get unwieldy.

I think the former is more common than the latter. Usually there are more things to scan and less vulnerabilities to ignore.

[AnaisUrlichs]

Ok, that makes sense
Would we allow tho to ignore the ID in an entire directory?