Should Gradle sub-projects be added as components?

[malice00]

I've been checking my Gadle SBOMs and testing with different versions of cdxgen. I noticed there is regressions for Gradle sub-projects in v9 of cdxgen.
It seems that sub-projects are now added as sub-components instead of actual components. This means that eg dependency-track is unable to correctly show the dependencies, as it apparently doesn't handle the sub-components.

My question is, if sub-projects should actually be added as normal components instead (as it was in v8) or if this is something dependency-track should change?

Side-note: I feel that the results of scanning my multi-module Gradle project actually gives me false results -- when I scan all projects, I get certain dependencies in multiple versions, which I think is wrong (I admit I still don't fully understand Gradle, but I compare it to Maven, which I do understand).
So, I prefer to 'only' scan my ':app'-module, which depends on all the other sub-projects and now I do only get a single version of my dependencies. Only problem now, is that the sub-projects are nowhere to be found in the SBOM at all, so the dependency-tree is incomplete!

I feel sub-projects and/or referenced projects should be handled the same as any other dependency and added as a component.

Thoughts?

[prabhu]

@malice00 This is a great observation! With CycloneDX, we couldn't find an established way to represent the parent components hierarchy, so we devised a creative solution by working with another contributor to use metadata.component.components. I didn't realize it affected the dependency tree on the dependency track. Could you investigate further on this topic by doing the following?

• copy-paste the sub-project component from metadata.component.components to the components array and see if it resolves the problem. We can implement this workaround in cdxgen if it works.
• Try creating an issue in the dependency track project to see if they can support the nested components model.

Do you have a sample project or gradle dependencies output for multiple versions that illustrates the problem? You can join our discord and share the files directly via DM for private projects.

https://discord.gg/pF4BYWEJcS

[malice00]

Well, wasn't as hard as I thought... I have implemented a correct version that still uses metadata.component.components for multi-module projects, but adds the projects to components if they are not found as sub-projects (eg in single module scan). And I have a version that only uses components in either case.

I've also created an issue with dependency-track. If it gets fixed, sticking with metadata.component.components is probably the correct way to handle things.

[prabhu]

Do we get any validation errors if we also duplicate the sub-projects under components? We can add this workaround to cdxgen directly.

[malice00]

Just checked that -- I get no errors from cdxgen on generating, and no errors in dependency-track when importing. I assume that was what you meant? Can't say if there are other tools that might have objections though...

I do see some issues with this when dependency-track implements the PR I sent them for this --> it seems there is no check on duplicate items, so now the sub-projects get imported twice...
Maybe we should just go with either/or and not add them to both. Give the DT-guys some time to merge the PR and cdxgen can stick with the metadata.component.components-implementation.

[prabhu]

Thank you so much for your help. Please feel free to link your DT PR here for reference.

[malice00]

DT PR

[malice00]

I just create PR #470, with some fixes for the current solution -- it fixes some issues with incorrect naming (group, name, version, bom-ref and purl) and therefore an incorrect dependency-tree.