"False positives" in SBOM when building OSGi bundle with maven-bundle-plugin

[bpapez]

We recently started to use the cyclonedx-maven-plugin to create the SBOM of our OSGI components, which are built with the maven-bundle-plugin (from Apache Felix). We have detected that the created SBOM can contain several false positives due to the following behaviour (taken from the maven-bundle-plugin documentation):

Normally the plugin only checks direct dependencies, but this can be changed to include the complete set of transitive dependencies with the following option:

<Embed-Transitive>true</Embed-Transitive>

Let's take this example:

A module has a direct compile scope dependency to gcc-restclient. This jar will get embedded into the bundle and is also getting listed in the bom. The jackson-databind transitive dependency will not get embedded due to the default behavior of maven-bundle-plugin (see above quote). Still the cyclonedx-maven-plugin also lists jackson-databind version 2.9.9 as dependency with scope "required".

jackson-databind in our case is a "provided" scope dependency (deployed and provided in a much higher version than 2.9.9). We set includeProvidedScope to false in our cyclonedx-maven-plugin configuration.

Would it be possible to prevent the creation of such false positives in order to have a trustable bom? Could cyclonedx-maven-plugin check the used Embed-Transitive setting of maven-bundle-plugin or could you at least add a new option in your configuration to only check direct dependencies?

[hboutemy]

I don't fully get the reasoning, it's too abstract: can you share a full example, please?

[bpapez]

The above example is from a private repository. Here is a link to a public repository having the same problem: https://github.com/Jahia/LDAP-provider . The pom.xml has a dependency to org.springframework.ldap.spring-ldap-core:2.3.8.RELEASE . This library gets packaged embedded into the resulting ldap-*.jar bundle and also gets listed in the bom created with cyclonedx-maven-plugin. However the bom also contains the org.springframework.spring-beans:4.3.30.RELEASE (and others), which are not getting embedded into the bundle and are not existing at runtime. The provided spring-beans library has a different version.

We see the same pattern with all of our modules. The default behavior of the maven-bundle-plugin used to create the bundle is only considering the direct dependencies and no transitive dependencies.

[hboutemy]

IIUC, if you are building an OSGi bundle, you expect the SBOM to match OSGi way of defining dependencies, not Maven way? IIUC, your bundle does not really include the dependencies (like a war does), but only defines a requirement for an OSGi runtime, isn't it?
I'm not an OSGi expert, it always hurst my brain: I don't know how your case relates to the Tycho one #137
Tycho or not Tycho, the OSGi aspects are common, perhaps @laeubi can help

[laeubi]

@hboutemy what is happening here is that some classes are "shaded" inside the bundle, so lets say we have the chain A > requires B > requires > C

Now I embedd A (but not import nay package from B+C) then the chain is "broken" an B + C are not required by my final artifact, but thats nothing caclone-dx can decide I think as it is still possible that there are some imports.

I think the most "maven" way would be to declare the unwanted dependency in provided scope or even better exclude them (so you don't accidently depend on any transitive stuff), while it is true that Maven and OSGi metadata can differ, I think this is not a true OSGi problem here and not really a false positive as your maven dependency is there.

[bpapez]

The false positive is not related to the library, but to the version of the library. cyclonedx-maven-plugin creates an SBOM with library versions, which are not deployed anywhere - neither in the bundle nor provided by the application. This results in found vulnerabilities, which are all false positives.

Currently as a workaround we are indeed excluding the provided transitive libraries in the pom.xml.

[amergey]

The above example is from a private repository. Here is a link to a public repository having the same problem: https://github.com/Jahia/LDAP-provider . The pom.xml has a dependency to org.springframework.ldap.spring-ldap-core:2.3.8.RELEASE . This library gets packaged embedded into the resulting ldap-*.jar bundle and also gets listed in the bom created with cyclonedx-maven-plugin. However the bom also contains the org.springframework.spring-beans:4.3.30.RELEASE (and others), which are not getting embedded into the bundle and are not existing at runtime. The provided spring-beans library has a different version.

We see the same pattern with all of our modules. The default behavior of the maven-bundle-plugin used to create the bundle is only considering the direct dependencies and no transitive dependencies.

Hello.
We had similar behavior but we came to the same conclusion than laeubi. cyclonedx-maven-plugin don't car about maven-bundle-plugin and use maven dependencies declared in pom.xml which is expected. To eliminate a transtive dependency we do not want to package, we exclude it explicitely in pom, which is the safe way of doing it as we know for sure it will not be embedded and packaged whatever configuration there is for maven-bundle-plugin.