You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While most of Maven/Gradle projects are either a single module or multimodule projects producing binary artifacts from the same codebase repository, there are also projects whose modules are distributed across multiple codebase repositories that are still released in a multimodule project fashion. Typically such kinds of projects would publish a Maven BOM POM that lists all the individual modules/libraries released from their own code repos to represent the "framework" as a whole.
These BOM POMs are what users import/enforce in the projects by specifying the version of the BOM POM. So these BOM POMs are actually representing these projects: Jackson, Vert.X, Quarkus, etc.
This issue is to figure out a proper way to generate SBOMs for such frameworks/libraries.
The current implementation of the CycloneDX Maven plugin is based on the idea that a module producing a binary would have dependencies to analyze. And, in fact, each individual library in case of Jackson, Vert.X or Quarkus would have its dependencies to analyze. However, the code repository of the BOM POM that's representing the framework as whole will not actually have any dependencies, it would only have the dependencyManagement configuration, which is essentially as list of version constraints that should be applied when resolving dependencies of each individual framework library.
One approach to create an SBOM for such projects would be:
identify which artifacts listed in the dependencyManagement section of the BOM POM are meant to be used as direct dependencies of the framework;
resolve dependencies of each artifact identified enforcing the BOM POM of the framework (possibly generating its own SBOM);
aggregate the results from 2 into a single SBOM to represent the whole framework.
While most of Maven/Gradle projects are either a single module or multimodule projects producing binary artifacts from the same codebase repository, there are also projects whose modules are distributed across multiple codebase repositories that are still released in a multimodule project fashion. Typically such kinds of projects would publish a Maven BOM POM that lists all the individual modules/libraries released from their own code repos to represent the "framework" as a whole.
Here are a few examples:
https://github.com/FasterXML/jackson-bom
https://github.com/vert-x3/vertx-dependencies
https://github.com/quarkusio/quarkus-platform (more complicated example)
These BOM POMs are what users import/enforce in the projects by specifying the version of the BOM POM. So these BOM POMs are actually representing these projects: Jackson, Vert.X, Quarkus, etc.
This issue is to figure out a proper way to generate SBOMs for such frameworks/libraries.
The current implementation of the CycloneDX Maven plugin is based on the idea that a module producing a binary would have dependencies to analyze. And, in fact, each individual library in case of Jackson, Vert.X or Quarkus would have its dependencies to analyze. However, the code repository of the BOM POM that's representing the framework as whole will not actually have any dependencies, it would only have the
dependencyManagement
configuration, which is essentially as list of version constraints that should be applied when resolving dependencies of each individual framework library.One approach to create an SBOM for such projects would be:
dependencyManagement
section of the BOM POM are meant to be used as direct dependencies of the framework;FYI @hboutemy
The text was updated successfully, but these errors were encountered: