-
-
Notifications
You must be signed in to change notification settings - Fork 85
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
Ensure aggregate BOMs contain exact dependency hierarchies from each Maven module #306
base: master
Are you sure you want to change the base?
Conversation
src/main/java/org/cyclonedx/maven/DefaultProjectDependenciesConverter.java
Outdated
Show resolved
Hide resolved
🛠 Lift Auto-fixSome of the Lift findings in this PR can be automatically fixed. You can download and apply these changes in your local project directory of your branch to review the suggestions before committing.1 # Download the patch
curl https://lift.sonatype.com/api/patch/github.com/CycloneDX/cyclonedx-maven-plugin/306.diff -o lift-autofixes.diff
# Apply the patch with git
git apply lift-autofixes.diff
# Review the changes
git diff Want it all in a single command? Open a terminal in your project's directory and copy and paste the following command: curl https://lift.sonatype.com/api/patch/github.com/CycloneDX/cyclonedx-maven-plugin/306.diff | git apply Once you're satisfied, commit and push your changes in your project. Footnotes |
we need a description of what this PR changed in terms of results: how is the new alternate dependency tree different (I suppose better :) ) from the previous one? |
9aaaaac
to
bbaa81e
Compare
…y hierarchies Signed-off-by: Kevin Conner <kev.conner@gmail.com>
Signed-off-by: Hervé Boutemy <hboutemy@apache.org>
If we were to stack rank the importance of data in an SBOM, it would be:
My issue with this approach is that data of lesser importance is taking priority over more important data in the BOM. We are sacrificing accurate inventory for the ability to have accurate dependency relationships. I don't know if it's worth the risk given that most systems will likely deduplicate the components anyway which will leave one of the branches in the dependency tree orphaned on import. Dependency-Track and likely many other systems will do this. |
@stevespringett Can you explain why you think this is sacrificing accurate inventory? The set of components included in the SBOM remain the same, the only change is that there will be duplicates of some because of the need for a different
They would likely face the same issue when importing the individual SBOMs, so either way there would be issues needing to be addressed. |
One reading the BOM will conclude that there are multiple of the same component included for the same metadata component, which is not true. By separating out the components into assemblies, the reader of the BOM will interpret this to mean the components are included in other components (maven modules) which in term are included in the same metadata component, which would be true statement.
Not sure about other systems, but users would not have any issues with Dependency-Track with this approach. Now, if we used component assemblies, I know Dependency-Track can handle parent/child components, but I don't know if it will deduplicate if the same component is used across multiple parent components. |
I'm not sure I would agree with that statement, if each of these projects were being packaged up you would end up with multiple instances of components with different dependencies so it's likely build dependent and not something we have sufficient information to reason about in the plugin.
The only way I can think of representing the above statement would be the exploded view through the assemblies, in which case de-duplication, as it is currently handled in the aggregate, would be wrong for both components and the dependency hierarchies (even if they were currently accurate). We would end up with an aggregated SBOM which was essentially nothing more than a concatenation of the individual SBOMs for each project. This is one of the approaches we discussed on the call resulting in the full, exploded dependency graph being represented.
I know guac would handle the de-duplication of the component if processing individual SBOMs, but I'm not sure how they would handle the same component being referenced multiple times in the same SBOM. I believe they would have the same issue whether using the solution from this PR or assemblies, since they generate a map of |
see #310 for more details