ARTEMIS-6209 Generate an SBOM for the distribution

[aloubyansky]

This PR adds SBOM generation to the Artemis distribution and enables options to distribute it along:

• as a distribution archive entry (embedded);
• as a Maven artifact;
• or both.

The SBOM will be more complete (including the NPM components) when the corresponding change is merged and released as part of artemis-console (apache/artemis-console#219).

Advantages of the SBOM:

• simplified vulnerability scanning (e.g. grype bom.cdx.json);
• consolidated license report per component;
• up-to-date accurate component inventory.

The SBOM generator used here is https://github.com/cyberstamp/maven-assembly-sbom

I did some analysis of the generated SBOM accuracy and comparison of the LICENSE report in my other branch, where I have an HTML summary of that https://github.com/aloubyansky/artemis/blob/sbom-support-wip/artemis-distribution/sbom-review.html

I previously demoed this to @brusdev

[jbertram]

@clebertsuconic, @gemmellr, @brusdev, publishing an SBOM for the full assembly seems like a good idea. I've been wanting to publish SBOMs for our Maven artifacts as discussed here as well.

Thoughts?

Before merging I'd want to address a few things:

1. The plugin is at 0.1.1 (0.1.4 is already out) and it has just a single maintainer and no visible community adoption. @aloubyansky, do you expect future development and wider adoption?
2. This needs a Jira with a reference in the commit message.
3. Versions are hardcoded in artemis-console/pom.xml and artemis-distribution/pom.xml. These should be managed like other versions instead.
4. We should probably merge Bundle an SBOM inside artemis-console WAR artemis-console#219 first.
5. We need to verify that this won't break build reproducibility. @aloubyansky, do you have any insight on this point?
6. Content-hash matching implies a lookup against known artifacts. Does that require network access at build time?
7. Is there any way (aside from manual inspection) to independently validate the accuracy of the result?

[aloubyansky]

1. The plugin is at 0.1.1 (0.1.4 is already out) and it has just a single maintainer and no visible community adoption. @aloubyansky, do you expect future development and wider adoption?

Certainly. A similar PR was open for Keycloak and the core artifact is used as dependency of the WildFly Galleon plugin to generate SBOMs for WildFly.
The issue is that there is no alternative implementation that I could find to generate an SBOM for an assembly-based distribution. cyclonedx-maven-plugin is manifesting project dependency graphs, which is not what we need in this case.

Upgrade from 0.1.1 to 0.1.4 is a no-op for Artemis.

2. This needs a Jira with a reference in the commit message.

I created https://issues.apache.org/jira/browse/ARTEMIS-6209 and referenced in both Bundle an SBOM inside artemis-console WAR artemis-console#219 and this PR's commit messages.

3. Versions are hardcoded in artemis-console/pom.xml and artemis-distribution/pom.xml. These should be managed like other versions instead.

Fixed in both PRs.

4. We should probably merge Bundle an SBOM inside artemis-console WAR artemis-console#219 first.

For a complete SBOM - yes. It can work in this repository w/o it but the NPM dependencies will be missing until a version of artemis-console bundling its SBOM is integrated in this project.

5. We need to verify that this won't break build reproducibility. @aloubyansky, do you have any insight on this point?

Yes, given the project sets project.build.outputTimestamp, it gets picked up by the SBOM generator and the serial number is generated taking that timestamp into account.

6. Content-hash matching implies a lookup against known artifacts. Does that require network access at build time?

No, content-hash matching is used for matching files on disk to Maven project dependencies (since files on disk can get renamed). It doesn't look beyond the scope of the project or reach out to external services or repositories.

7. Is there any way (aside from manual inspection) to independently validate the accuracy of the result?

That's a tricky one. There could be a few things to verify, depending on what you care about the most:

• components (Maven artifacts and NPM packages) - i suppose there could be some scripts that could analyze project dependencies and match the SBOM, however, there are some edge cases with shaded artifacts that aren't on the surface but also verifiable. This is actually the kind of analysis this tooling performs.
• licenses - that's actually a hard one. For NPM we use https://github.com/cyberstamp/cdx-npm-enrich and for Maven we read it from the POMs, which, depending on the maintainers, is not always guaranteed to be present or accurate. For Artemis specifically, it looked pretty good last time I checked. SBOM license info looked even better compared to the license files in the project. We may need an option to manually enforce certain licenses on some artifacts in case one day some inaccuracy gets surfaced from POMs.
• hashes, dependencies between components, occurrence locations, etc (probably less important but if present they should be correct).