Add more provenance information to SecObserve

[dervoeti]

It's often hard to find out how exactly a component was brought into an image. For example, our current workflow for Java dependencies involves cloning the source repo and looking and the output of mvn dependency:tree, which is cumbersome and error prone. We want to try out tools like ScanCode or find other ways to make the information on how a component is brought in easier discoverable, SBOMs might also be a good option.

Our solution will be to generate SBOMs for all the components in our images, create "merged" SBOMs containing all the information that Syft finds on top of the information that the CycloneDX plugins generate during build. This is needed, because neither of the tools can see all the information that's neccessary: Syft doesn't see the dependency tree and the CycloneDX plugins don't resolve shaded dependencies in Java (and maybe other things too).

• [x] Create a visualization for dependency trees in SecObserve
• [x] Create a tool / workflow to merge the SBOM information
• [x] https://github.com/stackabletech/docker-images/pull/814
• [ ] https://github.com/stackabletech/docker-images/pull/827
• [x] Scan our SBOMs instead of our images

[dervoeti]

Hit some problems when generating SBOMs at build time for some products:

• Kafka: Problem with the Gradle CycloneDX plugin and Scala (https://github.com/CycloneDX/cyclonedx-gradle-plugin/issues/239)
• OPA / statsd_exporter: cyclonedx-gomod expects the source code to be in a Git repo and obtains the version from the Git tag. Solutions:
  1. Patch cyclonedx-gomod
  2. Create a fake Git repo
  3. Clone the source code from Git instead of mirroring it in Nexus

The rest looks fine so far. The products with SBOM generation problems don't have too many vulnerabilities, so for the vulnerability analysis it's not dramatic that there's no dependency tree available in SecObserve.