Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SBOM generation for Maven BOM POM projects #373

Open
aloubyansky opened this issue Jun 15, 2023 · 1 comment
Open

SBOM generation for Maven BOM POM projects #373

aloubyansky opened this issue Jun 15, 2023 · 1 comment

Comments

@aloubyansky
Copy link

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:

  1. identify which artifacts listed in the dependencyManagement section of the BOM POM are meant to be used as direct dependencies of the framework;
  2. resolve dependencies of each artifact identified enforcing the BOM POM of the framework (possibly generating its own SBOM);
  3. aggregate the results from 2 into a single SBOM to represent the whole framework.

FYI @hboutemy

@adelavina
Copy link

+1 for dependencySupport

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants