Add option for generating the SBOM as if the project is consumed, fix… #357
Conversation
CycloneDX#312 Signed-off-by: Kevin Conner <kev.conner@gmail.com>
| @@ -167,6 +167,15 @@ public abstract class BaseCycloneDxMojo extends AbstractMojo { | |||
| @Parameter(property = "excludeTypes", required = false) | |||
| private String[] excludeTypes; | |||
|
|
|||
| /** | |||
| * Generate the dependency graph as if the project was being consumed. This will resolve dependencies while | |||
| * excluding dependencies with Optional, Test and Provided scopes. | |||
There was a problem hiding this comment.
oh "exclude Maven dependencies marked as optional in POM, or scope test or provided" is what you call "as consumed"?
is that description strictly accurate or approximative?
There was a problem hiding this comment.
It's accurate in that it's how the maven resolution mechanism treats dependencies which are non transitive. The selector is set up in DependencyCollectorRequest.
The PR works by demoting all direct artifacts (level 1) down to level 2 so they are treated the same as if they are pulled in through a transitive dependency.
There was a problem hiding this comment.
to get an equivalent result from default config, you just need to disable provided Maven scope
I'm really not convinced of the whole story around this feature
There was a problem hiding this comment.
to get an equivalent result from default config, you just need to disable provided Maven scope
and also Test scope and then work out how to remove the optional dependencies (likely through a selector)
I'm really not convinced of the whole story around this feature
It comes down to the fact that the dependency graph created by maven when consuming an artifact can be radically different from the graph used to build the same artifact, this option is giving visibility into how the artifact will be consumed. This is in a similar area as the issues which cause the aggregate SBOM to be unreliable.
There was a problem hiding this comment.
you seem to expect to use CycloneDX SBOM dependency graph as a source of investigating what Maven dependency graph will do when consuming a library as a dependency: Maven has many mechanisms that are not visible to CycloneDX (dependencyManagement in addition to the Maven scopes and optional attributes that you already identified): I feel that this approach is doomed to fail
and I still don't get how users will activate, when, where they'll publish, with what name
= what I call the whole story, that will be so much complex to explain
sorry I really feel uncomfortable: I'd love to have other people's view on such topics
There was a problem hiding this comment.
you seem to expect to use CycloneDX SBOM dependency graph as a source of investigating what Maven dependency graph will do when consuming a library as a dependency
There are two purposes that I'm currently interested in
- build time (current graph) which describes the dependency graph used when the artifact was built (was the artifact built safely?)
- 'release' time (this change) describing the default dependency graph which would be inherited by consuming components (can the artifact be consumed safely?)
The difference between the two is certainly more marked within the maven dependency resolution process, because of the non-transitive dependencies.
The aim of the 'release' time graph is to allow analysis of the dependencies as they would be consumed by another artifact. It's easy to imaging a scenario where the build time graph would resolve an artifact to a version due to the non-transitive dependencies (say v1.2) but then resolve to a different, possibly vulnerable version when consumed (v1.1). If we can identify these issues as part of the build process then we can use them to gate the release.
Maven has many mechanisms that are not visible to CycloneDX (dependencyManagement in addition to the Maven scopes and optional attributes that you already identified): I feel that this approach is doomed to fail
Agreed, there are many ways in which a consumer can override the dependency graph (explicitly or implicitly) and force resolution to generate differing results.
and I still don't get how users will activate, when, where they'll publish, with what name = what I call the whole story, that will be so much complex to explain
That's a good question. Ideally there would be some metadata to distinguish the different perspectives being described in the SBOMs, perhaps this links in with the lifecycle discussions?
sorry I really feel uncomfortable: I'd love to have other people's view on such topics
+1 on canvasing others for their views.
…es #312