west spdx output SBOM files incorrect?

[greuljoSICKAG]

Hello,
I am trying to generate an SBOM for my project. I followed this guide using the west spdx command. I use the zephyr workspace application setup.

west spdx --init -d
west build -b MY_BOARD -d build
west spdx --analyze-includes -d build

My output files zephyr.spdx and modules-deps.spdx are attached (I changed the file ending to json since .spdx is not supported by github)
modules-deps.spdx.json
zephyr.spdx.json
. It seems like all project source files are scannend correctly but not mapped to the correct package. So in the end, I am missing the crucial information which components of zephyr are used and which not. E.g. I am sure to use hal_nordic, mcuboot, zcbor but they look no different in the output spdx files than all the rest.

1. How should a correct spdx file look like such that it is possible to read the used components from it?
2. What could go wrong in my case?

My ultimate goal is to load the spdx files to BlackDuck. But the above seems to me a neccessary step to get a correct scan.

Thanks a lot,
Joanna

[pdgendt]

These commands are Zephyr extensions and are not related west itself. Please move this issue to the https://github.com/zephyrproject-rtos/zephyr project.

EDIT: moved to zephyr

[github-actions]

Hi @greuljoSICKAG! We appreciate you submitting your first issue for our open-source project. 🌟

Even though I'm a bot, I can assure you that the whole community is genuinely grateful for your time and effort. 🤖💙

[kartben]

