Generate CycloneDX SBOM with Conan deployer

[mcc0nnell]

Fixes #824.

This supersedes #844 and incorporates the review feedback from @PengZheng and @pnoltes.

The change keeps SBOM generation in the existing Conan CI and uses Conan’s built-in cyclone_1.6 deployer. It also adds a committed Conan lockfile as a reproducible safe-default dependency baseline, while preserving the ability for downstream Celix users to select or override their own dependencies.

The safe-default lockfile is intentionally stored at:

conan/safe-defaults.lock

rather than as a root-level conan.lock. Conan automatically discovers a root conan.lock, which would implicitly constrain unrelated Celix builds. Keeping it at an explicit path makes use of the baseline opt-in.

For the Linux/GCC/Release configuration, CI generates the CycloneDX 1.6 SBOM with:

conan install .
--lockfile=conan/safe-defaults.lock
--deployer=cyclone_1.6
--deployer-folder=sbom
-b missing
-pr:b default
-pr:h default
-s:h build_type=Release
-o celix/:build_all=True
-o celix/:celix_cxx17=True
-o mosquitto/*:broker=True
-o *:shared=True

CI publishes both:

• conan/safe-defaults.lock
• sbom/sbom-cyclonedx-1.6.json

together as the celix-conan-safe-defaults artifact.

The lockfile records the exact Conan recipe revisions used for this documented baseline. It is not intended to be repository-wide dependency policy: applications remain free to build without it, override dependency versions, or maintain their own lockfile and matching SBOM.

Documentation has also been added explaining the baseline, its scope, how CI generates the SBOM, and how users can opt into the same dependency graph locally.

Validation

• Uses Conan’s built-in CycloneDX 1.6 deployer; no custom SBOM generator.
• Uses a lockfile generated from the canonical Linux/GCC/Release full-feature Conan graph.
• The lockfile and SBOM describe the same resolved dependency baseline.
• Ordinary Celix builds do not implicitly consume the safe-default lockfile.
• Different platforms, build options, and downstream dependency overrides remain supported.
• SBOM guidance is linked from the main Celix documentation.

[PengZheng]

I would like to invite @pnoltes to have a look.

[PengZheng]

I'm not sure whether conan_create.yml is the right place to add SBOM support, since a conan package is just a recipe to cook, not the final binary package and SBOM only makes sense for binary package.

For example, I can use --require-override conan option when building Celix to upgrade openssl to fix a security vulnerability without modifying either Celix or the Celix conan reciple. And in this case both SBOM and the final binary artifact will change

[PengZheng]

To my understanding, SBOM should be used with the final binary, thus uploading SBOM alone makes no sense.

[pnoltes]

We can use the SBOM to scan the resolved dependencies for vulnerabilities, as described in a separate follow-up ticket: [#825](#825).

Then we at least know which vulnerabilities exist in the dependencies selected by the current default resolution. However, I am not sure how useful this is without a conan.lock file. With a lockfile, the Celix sources would include a reproducible, resolved dependency list.

Maybe we could generate the lockfile for a GCC Linux build on Ubuntu with build_all=True and use it as our canonical dependency reference. It could then serve as the basis for future vulnerability scans and help ensure more reproducible builds. (and we should document the intended use for a the lockfile and explain that celix is useable without a lockfile).

@PengZheng, maybe we should introduce such a lockfile. WDYT?

[PengZheng]

We can use the SBOM to scan the resolved dependencies for vulnerabilities, as described in a separate follow-up ticket: [#825](#825).

This can be done with Conan Audit. We can use it to generate vulnerabilities reports so that we can update Celix dependencies promptly to provide our users with safe defaults.

maybe we should introduce such a lockfile. WDYT?

Both SBOM and lockfile are associated with a specific set of dependencies/options, and our users have freedom to change them at their will. IMHO, providing them a safe defaults should be enough for now.

[pnoltes]

Both SBOM and lockfile are associated with a specific set of dependencies/options, and our users have freedom to change them at their will. IMHO, providing them a safe defaults should be enough for now.

To ensure we are the same page, do you mean that

a) we should not configure a lock file in our source control

or

b) we can provide a lock file and sbom, but we should communicate that this is a safe defaults, and users have to freedom to change the dependency versions when needed.

I think I prefer option b, but then also document this more clearly (lock file exists for safe defaults, and help in reproducible builds during development)

[PengZheng]

I think I prefer option b, but then also document this more clearly (lock file exists for safe defaults, and help in reproducible builds during development)

I agree.

[mcc0nnell]

Thanks, this makes sense. I’ve updated the PR so the SBOM is now tied to the concrete Conan binary package rather than generated independently from the recipe.

The GCC job first creates celix/3.0.0, then consumes that package with the same settings/options and runs full_deploy and cyclone_1.6 in the same dependency-graph resolution. The publication step uses -b never so it cannot silently rebuild a different configuration.

CI now uploads the deployed binary packages and the matching CycloneDX SBOM together as a single artifact.

This should address the concern about dependency overrides changing the binary/SBOM relationship. Please let me know if you’d prefer a different packaging boundary.

[PengZheng]

The action you modified is only for testing. We don't use it to release anything and SBOM generation should be added to the binary release process.

And I just noticed that we do not make any binary release.

[pnoltes]

The action you modified is only for testing. We don't use it to release anything and SBOM generation should be added to the binary release process.

And I just noticed that we do not make any binary release.

What I have always understood is that ASF releases are primarily source releases, which is also what we do. Especially for Apache Celix, I expect a source release to be more useful because Celix is a framework rather than an end product. I personally see little value in installing a celix executable. The Celix libraries, bundles, and CMake files can of course be installed and used by downstream projects, but I am not sure whether we should provide and maintain an official binary distribution ourselves (small team).

[pnoltes]

The action you modified is only for testing. We don't use it to release anything and SBOM generation should be added to the binary release process.
And I just noticed that we do not make any binary release.

What I have always understood is that ASF releases are primarily source releases, which is also what we do. Especially for Apache Celix, I expect a source release to be more useful because Celix is a framework rather than an end product. I personally see little value in installing a celix executable. The Celix libraries, bundles, and CMake files can of course be installed and used by downstream projects, but I am not sure whether we should provide and maintain an official binary distribution ourselves (small team).

What I do see as a possibility - and we already do this a bit - is that we provide and push an Apache Celix dev container so that users can more quickly build applications using Apache Celix.