How to model native (C++) shared and static libraries dependencies

[alcroito]

Hi,

I have a native SDK that ships a few C++ projects compiled into shared libraries, some into static libraries, and some build tools.
A consumer C++ project would then use the SDK to link against some of those libraries and use some of the build tools to generate their own code, ultimately compiled into a library or executable.

The SDK ships:

1. libCore.so - shared library
2. libGui.so - shared library, has a dynamic linker dependency on libCore.so
3. libUtils.a - static library
4. libPlatform<x>.a - a set of static libraries for various platforms like windows, macos, linux. Has a dependency on libUtils.a. So any project that wants to link against libPlatform<x>.a, must ensure their build system also link against libUtils.a.
5. code_generator - a native build tool that generates C++ code that the user project should build and include in their app / library. This tool was also used for generating and building some of the shipped libraries.

I would like to ship a single CycloneDX BOM for this SDK, that would describe these libraries and tools.

For a SPDX sbom, both SPDX v2 and v3 have various relationship types like hasDynamicLink, hasStaticLink, dependsOn, spdx v2 hasBUILD_DEPENDENCY_OF, BUILD_TOOL_OF, etc that allow me to model these relationships.

My initial guess is that each of the libraries and tools should be represented by a CycloneDX component. But I'm less sure on what is the best way to model the dependencies.

I've seen #135 but that only mentions documentation references.

The spec has a dependencies key, but that lacks relationship types.
The spec has formulation with a nested components, but it's not immediately clear if that's appropriate here.

I would appreciate some guidance on what would be the best way to model this using CycloneDX.

Thank you.

[jkowalleck]

your goal is to describe your shippable product - the SDK - and it is an aggregate of those shared/static libraries?
So your goal is something like an architectural view of the SDK?

[alcroito]

your goal is to describe your shippable product - the SDK - and it is an aggregate of those shared/static libraries?

Yes, plus a tool.

So your goal is something like an architectural view of the SDK?

Not quite I guess.

The ultimate goal is empowering consumers of the SDK SBOM to do vulnerability scanning and license compliance.

So depending on how they use / link the SDK libraries, it affects vulnerability management and license compliance.

For example if a linked SDK library is LGPL licensed, depending on if it is static or shared, it affects which part of the license the consumer library needs to adhere to (give access to sources or not). And while determining this, it's important to check the transitive dependencies of the SDK library and the relationship type as well.

For vulnerability management, if a consumer app links to libGui.so, you want to know what 3rd party dependencies it has and if they were link dependencies or tool dependencies, which might influence the decision of whether the vulnerability affects the consumer.

[stevespringett]

For static linking, simply use an assembly (nested component). Since statically linked libraries are included/embedded in the thing that depends on them. For dynamically linked libraries, simply use a flat list of components (no nesting), since dynamically linked libraries are standalone files and not embedded.

For dependsOn, simply use the CycloneDX dependencies functionality and for build related information, use formulation. You'll find that CycloneDX has a ton of relationships, but it doesn't have a simplistic list like SPDX does. It's also a lot more granular, especially when it comes to formulation, but it can be a bit more of a learning curve - just because it has so much capability. Refer to https://cyclonedx.org/guides/OWASP_CycloneDX-Authoritative-Guide-to-MBOM-en.pdf to get started.