@greuljoSICKAG just to be sure, you did enable ``CONFIG_BUILD_OUTPUT_META`, yes?

[greuljoSICKAG]

Thanks for the reply.
Yes, I enabled CONFIG_BUILD_OUTPUT_META

[kartben]

@tgagneret-embedded can you please chime in?

[tgagneret-embedded]

Hello @greuljoSICKAG,

I wasn't able to reproduce your issue. I did a quick test with the following configuration:
west build -b nrf5340dk/nrf5340/cpuapp zephyr/samples/hello_world/ and the Nordic HAL files are in the correct packages (hal-nordic-sources).

Could you provide me an example to reproduce it on my end ? Can you give me:

• a zephyr example
• a board
• any modification in the prj.conf (if needed)

Thanks

[pdgendt]

Hello, I am trying to generate an SBOM for my project. I followed this guide using the west spdx command. I use the zephyr workspace application setup.

west spdx --init -d
west build -b MY_BOARD -d build
west spdx --analyze-includes -d build

The --init -d needs to be passed the build folder too, which seems to be missing in your command list. So make sure you do:

$ west spdx --init -d build
$ west build -p -b MY_BOARD -d build -- -DCONFIG_BUILD_OUTPUT_META=y
$ west spdx -d build

Currently the west spdx commands exit with 0 even if an error occurs, I bumped into that while toying with #83359

[kartben]

@greuljoSICKAG please let us know if there is anything else we can do to help, and/or please close the issue if the input provided by @pdgendt and @tgagneret-embedded helped you solve the issue.

[greuljoSICKAG]

Hello and thanks for the reply.

I got one step further. My SBOM now only lists the packages which I actually use.

• zephyr-sources
• cmsis
• hal-nordic
• littlefs
• mbedtls
• mcuboot
• segger
• tinycrypt
• zcbor

However, there are problems with finding the license. All I get is NOASSERTION for the licenses of the packages. (See zephyr.spdx.json for the entire SBOM)

Package: hal-nordic-sources

PackageName: hal-nordic-sources
SPDXID: SPDXRef-hal-nordic-sources
PackageLicenseConcluded: NOASSERTION
PackageLicenseDeclared: NOASSERTION
PackageCopyrightText: NOASSERTION
PrimaryPackagePurpose: SOURCE
PackageDownloadLocation: git+https://github.com/zephyrproject-rtos/hal_nordic@ab5cb2e2faeb1edfad7a25286dcb513929ae55da
PackageVersion: ab5cb2e2faeb1edfad7a25286dcb513929ae55da
FilesAnalyzed: false
PackageComment: Utility target; no files

Could this be due to the fact that Nordic has its own fork of Zephyr, the nRFConnectSDK? And that somehow references to nRFConnectSDK cannot be found the the west-spdx-command of the original Zephyr?

I find all the git-hashes of the used packages in this overview and they all point to the nRFConnectSDK.

[tgagneret-embedded]

Yes, only the compiled files are present in the SBOM.

For the license, I had a quick look at the code, it seems that it needs SPDX license at the beginning of the file (https://spdx.dev/learn/handling-license-info/). Zephyr RTOS has the correct syntax, but modules don't necessary use this syntax.

An example:

zephyr/kernel/banner.c

Line 4 in 4e201f2

* SPDX-License-Identifier: Apache-2.0

[greuljoSICKAG]

Hi again,

thanks for your replies.

First:

The part about the license makes sense. I guess that is up to the components to use that syntax for their license. So okay, I can look up the licenses "by hand" for now.

Second:

I reproduced my issue for the zephyr sample basic/blinky on board nrf52833dk_nrf52833.

Go from zephyr-workspace to zephyr/samples/basic/blinky and execute:

west spdx --init -d build
west build -p -b nrf52833dk_nrf52833-d build -- -DCONFIG_BUILD_OUTPUT_META=y
west spdx -d build

You get output files zephyr.spdx, build.spdx, modules-deps.spdx, app.spdx

Third:

I tried to load those outputs from the blinky sample into BlackDuck. The scan does not find the components and I already found the following two problems why this is.

Problem1:
The zephyr.spdx has the following entry:

Package: zephyr-sources

PackageName: zephyr-sources
SPDXID: SPDXRef-zephyr-sources
PackageLicenseConcluded: Apache-2.0 AND BSD-3-Clause
PackageLicenseDeclared: NOASSERTION
PackageCopyrightText: NOASSERTION
PackageDownloadLocation: git+https://github.com/zephyrproject-rtos/zephyr@36940db938a8f4a1e919496793ed439850a221c2
PackageVersion: 3.7.0
ExternalRef: PACKAGE_MANAGER purl pkg:github.com/zephyrproject-rtos/zephyr@v3.7.0
ExternalRef: SECURITY cpe23Type cpe:2.3:o:zephyrproject:zephyr:3.7.0:-::::::
PackageLicenseInfoFromFiles: Apache-2.0
PackageLicenseInfoFromFiles: BSD-3-Clause
FilesAnalyzed: true
PackageVerificationCode: 98b220c63cb7c087430fdde1568c4f61fafa2cf8

BlackDuck indicates that the ExternalRef can't be found. So I looked into the purl link and changed pkg:github.com/zephyrproject-rtos/zephyr@v3.7.0 to pkg:github/zephyrproject-rtos/zephyr@v3.7.0

Then it finds it. Is this only a problem for my BlackDuck version or is this purl link faulty in general?

Problem 2:
The build.spdx file has the following entry:

Package: modules--hal-nordic--nrfx

PackageName: modules--hal-nordic--nrfx
SPDXID: SPDXRef-modules--hal-nordic--nrfx
PackageLicenseConcluded: NOASSERTION
PackageLicenseDeclared: NOASSERTION
PackageCopyrightText: NOASSERTION
PrimaryPackagePurpose: LIBRARY
PackageDownloadLocation: NOASSERTION
PackageLicenseInfoFromFiles: NOASSERTION
FilesAnalyzed: true
PackageVerificationCode: 3ed50c90623c0e5291d11820d82df6e4dfd1f7e2

If I change it to this, it the component gets found by BlackDuck:

Package: modules--hal-nordic--nrfx

PackageName: modules--hal-nordic--nrfx
SPDXID: SPDXRef-modules--hal-nordic--nrfx
PackageLicenseConcluded: NOASSERTION
PackageLicenseDeclared: NOASSERTION
PackageCopyrightText: NOASSERTION
PrimaryPackagePurpose: LIBRARY
PackageDownloadLocation: git+https://github.com/zephyrproject-rtos/hal_nordic@nrfx-3.0.0
PackageVersion: nrfx-3.0.0
ExternalRef: PACKAGE-MANAGER purl pkg:github/zephyrproject-rtos/hal_nordic@nrfx-3.0.0
PackageLicenseInfoFromFiles: NOASSERTION
FilesAnalyzed: true
PackageVerificationCode: 3ed50c90623c0e5291d11820d82df6e4dfd1f7e2

My conclusion:
The zephyr sdpx command helps generate files zephyr.spdx and build.spdx which (if I look into them) tell me which files are compiled in my project. This is fine so far. But shouldn't these files be in a format so that they can be read and components mapped by a tool like BlackDuck? Is this only a problem of mine or am trying something that is "not meant to be"?

Thanks,
Joanna

[pdgendt]

Could you provide more details on how Blackduck works? This appears to be a commercial tool? Maybe even create an SCA extension for it?

[mrodgers-witekio]

I'm not sure about blackduck specifically, but I think this section of the docs is relevant: https://docs.zephyrproject.org/latest/develop/modules.html#vulnerability-monitoring

Modules can specify a cpe and/or purl in the module.yml file:

security:
  external-references:
    - cpe:2.3:a:arm:mbed_tls:3.6.2:*:*:*:*:*:*:*
    - pkg:github/Mbed-TLS/mbedtls@V3.6.2

But it seems mbedtls is the only module that actually does this currently.

This issue is potentially relevant too: #53479, I've posted in there to see if there's any plan to extend this to other modules.

[greuljoSICKAG]

Yes, BladkDuck is a commercial tool. Sorry, I am not at all familiar with SCA extensions. Maybe with some time I can look into it and maybe provide something.

But I think I can make my questions more general. The problems I pointed are (I think) independent of BlackDuck.
The spdx is a standard and the entries should follow that. I see issues with:

1. purl link: How does a purl have to look like? purl pkg:github/... or purl pkg:github.com/... ?
2. The package entry for nordi-hal is missing the following entries that seems crucial to me in order to understand where the package is from (no matter if it is BlackDuck that is trying to read it or anyone/anything else):

PackageDownloadLocation: git+https://github.com/zephyrproject-rtos/hal_nordic@nrfx-3.0.0
PackageVersion: nrfx-3.0.0
ExternalRef: PACKAGE-MANAGER purl pkg:github/zephyrproject-rtos/hal_nordic@nrfx-3.0.0

[pdgendt]

@zephyrproject-rtos/security can maybe comment, should we track that modules update the relevant information in the zephyr/module.yml files?

[tgagneret-embedded]

BlackDuck indicates that the ExternalRef can't be found. So I looked into the purl link and changed pkg:github.com/zephyrproject-rtos/zephyr@v3.7.0 to pkg:github/zephyrproject-rtos/zephyr@v3.7.0

Then it finds it. Is this only a problem for my BlackDuck version or is this purl link faulty in general?

You are right. I can submit a PR to fix this if you want.

Problem 2: The build.spdx file has the following entry:

Package: modules--hal-nordic--nrfx

PackageName: modules--hal-nordic--nrfx
SPDXID: SPDXRef-modules--hal-nordic--nrfx
PackageLicenseConcluded: NOASSERTION
PackageLicenseDeclared: NOASSERTION
PackageCopyrightText: NOASSERTION
PrimaryPackagePurpose: LIBRARY
PackageDownloadLocation: NOASSERTION
PackageLicenseInfoFromFiles: NOASSERTION
FilesAnalyzed: true
PackageVerificationCode: 3ed50c90623c0e5291d11820d82df6e4dfd1f7e2

If I change it to this, it the component gets found by BlackDuck:

Package: modules--hal-nordic--nrfx

PackageName: modules--hal-nordic--nrfx
SPDXID: SPDXRef-modules--hal-nordic--nrfx
PackageLicenseConcluded: NOASSERTION
PackageLicenseDeclared: NOASSERTION
PackageCopyrightText: NOASSERTION
PrimaryPackagePurpose: LIBRARY
PackageDownloadLocation: git+https://github.com/zephyrproject-rtos/hal_nordic@nrfx-3.0.0
PackageVersion: nrfx-3.0.0
ExternalRef: PACKAGE-MANAGER purl pkg:github/zephyrproject-rtos/hal_nordic@nrfx-3.0.0
PackageLicenseInfoFromFiles: NOASSERTION
FilesAnalyzed: true
PackageVerificationCode: 3ed50c90623c0e5291d11820d82df6e4dfd1f7e2

This is my analysis of the situation:

I would recommand to use zephyr.spdx and modules-deps.spdx for Black Duck. build.spdx only tracks compiled files.

You can find the correct PackageDownloadLocation and PackageVersion in zephyr.spdx. However it will not use nrfx-3.0.0 as current version, because it's not the case. It's on a later commit (on Zephyr 3.7.0), so we use this commit as version.

For the PURL in ExternalRef, we do not add them in our SBOM. I need to take a look at this, but this is an improvement we could add to the zephyr.spdx (using commit as version if not on a tag).