Examples

[hboutemy]

Different cases require different SBOMs to describe more precisely the output artifacts: trying to get a global view based on past years of experience doing the generic base cases in CycloneDX Maven Plugin

[hboutemy]

thinking:
when dependency is embedded, we could probably add a CycloneDX evidence pointing to the jar (or classes in case of shade)?
when the dependency is not embedded, what should we put as evidence?

[hboutemy]

thinking:
given the vast diversity of plugins involved, with diversity of configuration of filtering of dependencies, how to support these use cases?
Should cyclonedx-maven-plugin try to detect build at runtime, extract other plugin execution configuration, and try to magically guess what SBOM details to generate?
Or should there more be a coordination of plugins generating SBOM instructions that would be read by cyclonedx-maven-plugin to do teh actual generation at the end?

[hboutemy]

thinking:
on one Maven module, defining one gav, how many different SBOMs will be necessary to describe the different outputs?
How will SBOM supplier manage them?
How will SBOM consumers consume them?

[ppkarwasz]

given the vast diversity of plugins involved, with diversity of configuration of filtering of dependencies, how to support these use cases?
Should cyclonedx-maven-plugin try to detect build at runtime, extract other plugin execution configuration, and try to magically guess what SBOM details to generate?
Or should there more be a coordination of plugins generating SBOM instructions that would be read by cyclonedx-maven-plugin to do teh actual generation at the end?

I think the last option is the better one. The way I see it:

• The CycloneDX Maven plugin creates a Source SBOM using only the pom.xml of the project and the pom.xml files of the dependencies. This can be done very early in the Maven LifeCycle and before any artifact is generated. The CycloneDX Maven plugin will attach an artifact with classifier cyclonedx to the build.
• The CycloneDX Maven plugin could provide some extension system to allow Maven plugins that generate artifacts to also post-process the initial SBOM (let's call the extensions CycloneDX postprocessors). For example:
  • The JAR postprocessor could be automatically executed after each Maven JAR Plugin execution and add the hashes of the JAR to the Source SBOM. It would replace the artifact with classifier cyclonedx with its own output.
  • The Shade postprocessor could take the SBOM generated by the JAR postprocessor and replace the dependencies section with a composition. Depending on the configuration of the Maven Shade Plugin, it would then replace the cyclonedx artifact or attach a new <shaded classifier>-cyclonedx artifact.

[hboutemy]

let's start with a simple case: war, where we have a dedicated CycloneDX Maven plugin goal