Feature: detect shipped vs non shipped dependency => generate version-less component when not shipped

[hboutemy]

based on multiple issues reported by users with SBOMs generated at build time by cyclonedx-maven-plugin until now vs what is really used at runtime (#472 #588 #357 ),

opened a draft proposal CycloneDX/specification#578

that led to a 2-sided conclusion:

• no need to update the CycloneDX spec
• but need for build-time generators to detect if dependency is really shipped (as in Maven shade or assembly or war or fat jar or executable jar...) or not (as in classical library dependencies, or provided when building a Maven plugin or Jenkins plugin or ...): if not shipped, it's more accurate to generate a version-less CycloneDX component

version-less CycloneDX components will let SBOM users know that they'll get an effective version decided by build tool when they consume the library, as Maven (or Gradle or SBT) will resolve all dependencies and when solving conflicts, will choose the effective consume-time version

version-less CycloneDX components will avoid reporting vulnerabilities from dependencies to library or plugins OSS projects that do not affect them per-se but only consumers if they did not get updated version at runtime

Now that this logic has been established, we need to implement: how to detect shipped vs non-shipped dependencies in a Maven build (eventually multi-modules)?

[ppkarwasz]

Now that this logic has been established, we need to implement: how to detect shipped vs non-shipped dependencies in a Maven build (eventually multi-modules)?

I think that independently of the (heuristic) logic used to detect if a dependency is shipped or non-shipped, we need a configuration option to override the automatic choice. What about starting with that, a simple dependenciesAreIncluded configuration parameter with a default that depends on the artifact type?

[algomaster99]

This is making me think that SBOM should be per artifact now and not a gav. Assuming there are shipped and not shipped dependencies only:

1. Outputting a "classical jar" is the default behaviour of maven-jar-plugin that is attached to package phase. So that can always have a versionless SBOM.
2. However, the shipped dependency could have the current SBOM already implemented by the plugin.

[ppkarwasz]

This is making me think that SBOM should be per artifact now and not a gav.

Yes, we should have the possibility to publish a different SBOM for each classifier at least. Some projects publish both normal and fat jars under different classifiers. jakartaee-migration seems like a nice example:

• It has a normal JAR with no classifier.
• It has a shaded JAR with a shaded classifier.
• It has two binary distributions (.zip and .tar.gz) with a bin classifier.

For this project, we would need 3 SBOMs.

[algomaster99]

Yes, @ppkarwasz ! But simply based on classifier would be hard because plugins allow to strip this and publish the jar. For example https://repo1.maven.org/maven2/io/github/algomaster99/classfile-fingerprint/0.14.1/ has a Jar file with no classifiers but it is actually shaded.

[hboutemy]

multiple SBOMs for 1 gav: I dislike complexity, particularly when I think at aggregate after it...
but facts are facts, we'll see, we're here going step by step because we know this will have implications

IMO, we need to create a sample project with multiple scenarios of "shipped or not shipped", done by various plugins/build practice
creating a multi-module project in https://github.com/CycloneDX/cyclonedx-maven-plugin/tree/master/src/it should be easy to start
who does the first PR? should we create a dedicated branch, because we probably won't be ready to merge to master quickly?

[ppkarwasz]

In the long term it would be nice if the CycloneDX Maven Plugin was able to infer if the dependencies are bundled or not. However, for now we probably need only two small changes:

• A switch to allow users to specify if all compile/runtime dependencies are bundled or none of them.
• A configuration option to add a "classifier prefix" to the SBOM. We would append -cyclonedx to the classifier to prevent users from publishing stuff that can not be automatically detected by tools.

multiple SBOMs for 1 gav: I dislike complexity, particularly when I think at aggregate after it...

Isn't this what Maven 4 does by adding classifiers to BOMs? E.g. *-slim.pom, *-fat.pom?

IMO, we need to create a sample project with multiple scenarios of "shipped or not shipped", done by various plugins/build practice creating a multi-module project in https://github.com/CycloneDX/cyclonedx-maven-plugin/tree/master/src/it should be easy to start who does the first PR? should we create a dedicated branch, because we probably won't be ready to merge to master quickly?

We could start a branch with some ITs and we merge it once the ITs pass. I can create some ITs, could you create the branch?

[hboutemy]

branch created https://github.com/CycloneDX/cyclonedx-maven-plugin/tree/589-shipped-or-not-deps

Isn't this what Maven 4 does by adding classifiers to BOMs? E.g. *-slim.pom, *-fat.pom?

no: build vs consumer POMs (and not BOMs) are more basic (= strictly 2) than varying number of compositions based on yet to be precisely defined conditions :)

[hboutemy]

#576 was my initial try: need to reuse content...

[algomaster99]

The Surprise of Multiple Dependency Graphs: Dependency resolution is not deterministic motivates this PR.
Summarised it here - CycloneDX/specification#578 (comment).