sbom creation in multimodule maven project

[20appy23]

Hello, I seem to have stumbled upon something which i am not sure is an expected behaviour or maybe my misunderstanding . I have tried to put everything together here.

We are using cycloneDx to create SBOM for our multi module maven project and Dependency track to visualise them. However it seems to show some strange results.
This is a jira project(complex structure) which is the parent project and has a number of modules(each having it’s own pom.xml), third party dependencies etc. One of these are our bundled plugins which is accessed from the internal repository of jira.

When I create SBOM on jira parent pom.xml, I find that the components of bundled plugin show zero vulnerabilities whereas when I run the cycloneDx on a particular plugin project(in our case mobile-rest), it clearly shows that some vulnerabilities do exist. However for some reason this is not captured when the parent project is used.

What I mean is parent A has a dependency on child project B which is added as a bundled plugin. When I add cyclonedx maven plugin to Child project B and run it as a separate project , create and upload it’s sbom to the dependency track, it shows certain vulnerabilities. However when it is listed as a component of project A, there seems to be zero vulnerabilities which is confusing.

Is this expected? How can I fix this?

P.S. I have tried using dependency-check on bundled plugins and it seems to show the vulnerabilities however sbom created under bundled plugins doesn’t seem to work.

Am i missing some configuration here or is this an expected behaviour?

Is there a workaround such that the bundled plugins are also included? Do I need to make some changes in the pom file of these plugins as well?

I have added the below to the parent pom.xml.

Here is a screenshot of the Parent project with the bundled plugin component showing zero vulnerabilities

Here you can see that when I have created a separate project namely mobile-rest-parent , it reflects the vulnerabilities

[hboutemy]

Thanks for reporting
CycloneDX Maven Plugin only lists dependencies, anything about vulnerabilities is done by Dependency Track: it's where you should start
We can do something here if you show us that something is wrong in an SBOM file as generated by CycloneDX Maven Plugin

[20appy23]

Thank you so much for your response. Maybe I can try and explain a bit more here. When I generate sbom for the child project separately as a standalone project and upload it to dependency track, I can see a list of dependencies and the subsequent vulnerabilities associated with it. However when I generate sbom on the parent project which includes this child project as a multi module maven project, I notice that it shows empty list of dependencies for the child project within the parent project. Could it be an issue with the sbom in that case or dependency track? I will try to share the sbom file redacted to see if that helps. Also, These child projects are bundled plugins which are already compiled and retrieved from the internal repository.

[hboutemy]

Could it be an issue with the sbom in that case or dependency track?

I suppose both

I will try to share the sbom file redacted to see if that helps.

yes, having a join look at the SBOM content may give us hints or whether it's the data in the SBOM that is missing, or DT that can't use it

[20appy23]

Hi, I have been trying to find a way to redact the SBOM since it contains data which may be considered sensitive to the organisation . Do you have any idea or tool which can help me do that? Or can I send you a more generic outline of the SBOM instead of the entire SBOM?

[hboutemy]

just look at the SBOM content: does it seem to contain the data you want DT to display?
If the data is there, I'd say DT is not able to display it, but it's about DT to tell why
If the data is not there, you'll have to precise what data you expect in the SBOM that you don't find

[20appy23]

I think I can have found a way to put this together in a better way.

1.) Generate SBOM on the mobile-rest plugin parent module(I used aggregateMakeBom) and upload to DT

what you see here below, is the graph which shows that parent has the mobile-rest submodule which has a dependency on spring v5.3.19

2.) Generate SBOM on the Jira parent project( here mobile-rest is a part of bundled plugin module)
what we see here is the graph which shows mobile-rest listed under the bundled plugin module. However when I check the list for dependency on spring v5.3.19, I see none!

Here my question is: shouldn’t it pick up the transitive dependencies of the bundled plugin as well? I was expecting the dependency hierarchy to be somewhat like Jira Parent -> Bundled Plugins -> Mobile Rest -> Spring 5.3.19

[knrc]

FYI, #312 is likely related as the dependency graph created when an artifact is consumed can be very different from the graph in effect when it is built.

[knrc]

and if you want to use an aggregate then you should be aware of #310

(see also https://trustification.io/2023/03/20/cyclonedx-maven-aggregate-bom-why-not-to-trust.html for more information)

[20appy23]

Thank you for the swift response. I have read your blog and it does seem like something is amiss in the dependency graph. However If I still want to use this, do you suggest I run makeBom separately for the bundled plugins? I have noticed makeBom does seem to take longer and for a project with 94 modules, it can be significant.

[knrc]

@20appy23 makeBom would give you a true dependency graph for how each project is built, but not necessarily how those artifacts are consumed by other projects, so it really depends on your use case.

With regards to the performance of makeBom can you try with the 2.7.8 release and see if it's the same? In order to fix an earlier bug I had to introduce some code to track versionless purls, which was impacting performance, but with the switch over to aether this is no longer necessary and has been replaced as of yesterday.

[20appy23]

I came across this #306 and it looks like this issue is being addressed there. May I ask if this has been merged and could possibly help with the current problem I have? Also with 2.7.8 release, is the performance improvement only wrt makeBom or also aggregateBom?

[knrc]

@20appy23 Unfortunately #306 (the PR for #310) is still under discussion. The changes in 2.7.8 should improve both makeBom and makeAggregateBom since the majority of the code is shared between the two.

[20appy23]

@knrc thank you for the info. I have also noticed some differences when i use the bom.json instead of the bom.xml, the number of components differ. Is it advisable to use the bom.xml for Dependency track rather? Could this be a json or xml issue or a DT issue?

[knrc]

@20appy23 Sorry, I don't know anything about Dependency Track. Do you have an example of when the json and xml differ? They should be generated from the same information so I'm surprised there would be any differences.

[20appy23]

@knrc
Here I have used the bom.xml

and here I have used the bom.json

I will try to generate this again and check if this still holds true

[hboutemy]

all what you report looks very DT oriented: wrong place here :)