Add sbom generation tooling (#2232) #106

Lukasz-Juranek · 2026-01-31T09:15:06Z

This PR adds basic sbom bazel rules for details see

https://github.com/Lukasz-Juranek/score-tooling/blob/8e9cb957c32b7b2da9b4faf607be172ba9b14a6f/sbom/SBOM_Readme.md

Here are generated SBOMs for reference_integration targets:

sbom_kyron.cdx.json
sbom_kyron.spdx.json
sbom_orch_per.cdx.json
sbom_orch_per.spdx.json

Here is SBOM target definition: eclipse-score/reference_integration#83
Sbom is automatically generated no modiffications are needed for SCORE

Depending-on: eclipse-score/score-crates#24

This is not full solution but rather sth to begin with.
Happy to discuss this in details.

AlexanderLanin · 2026-02-02T13:29:47Z

@Lukasz-Juranek this looks interesting! Can you describe a little why we need custom code? No native bazel support etc.

Lukasz-Juranek · 2026-02-03T12:27:12Z

Hi right now i'm not aware of any out of box support for bazel that would really cover all c++ imports and rust code.

But IMO tooling itself is not important that much, this can be replaced later on with anything

What is important is to start getting the SBOM data for 3rd party dependencies in any meaningful format when there is not much deps, and to build in SCORE developers this behavior that when you import some stuff to your project you think about SBOM.

If SBOM data will be available then you can do conversion to some mature solution.

Lukasz-Juranek · 2026-02-07T09:46:17Z

Updated PR according discussion that we had https://github.com/orgs/eclipse-score/discussions/2226#discussioncomment-15669973

Now manual generation of is removed , sbom data is generated via

cdxgen for C++
for rust @score_crates//:MODULE.bazel.lock is used

Added mandatory fields from

CISA 2025 Element Coverage for CycloneDX

For details see updated readme https://github.com/Lukasz-Juranek/score-tooling/blob/8e9cb957c32b7b2da9b4faf607be172ba9b14a6f/sbom/SBOM_Readme.md

@masc2023 you asked for list of tools here it is https://github.com/Lukasz-Juranek/score-tooling/blob/8e9cb957c32b7b2da9b4faf607be172ba9b14a6f/sbom/SBOM_Readme.md#core-tools

AlexanderLanin · 2026-02-09T19:55:02Z

sbom/SBOM_Readme.md

+| [@cyclonedx/cdxgen](https://github.com/CycloneDX/cdxgen) | C++ dependency scanner and license discovery tool | C++ metadata extraction when `auto_cdxgen = True` |
+| [Node.js / npm](https://nodejs.org) | Runtime for cdxgen | C++ metadata extraction when `auto_cdxgen = True` |
+
+### Five-Phase Architecture


Which of these actually depend on bazel? Can we use this tool without bazel?

@AlexanderLanin thx for review.

cyclonedx/cdxgen you can use without bazel, both NPM and cdxgen are currently required on system to be installed on system they are not deployed via bazel.

Bazel is only needed to collect dependencies that are needed to build the target,
This data is then hold in sbom_aspect then tool is matching data from this structure to data from cdxgen and bazel lockfile

But if you have all data that is needed in dash-license-scan then we should use this as source of data, not cdxgen and bazel lockfile

Maybe lets make some short sync on this just ping me on slack when you will have time

For think that we can't use only the dash-licensese-scan but we can extract license data from it

Field crates_metadata.json provides dash-license-scan provides

version Yes Yes (from Cargo.lock parse)

license Yes (from crates.io API) Yes (from Eclipse/ClearlyDefined)

checksum (SHA-256) Yes No

purl Yes (pkg:cargo/name@ver) No (uses crate/cratesio/-/ format)

repository Yes (from crates.io API) No

AlexanderLanin · 2026-02-09T19:56:41Z

sbom/scripts/generate_crates_metadata_cache.py

+#!/usr/bin/env python3
+"""Generate crates.io metadata cache for SBOM generation.
+
+This script parses Cargo.lock files and/or MODULE.bazel.lock files,


cargo.lock parsing has also been implemented in dash-license-scan. Probably needs alignment.

AlexanderLanin · 2026-02-09T19:59:24Z

sbom/scripts/generate_crates_metadata_cache.py

+        lockfile_path: Path to MODULE.bazel.lock file
+
+    Returns:
+        Dict mapping crate name to {version, checksum, source}


how do you know which version to use? Thats the main reason I have not implemented bazel lockfile parsing in dash-license-scan, since there is no way to know which version is actually relevant?!

no i was not aware of this problem

AlexanderLanin · 2026-02-09T20:00:39Z

sbom/tests/test_cyclonedx_formatter.py

@@ -0,0 +1,142 @@
+"""Tests for CycloneDX 1.6 formatter."""
+
+import unittest


would you consider pytest? I don't know if its better or worse. But we use pytest everywhere.

ok i will change framework

AlexanderLanin · 2026-02-09T20:01:41Z

sbom/crates_licenses_common.json

@@ -0,0 +1,78 @@
+{
+  "serde": {"license": "MIT OR Apache-2.0"},


note that different versions can have different licenses

this file is not used ,

The actual license data now comes from crates_metadata.json (generated by the cache script from crates.io API + MODULE.bazel.lock).

i need to clean this trash

AlexanderLanin · 2026-02-09T20:02:45Z

sbom/defs.bzl

+    targets, traversing their transitive dependencies and generating output
+    in SPDX 2.3 and/or CycloneDX 1.6 format.
+
+    License metadata is collected automatically:


this is where dash-license-scan could somehow fit it. It collects verified license information.

i will check it if we can match get license field from dash output makes sense.

AlexanderLanin · 2026-02-09T20:26:36Z

sbom/SBOM_Readme.md

+# bazel_dep module (version from module graph)
+sbom_ext.license(
+    name = "googletest",
+    license = "BSD-3-Clause",


we should use dash-licene-scan and not write hand collected license infos

Lukasz-Juranek · 2026-02-10T21:50:28Z

@AlexanderLanin i've updated SBOM tooling to get license from dash you can take a look at some generated files

sbom_communication.cdx.json
sbom_kyron_module.cdx.json
sbom_baselibs.cdx.json

Two things to confirm

Dash only supports rust right ? I could not get cpp licenses
License ids like this are expected right ?

 "id": "Apache-2.0 AND MIT AND Apache-2.0 AND MIT"

evinoth1206 · 2026-02-11T17:23:50Z

Thanks for the work on the SBOM generation! I reviewed the CycloneDX output and have some feedback:

Must fix:

Invalid license format for compound SPDX expressions: When a component has multiple licenses combined with AND/OR, the current format uses "license": { "id": "Apache-2.0 AND MIT" }, which fails schema validation. The id field only accepts a single SPDX identifier. Compound expressions must use the expression field instead:
// ❌ Current (invalid):
"licenses": [{ "license": { "id": "Apache-2.0 AND MIT" } }]

// ✅ Correct:
"licenses": [{ "expression": "Apache-2.0 AND MIT" }]

Missing description field on all components. Every component should have at least a short description for SBOM usability

Nice to have (can be addressed in a follow-up):

Missing cpe identifiers for OSS components. Adding CPE entries (e.g. cpe:2.3:a:google:flatbuffers:25.2.10:::::::*) would improve vulnerability matching against the NVD.
Flat dependency graph. Currently all dependsOn arrays are empty except for the root component, which lists everything as a direct dependency. Ideally the graph should reflect actual transitive relationships (e.g. serde-derive depends on syn, quote, proc-macro2).

Lukasz-Juranek · 2026-02-12T19:31:16Z

Thanks for the work on the SBOM generation! I reviewed the CycloneDX output and have some feedback:

Must fix:

Invalid license format for compound SPDX expressions: When a component has multiple licenses combined with AND/OR, the current format uses "license": { "id": "Apache-2.0 AND MIT" }, which fails schema validation. The id field only accepts a single SPDX identifier. Compound expressions must use the expression field instead:
// ❌ Current (invalid):
"licenses": [{ "license": { "id": "Apache-2.0 AND MIT" } }]

// ✅ Correct: "licenses": [{ "expression": "Apache-2.0 AND MIT" }]

Missing description field on all components. Every component should have at least a short description for SBOM usability

Nice to have (can be addressed in a follow-up):

Missing cpe identifiers for OSS components. Adding CPE entries (e.g. cpe:2.3:a:google:flatbuffers:25.2.10:::::::*) would improve vulnerability matching against the NVD.

Flat dependency graph. Currently all dependsOn arrays are empty except for the root component, which lists everything as a direct dependency. Ideally the graph should reflect actual transitive relationships (e.g. serde-derive depends on syn, quote, proc-macro2).

Updated PR fixed licenses you can check this i've validated it using https://tools.spdx.org/app/ntia_checker/ and it passed

sbom_kyron_module.cdx.json
sbom_kyron_module.spdx.json

github-project-automation bot added this to INF - Infrastructure Community Jan 31, 2026

github-project-automation bot moved this to Draft in INF - Infrastructure Community Jan 31, 2026

This was referenced Jan 31, 2026

Add sbom targets (#2232) eclipse-score/reference_integration#83

Draft

Add sbom data for baselibs (#2232) eclipse-score/baselibs#93

Closed

Improvement: SBOM eclipse-score/score#2232

Open

Lukasz-Juranek force-pushed the feat/issue-2232-sbom-init branch from ffca1f1 to e308870 Compare February 7, 2026 09:37

Lukasz-Juranek force-pushed the feat/issue-2232-sbom-init branch 2 times, most recently from cad2c59 to 8e9cb95 Compare February 8, 2026 14:04

Lukasz-Juranek mentioned this pull request Feb 9, 2026

Add sbom generation tooling for rust and cpp(#2232) eclipse-score/score-crates#24

Draft

Lukasz-Juranek force-pushed the feat/issue-2232-sbom-init branch 4 times, most recently from 9382341 to c8d2a39 Compare February 9, 2026 19:51

AlexanderLanin reviewed Feb 9, 2026

View reviewed changes

Lukasz-Juranek force-pushed the feat/issue-2232-sbom-init branch from e208237 to 3c0af62 Compare February 10, 2026 07:24

Add sbom generation tooling (#2232)

35c92b1

Lukasz-Juranek force-pushed the feat/issue-2232-sbom-init branch from 3c0af62 to 35c92b1 Compare February 10, 2026 17:04

dcalavrezo-qorix mentioned this pull request Feb 11, 2026

Gap content eclipse-score/score#2019

Open

Add license dash support for license data extraction (#2232)

3d5b273

Lukasz-Juranek force-pushed the feat/issue-2232-sbom-init branch from 7b00264 to 3d5b273 Compare February 12, 2026 19:21

Merge branch 'main' into feat/issue-2232-sbom-init

fc2d4ea

Field	crates_metadata.json provides	dash-license-scan provides
version	Yes	Yes (from Cargo.lock parse)
license	Yes (from crates.io API)	Yes (from Eclipse/ClearlyDefined)
checksum (SHA-256)	Yes	No
purl	Yes (pkg:cargo/name@ver)	No (uses crate/cratesio/-/ format)
repository	Yes (from crates.io API)	No

		@@ -0,0 +1,142 @@
		"""Tests for CycloneDX 1.6 formatter."""

		import unittest

Add sbom generation tooling (#2232) #106

Are you sure you want to change the base?

Add sbom generation tooling (#2232) #106

Uh oh!

Conversation

Lukasz-Juranek commented Jan 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

AlexanderLanin commented Feb 2, 2026

Uh oh!

Lukasz-Juranek commented Feb 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Lukasz-Juranek commented Feb 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Lukasz-Juranek Feb 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Lukasz-Juranek Feb 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Lukasz-Juranek commented Feb 10, 2026

Uh oh!

evinoth1206 commented Feb 11, 2026

Uh oh!

Lukasz-Juranek commented Feb 12, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Lukasz-Juranek commented Jan 31, 2026 •

edited

Loading

Lukasz-Juranek commented Feb 3, 2026 •

edited

Loading

Lukasz-Juranek commented Feb 7, 2026 •

edited

Loading

Lukasz-Juranek Feb 10, 2026 •

edited

Loading

Lukasz-Juranek Feb 10, 2026 •

edited

Loading