enricher: add RHCC enricher

[crozzy]

This change introduces an enricher who's purpose is to scope down the vulnerability report for layers that have RHCC packages. This approach helps to keep the index report unchanged and therefore state is less of an issue, it also builds on existing machinary.

[codecov]

Codecov Report

Attention: Patch coverage is 84.21053% with 3 lines in your changes missing coverage. Please review.

Project coverage is 55.47%. Comparing base (7088f7b) to head (0a9465c).

Files with missing lines	Patch %	Lines
enricher/rhcc/rhcc.go	87.50%	1 Missing and 1 partial ⚠️
rhel/rhcc/scanner.go	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1057      +/-   ##
==========================================
+ Coverage   55.41%   55.47%   +0.05%     
==========================================
  Files         282      283       +1     
  Lines       17890    17906      +16     
==========================================
+ Hits         9914     9933      +19     
+ Misses       6934     6931       -3     
  Partials     1042     1042              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[crozzy]

The result is something like this:

{
  "message/vnd.clair.map.layer; enricher=clair.rhcc": [
    {
      "2": "sha256:013d2d7b1d1f8a94ffb762e6960fb5f483c60e38bd8740b1ec1f1a557d3d1bbf",
      "4": "sha256:013d2d7b1d1f8a94ffb762e6960fb5f483c60e38bd8740b1ec1f1a557d3d1bbf",
      "6": "sha256:d93e847446533e9af99b246c8cebea2527bf3e9db82e45fb59e3d9f1443a7d2c",
      "8": "sha256:d93e847446533e9af99b246c8cebea2527bf3e9db82e45fb59e3d9f1443a7d2c"
    }
  ]
}

There are a couple of ways to do this, it could also be technically reversed. In that case we'd have to just consider binary packages (at the moment each RHCC layer has a source and a binary package describing it). I'm not sure what consumers of Clair would prefer.

[hdonnay]

Question about the approach

[RTann]

Haven't looked at the logic much yet, but I have a question. It was brought to my attention layers may be squashed, even if from the base image. For example podman build --squash-all. In that scenario, we will just see a single layer I believe, and I'm not sure how useful this would be in that scenario. I'm wondering what your thoughts are about this? I'm not saying to throw this out, but rather we may just need to make it clear to users that this may not be that useful for those images which are completely squashed

[crozzy]

Haven't looked at the logic much yet, but I have a question. It was brought to my attention layers may be squashed, even if from the base image. For example podman build --squash-all. In that scenario, we will just see a single layer I believe, and I'm not sure how useful this would be in that scenario. I'm wondering what your thoughts are about this? I'm not saying to throw this out, but rather we may just need to make it clear to users that this may not be that useful for those images which are completely squashed

If the image is squashed we should still be able to identify every RH layer that has composed the squashed layer but yeah, any client making decisions off of this information would need to be aware that it's fallible if the input has been manipulated. Clients could potentially be told to ignore vulnerabilities in RH layers that are squashed together with application layers.

[hdonnay]

SGTM

Let's rescue this one.

[crozzy]

I think this wouldn't work directly with #1544 as the repository.Name is now potentially variable, I need to change it to use repository.Key (link), going to draft until #1544 is merged.