Vulnerabilities/CVE in Zephyr modules

[tgagneret-embedded]

Hi,

I'd like to check that my Zephyr product is not affected by any CVE. For this, I use the NVD database (using CPE "zephyrproject:zephyr") which mostly links to the "Security Advisories" on this github repository.

However I did not find information about the vulnerabilities in Zephyr modules. Indeed Zephyr is not using mainline modules, but instead use its own repository with some modification. The west.yml points to a commit in this repository. So it means that for every version of Zephyr, since theses modules are part of Zephyr, there should be some information about CVE in these modules I think.

If I take an example, like mbedTLS. The last version of mbedTLS merged in the zephyr mbedTLS module is "3.1.0" if I'm not mistaken ([https://github.com/zephyrproject-rtos/mbedtls]()) but there is a recent CVE on this version ([https://nvd.nist.gov/vuln/detail/CVE-2022-35409]()). How can I know if I'm affected by this one ? If so, is there any fixes that has been added ?

So I would like to know if there is any existing documentation/report about this ? If not, how can I solve this issue ? Should I "manually" check the last merged version (from mainline to zephyr module) and then check CVE for this component ?

Thanks

[stephanosio]

cc @ceolin

[ceolin]

That is a good point that we are bring to security working group. Right now, we don't a process to monitor and publish vulnerabilities on modules. Modules and HALs are "generally" updated before a release. I acknowledge that from the security perspective it is not ideal, so we are planning to use github dependabot to minimize this gap. I'm glad this topic was brought up since we are looking into it.

[tgagneret-embedded]

Hi,

Thanks for your answer.

Do you have any schedule or delivery date for this "feature" ?

Thanks

[ceolin]

We don't have a date yet, but I'll come out with a proposal this month. For now the best thing is filling an issue asking for update a module if you find a vulnerability in one of them.

[tgagneret-embedded]

On a close topic, I checked some of the Security advisories for Zephyr and it seems that the commit associated with the CVE (that fixes the vulnerabilities) is not always a dedicated commit/PR (it can include multiple modification not related to the CVE). I think it could be interesting if your policy forces to have a dedicated commit/PR when it fixes a CVE. That would allow to improve backport for people not using current version (or Long Term).

Would it make sense for you to adopt this policy ?

Thanks

[dkalowsk]

@tgagneret-embedded you may find it useful to attend the bi-weekly security working group meeting. Details can be found at https://lists.zephyrproject.org/

[beriberikix]

@kestewart FYI

[ceolin]

On a close topic, I checked some of the Security advisories for Zephyr and it seems that the commit associated with the CVE (that fixes the vulnerabilities) is not always a dedicated commit/PR (it can include multiple modification not related to the CVE). I think it could be interesting if your policy forces to have a dedicated commit/PR when it fixes a CVE. That would allow to improve backport for people not using current version (or Long Term).

Would it make sense for you to adopt this policy ?

We disclose the pr that fixes the vulnerability in the respective advisory, but yep, some times it fixes more than the original CVE. This can happen because the developer decided to change how something was implemented or because they found other related issues. That is something that we can review and have a more strict policy if it makes user's life easier.

[ceolin]

A heads up on this item. I've tried to automate it finding for vulnerabilities based on a generated SBOM. I've tested https://github.com/intel/cve-bin-tool, but there are other tools like https://github.com/google/osv-scanner too. The main problem is that our SBOM lacks information like package name and package version, so these tools are not able to identify which modules / libraries are being used and consequently find vulnerabilities on them.

One possibility is introduce more responsibilities for modules maintainers to check for it, but it will be hard to ensure it is properly being done. Our best shot IMHO is properly fix our SBOM generator and have some of these CVE finding tools integrated in CI.

[tgagneret-embedded]

Hi,

Thanks for the update.

I was at the security meeting yesterday, and if I'm not mistaken one of the solution would be to extend Zephyr module.yml with CPE.

For example:

build:
  cmake-ext: True
  kconfig-ext: True
  cpe: cpe:2.3:a:arm:mbed_tls:2.4.2:-:*:*:*:*:*:*

This would allow to detect CVE from mainstream repository. It would be easier to detect CVE for the maintainer of the module and fix them. However, we need to track the CVE we patched, else the scan will always returns the same CVEs, even the ones that are patched.

A solution for this, would be to have a VEX (which would indicate which CVE are presents and their status) in each Zephyr modules (if needed).

What do you think ?

Thanks

[tgagneret-embedded]

Hi,

Zephyr provides a SPDX SBOM however this SBOM does not allow to track CVE. This post proposes a solution to fix this.

Currently west spdx generates 3 spdx file:

• app.spdx
• build.spdx
• zephyr.spdx

I will only focus on zephyr.spdx for now.

Currently, Zephyr.spdx contains one package "zephyr-sources" and it contains all the files used to build zephyr library. To allow to track cve spdx file should be update:

• Create one package for each project/submodules in west.yml (package would contain cpe, url and version)
• Check for each .c file compiled in wich package it is contained and insert the file in the correct package

This is the current zephyr.spdx (truncated):

##### Package: zephyr-sources

PackageName: zephyr-sources
SPDXID: SPDXRef-zephyr-sources
PackageDownloadLocation: NOASSERTION
PackageLicenseConcluded: Apache-2.0 AND BSD-2-Clause AND BSD-3-Clause AND LicenseRef-Nordic-5-Clause AND LicenseRef-T2-
LC3 AND Nordic-5-Clause
PackageLicenseDeclared: NOASSERTION
PackageCopyrightText: NOASSERTION
PackageLicenseInfoFromFiles: Apache-2.0
PackageLicenseInfoFromFiles: BSD-2-Clause
PackageLicenseInfoFromFiles: BSD-3-Clause
PackageLicenseInfoFromFiles: LicenseRef-Nordic-5-Clause
PackageLicenseInfoFromFiles: LicenseRef-T2-LC3
PackageLicenseInfoFromFiles: Nordic-5-Clause
FilesAnalyzed: true
PackageVerificationCode: dfcc87d6d6a69b23d5e73101ba09f3bfffac9b7e

FileName: ./modules/lib/open-amp/open-amp/lib/virtio/virtio.c
SPDXID: SPDXRef-File-virtio.c
FileChecksum: SHA1: 912b847c1d3ad77478dd7aa06765a4f7d5cd2582
FileChecksum: SHA256: f86e11e5333d86ed23d2b602fd3ae8283d295760444362558faa0860ec21e62a
LicenseConcluded: BSD-2-Clause
LicenseInfoInFile: BSD-2-Clause
FileCopyrightText: NOASSERTION

[...]

FileName: ./zephyr/arch/arm/core/aarch32/cortex_m/fpu.c
SPDXID: SPDXRef-File-fpu.c
FileChecksum: SHA1: d0b6e9468d876cffece8f1daedda213b110e0897
FileChecksum: SHA256: 7106647bfd9ef657c88676d3dfba47eb0a68787d82a77553fc9221c61a72890f
LicenseConcluded: Apache-2.0
LicenseInfoInFile: Apache-2.0
FileCopyrightText: NOASSERTION

This would be the new zephyr.spdx (truncated):

##### Package: open-amp

PackageName: open-amp
SPDXID: SPDXRef-zephyr-open-amp
PackageDownloadLocation: NOASSERTION
PackageLicenseConcluded: BSD-2-Clause
PackageLicenseDeclared: NOASSERTION
PackageCopyrightText: NOASSERTION
PackageLicenseInfoFromFiles: Apache-2.0
PackageLicenseInfoFromFiles: BSD-2-Clause
PackageLicenseInfoFromFiles: BSD-3-Clause
PackageLicenseInfoFromFiles: GPL-2.0
FilesAnalyzed: true
PackageDownloadLocation: https://github.com/zephyrproject-rtos/open-amp
PackageVersion: a85bb3676d61d1ae202088e0d3fec556056b2c9e
PackageVerificationCode: dfcc87d6d6a69b23d5e73101ba09f3bfffac9b7e

FileName: ./modules/lib/open-amp/open-amp/lib/virtio/virtio.c
SPDXID: SPDXRef-File-virtio.c
FileChecksum: SHA1: 912b847c1d3ad77478dd7aa06765a4f7d5cd2582
FileChecksum: SHA256: f86e11e5333d86ed23d2b602fd3ae8283d295760444362558faa0860ec21e62a
LicenseConcluded: BSD-2-Clause
LicenseInfoInFile: BSD-2-Clause
FileCopyrightText: NOASSERTION

[...]

 ##### Package: zephyr

PackageName: zehpyr
SPDXID: SPDXRef-zephyr
PackageDownloadLocation: NOASSERTION
PackageLicenseConcluded: BSD-2-Clause
PackageLicenseDeclared: NOASSERTION
PackageCopyrightText: NOASSERTION
PackageLicenseInfoFromFiles: Apache-2.0
FilesAnalyzed: true
PackageVerificationCode: dfcc87d6d6a69b23d5e73101ba09f3bfffac9b7e
PackageVersion: f6628a30581d8d4b80954af163b83ce065e87467
PackageDownloadLocation: https://github.com/zephyrproject-rtos/zephyr
ExternalRef: SECURITY cpe23Type cpe:2.3:o:zephyrproject:zephyr:1.9.0:rc3:*:*:*:*:*:*

FileName: ./zephyr/arch/arm/core/aarch32/cortex_m/fpu.c
SPDXID: SPDXRef-File-fpu.c
FileChecksum: SHA1: d0b6e9468d876cffece8f1daedda213b110e0897
FileChecksum: SHA256: 7106647bfd9ef657c88676d3dfba47eb0a68787d82a77553fc9221c61a72890f
LicenseConcluded: Apache-2.0
LicenseInfoInFile: Apache-2.0
FileCopyrightText: NOASSERTION

[...]

Most of the data would be present in meta file which is a file generated by zephyr_module.py script. It contains local path to all projects/modules with current revision.

This would be the tasks to get there:

• [ ] Call zephyrmodule.py, with --meta-out_ option by default: This file allows to get the list of all package/submodules in west with revision. Check zephyr_module.cmake for details.
• [ ] Update SPDX script algorithm that generates SPDX to separate packages (present in meta file) and include the correct files in each package.
• [ ] Update specification for module.yml with my previous message proposing to add CPE fields to module.yml (it was only a draft and more reflexion should be done of course)
• [ ] Extract remote URL form west.yml and include it in meta file
• [ ] Extract CPE from module.yml and include it in meta file
• [ ] Extract all necessary information from meta file and include it in SPDX file

What do you think ?

[tgagneret-embedded]

An additional question, would it be interesting to open a CPE for all zephyr modules ?

There is the existing one cpe:2.3:o:zephyrproject:zephyr:-:*:*:*:*:*:*:* for the kernel but maybe it would make sense to add these for exemple:

• cpe:2.3:o:zephyrproject:mbedtls:-:*:*:*:*:*:*:*
• cpe:2.3:o:zephyrproject:trusted_firmware-m:-:*:*:*:*:*:*:*

Is it something that should be considered ?

Thanks

[tgagneret-embedded]

Hi,

Thanks for the update.

I was at the security meeting yesterday, and if I'm not mistaken one of the solution would be to extend Zephyr module.yml with CPE.

For example:

build:
  cmake-ext: True
  kconfig-ext: True
  cpe: cpe:2.3:a:arm:mbed_tls:2.4.2:-:*:*:*:*:*:*

This would allow to detect CVE from mainstream repository. It would be easier to detect CVE for the maintainer of the module and fix them. However, we need to track the CVE we patched, else the scan will always returns the same CVEs, even the ones that are patched.

A solution for this, would be to have a VEX (which would indicate which CVE are presents and their status) in each Zephyr modules (if needed).

What do you think ?

Thanks

This is an updated module.yml proposition:

diff --git a/scripts/zephyr_module.py b/scripts/zephyr_module.py
index 59679a6ea8..abbb8861ba 100755
--- a/scripts/zephyr_module.py
+++ b/scripts/zephyr_module.py
@@ -95,6 +95,17 @@ mapping:
     type: seq
     sequence:
       - type: str
+  vulnerabilities:
+    remote_cpe:
+      required: false
+      type: seq
+      sequence:
+        - type: str
+    vex:
+      required: false
+      type: seq
+      sequence:
+        - type: str
 '''

• remote_cpe would contains the cpe of the repository that has been forked (it's a list to allow to add cpe from dependencies if necessary)
• vex would contains path to VEX files used to filter the CVE treated. This is not meant to be integrated right now but shows some evolution for this. OpenVEX is an example of VEX specification we could use.

With this, I think we could have a better way to detect/automate and manage CVE in zephyr submodules.

[tgagneret-embedded]

Hi @ceolin,

Can I have some feedback ? Is it a good path to follow ?

Thanks

[ceolin]

An additional question, would it be interesting to open a CPE for all zephyr modules ?

There is the existing one cpe:2.3:o:zephyrproject:zephyr:-:*:*:*:*:*:*:* for the kernel but maybe it would make sense to add these for exemple:

• cpe:2.3:o:zephyrproject:mbedtls:-:*:*:*:*:*:*:*
• cpe:2.3:o:zephyrproject:trusted_firmware-m:-:*:*:*:*:*:*:*

Only for Zephyr imho, we are not assigning any cve to modules and consequently these CPEs don't exist. (At least for now)

Package: open-amp

PackageName: open-amp SPDXID: SPDXRef-zephyr-open-amp PackageDownloadLocation: NOASSERTION PackageLicenseConcluded: BSD-2-Clause PackageLicenseDeclared: NOASSERTION PackageCopyrightText: NOASSERTION PackageLicenseInfoFromFiles: Apache-2.0 PackageLicenseInfoFromFiles: BSD-2-Clause PackageLicenseInfoFromFiles: BSD-3-Clause PackageLicenseInfoFromFiles: GPL-2.0 FilesAnalyzed: true PackageDownloadLocation: https://github.com/zephyrproject-rtos/open-amp PackageVersion: a85bb3676d61d1ae202088e0d3fec556056b2c9e

The package version should be the version used by the project that we have forked. Most tools use PackageName + PackageVersion to query CVE databases AFAIK.

Regarding CPEs that is right for me, though the tool that I used to test seems to ignore it (https://github.com/intel/cve-bin-tool).

I wouldn't care with vex for now for the sake of simplicity.

I think that is good plan and is correct.

[tgagneret-embedded]

Only for Zephyr imho, we are not assigning any cve to modules and consequently these CPEs don't exist. (At least for now)

I know, and I think modules should have their own CPE on NVD database. If I'm correct modules are forked from mainline project but sometimes there is some additions to it (It could be a backported patch). So it's not the original one.

If one of these additions causes a CVE, Zephyr wouldn't be able to report it to someone using the SBOM to track CVE.

This can probably wait for Zephyr to correctly detect and report CVE from its modules, but in my opinion, this is how it should be done at the end.

The package version should be the version used by the project that we have forked.

Yes you are right, however west.yml provides commit ID and not version number. Moreover it seems that zephyr modules have rarely tags/version number. So, I'm not sure what's the solution here, especially if we add CPE for zephyr modules. Should we force tag instead of commit in west.yml ?

[ceolin]

Only for Zephyr imho, we are not assigning any cve to modules and consequently these CPEs don't exist. (At least for now)

I know, and I think modules should have their own CPE on NVD database. If I'm correct modules are forked from mainline project but sometimes there is some additions to it (It could be a backported patch). So it's not the original one.

If one of these additions causes a CVE, Zephyr wouldn't be able to report it to someone using the SBOM to track CVE.

Fair enough, it doesn't hurt :)

This can probably wait for Zephyr to correctly detect and report CVE from its modules, but in my opinion, this is how it should be done at the end.

The package version should be the version used by the project that we have forked.

Yes you are right, however west.yml provides commit ID and not version number. Moreover it seems that zephyr modules have rarely tags/version number. So, I'm not sure what's the solution here, especially if we add CPE for zephyr modules. Should we force tag instead of commit in west.yml ?

I'd let each module set its own. e.g:

build:
  cmake-ext: True
  kconfig-ext: True
  version: 2.4.2
  cpe: cpe:2.3:a:arm:mbed_tls:2.4.2:-:*:*:*:*:*:*

[tgagneret-embedded]

I think it could cause some issue to do that.

You would need to update this version each time you update west.yml in zephyr. If you don't you could have patch a vulnerability present in 2.4.1, but if you forgot to update the version to 2.4.2, and CPE would report a CVE. So if you need to update version each time you update west.yml, I think a tag is safer (and it's easier to enforce it).

On the other end, if you don't update CPE you would have a problem also.

Maybe it would be interesting to have some module maintainers give some ideas and give the feasibility of the solution ?

[ceolin]

I think it could cause some issue to do that.

You would need to update this version each time you update west.yml in zephyr. If you don't you could have patch a vulnerability present in 2.4.1, but if you forgot to update the version to 2.4.2, and CPE would report a CVE. So if you need to update version each time you update west.yml, I think a tag is safer (and it's easier to enforce it).

That is not related with west.yml, this is defined in each module in module.yml. Basically this will need to be update anytime the module is updated and should contains the version the module is using. I mean, if you are saying that because when the module is update we update west.yml than yes :)

On the other end, if you don't update CPE you would have a problem also.

Maybe it would be interesting to have some module maintainers give some ideas and give the feasibility of the solution ?

It is fine to ask ... but we need this info to implement it, so I would just have something working this way and document it as part of module maintenance. Having some sort of automated way to this will just over complicate the problem since not all modules are organized in the same way. I don't think it is a big cost to update the version in that file.

[tgagneret-embedded]

Ok thank you, this will help me create the related PR (first PR, adding modules in SBOM, is in review).

[tgagneret-embedded]

Basically this will need to be update anytime the module is updated and should contains the version the module is using.

There was a misunderstanding on this. For tracking the CVE from the forked/remote repository (for example mbedtls), I created the field external-references. This field should contain CPE/PURL and thus, the version of the remote repository (for exemple, cpe:2.3:a:arm:mbed_tls:2.4.2:-:*:*:*:*:*:*), so no need to use this version field to track vulnerabilities from the forked repository.

My goal here was to add versioning to zephyr modules themselves, but this version field is not a good solution. A tag is better solution. If version field is in module.yml you can't easily check if there was some commit between the commit that set version and the current commit (and mark it as "dirty"). By the way, the problem is probably the same on the CPE field.

The goal of versioning zephyr modules is to allow better vulnerabilities tracking. Each module should report vulnerabilities as a CVE (with CPE cpe:2.3:o:zephyrproject:<module name>:<module version>:*:*:*:*:*:*:*) and/or to the Security tabs (Github Advisiory Database). This version would be reported in the SBOM, and allows SBOM tools to track modules vulnerabilities.

So, I would like to have your feedback on these two points @ceolin :

• For modules versioning, I think we should start having tag.
• For the CPE, I'm not sure how we can solve this. Maybe cpe_vendor and cpe_product and CPE would be automatically generated from these fields and tag. However, it means that we have some "specification" to transform tag to version (that might not work with external modules not following this spec).

I hope I've been clear enough.

Thanks

[ceolin]

Basically this will need to be update anytime the module is updated and should contains the version the module is using.

There was a misunderstanding on this. For tracking the CVE from the forked/remote repository (for example mbedtls), I created the field external-references. This field should contain CPE/PURL and thus, the version of the remote repository (for exemple, cpe:2.3:a:arm:mbed_tls:2.4.2:-:*:*:*:*:*:*), so no need to use this version field to track vulnerabilities from the forked repository.

cpe is correct, the only reason I mentioned the version is because the tool I tested to check CVEs seemed to not work with CPE, while the combination of version and source (original module name / repository ...) works in all these tools. That is said, if we can ensure that we can get CVEs through CPE info that is a better approach indeed.

My goal here was to add versioning to zephyr modules themselves, but this version field is not a good solution. A tag is better solution. If version field is in module.yml you can't easily check if there was some commit between the commit that set version and the current commit (and mark it as "dirty"). By the way, the problem is probably the same on the CPE field.

There almost always be some commits on top of the original module we've forked. In my opinion we should just use the version from the forked project.

The goal of versioning zephyr modules is to allow better vulnerabilities tracking. Each module should report vulnerabilities as a CVE (with CPE cpe:2.3:o:zephyrproject:<module name>:<module version>:*:*:*:*:*:*:*) and/or to the Security tabs (Github Advisiory Database). This version would be reported in the SBOM, and allows SBOM tools to track modules vulnerabilities.

The problem is that, if I understood correctly, we will need to mirror all CVEs reported in the project we have forked + the ones caused by our changes on them right ? Otherwise if someone uses `cpe:2.3:o:zephyrproject:<module name>:<module version>:*:*:*:*:*:*:*)` to check if there is a vulnerability in this module they won't get CVEs from the original project ...

I understand that this is a complete solution but this will transfer the burden to check vulnerabilities in upstream projects back to us and I am afraid this will end up not being properly updated. And since in all these time we haven't really get any report about vulnerabilities in our changes (mix of small changes and not getting much attention) I think for us the best thing would be to use the CPE from the original project, this way we can easily check if a Zephyr's build is using a module that the upstream project contains vulnerabilities.

So, I would like to have your feedback on these two points @ceolin :

• For modules versioning, I think we should start having tag.

What exactly you propose in this tag ? My suggestion is to keep it simpler and ignore possible commit changes we add in these modules for now. The major problem is getting the vulnerabilities from the upstream project we have forked. Later we can revisit it.

• For the CPE, I'm not sure how we can solve this. Maybe cpe_vendor and cpe_product and CPE would be automatically generated from these fields and tag. However, it means that we have some "specification" to transform tag to version (that might not work with external modules not following this spec).

I hope I've been clear enough.

Absolutely !!! Thanks a lot for working on this

Thanks

[tgagneret-embedded]

Indeed, I wanted modules maintainers to track and fix CVE. So I think it's okay to give the responsability to developer using zephyr (and maybe change this later).

So for this:

• I would remove the versionand cpefield I talked about.
• SPDX would use commit id of the module as version (the goal of the zephyr.spdx is to track zephyr modules not the original source of the repositories).
• I would replace the remote_cpe by external-refs (or something like that) to support multiple format like CPE, PURL, ... This would allow to track vulnerabilities in remote/forked repository.
• I would create a new SBOM/SPDX file (modules.spdx for example) that would contains the modules and all associated external-refs.
• Any user that want to track vulnerabilities on modules (in fact, original repositories) would need to scan this SBOM for vulnerabilities (using cve-bin-tool for example)

I'm currently working on a PR for cve-bin-tool to support CPE field.

Does it looks good to you ?

[tgagneret-embedded]

@ceolin I was able to implement the behavior of my previous message. I'll submit the PR if you find the result satisfying.

With the following mbedtls module.yml:

build:
  cmake-ext: True
  kconfig-ext: True
vulnerabilities:
  external-references:
    - cpe:2.3:a:arm:mbed_tls:2.4.2:-:*:*:*:*:*:*
    - pkg:github.com/Mbed-TLS/mbedtls

and CMSIS module.yml:

build:
  cmake-ext: true
  kconfig-ext: true
vulnerabilities:
  external-references:
    - cpe:2.3:o:arm:cmsis-rtos:2.1.2:*:*:*:*:*:*:*
    - pkg:github.com/ARM-software/CMSIS_5@5.9.0

The content of zephyr.yml would look like this:

SPDXVersion: SPDX-2.2
DataLicense: CC0-1.0
SPDXID: SPDXRef-DOCUMENT
DocumentName: zephyr-sources
DocumentNamespace: http://spdx.org/spdxdocs/zephyr-c175a74f-dfb6-464d-b6de-18292aa77aba/zephyr
Creator: Tool: Zephyr SPDX builder
Created: 2024-01-29T12:43:38Z

Relationship: SPDXRef-DOCUMENT DESCRIBES SPDXRef-zephyr-sources
Relationship: SPDXRef-DOCUMENT DESCRIBES SPDXRef-example-application-sources
Relationship: SPDXRef-DOCUMENT DESCRIBES SPDXRef-cmsis-sources
Relationship: SPDXRef-DOCUMENT DESCRIBES SPDXRef-hal-nordic-sources
Relationship: SPDXRef-DOCUMENT DESCRIBES SPDXRef-stm32-sources
Relationship: SPDXRef-DOCUMENT DESCRIBES SPDXRef-mbedtls-sources

##### Package: zephyr-sources

PackageName: zephyr-sources
SPDXID: SPDXRef-zephyr-sources
PackageLicenseConcluded: Apache-2.0
PackageLicenseDeclared: NOASSERTION
PackageCopyrightText: NOASSERTION
PackageDownloadLocation: https://github.com/tgagneret-embedded/zephyr
PackageVersion: aefe1ae3057acf568ac5e5c05358928709a33274
PackageLicenseInfoFromFiles: Apache-2.0
FilesAnalyzed: true
PackageVerificationCode: 738e8f33d234882a0a68fd4a8af97a45b59e2e6a

[ Zephyr source files were removed ]

##### Package: example-application-sources

PackageName: example-application-sources
SPDXID: SPDXRef-example-application-sources
PackageLicenseConcluded: Apache-2.0
PackageLicenseDeclared: NOASSERTION
PackageCopyrightText: NOASSERTION
PackageDownloadLocation: https://github.com/zephyrproject-rtos/example-application
PackageVersion: 83356c31c2d7c3a3ca15aa62bfc8040ba9979b30-dirty
PackageLicenseInfoFromFiles: Apache-2.0
FilesAnalyzed: true
PackageVerificationCode: b99e0f3358880e352c95b830eae486963e8ebf69

FileName: ./drivers/sensor/examplesensor/examplesensor.c
SPDXID: SPDXRef-File-examplesensor.c
FileChecksum: SHA1: de1e82ca42e644e764194d02b0b00c7e2a327eb5
FileChecksum: SHA256: fb7dbba1c176481a3976ed6e89586c2f2afc5c34adb910b1e3b07dd86a1a5cc5
LicenseConcluded: Apache-2.0
LicenseInfoInFile: Apache-2.0
FileCopyrightText: NOASSERTION

##### Package: cmsis-sources

PackageName: cmsis-sources
SPDXID: SPDXRef-cmsis-sources
PackageLicenseConcluded: NOASSERTION
PackageLicenseDeclared: NOASSERTION
PackageCopyrightText: NOASSERTION
PackageDownloadLocation: https://github.com/zephyrproject-rtos/cmsis
PackageVersion: 4b96cbb174678dcd3ca86e11e1f24bc5f8726da0-dirty
FilesAnalyzed: false
PackageComment: Utility target; no files

##### Package: hal-nordic-sources

PackageName: hal-nordic-sources
SPDXID: SPDXRef-hal-nordic-sources
PackageLicenseConcluded: BSD-3-Clause
PackageLicenseDeclared: NOASSERTION
PackageCopyrightText: NOASSERTION
PackageDownloadLocation: https://github.com/zephyrproject-rtos/hal_nordic
PackageVersion: 64bd075a06f6a16d6ea9101cda82b41465a35211
PackageLicenseInfoFromFiles: BSD-3-Clause
FilesAnalyzed: true
PackageVerificationCode: 62afec6f1f8abe0783850523129e45655f824cf4

FileName: ./nrfx/drivers/src/nrfx_clock.c
SPDXID: SPDXRef-File-nrfx-clock.c
FileChecksum: SHA1: 2a034c9f752c5af3d924d013448ae048106a2d8c
FileChecksum: SHA256: 2a86f520c58c4959e8ddb657ac4c8770e1aba0316f10948f7b0ae6139128c0fb
LicenseConcluded: BSD-3-Clause
LicenseInfoInFile: BSD-3-Clause
FileCopyrightText: NOASSERTION

FileName: ./nrfx/drivers/src/nrfx_gpiote.c
SPDXID: SPDXRef-File-nrfx-gpiote.c
FileChecksum: SHA1: efb153729e4d2c1ed2b740c410010985497bcde7
FileChecksum: SHA256: f915a718a7da91fa2d93936255081ea460414989492365068a6b609f8f512833
LicenseConcluded: BSD-3-Clause
LicenseInfoInFile: BSD-3-Clause
FileCopyrightText: NOASSERTION

FileName: ./nrfx/helpers/nrfx_flag32_allocator.c
SPDXID: SPDXRef-File-nrfx-flag32-allocator.c
FileChecksum: SHA1: 8f6a3c17b0630d25309a08b0a14b97746a620efb
FileChecksum: SHA256: c5a5218e1bb253bb307f1e3b9df3b5d2ca8fb50068893aea40e690f844e84141
LicenseConcluded: BSD-3-Clause
LicenseInfoInFile: BSD-3-Clause
FileCopyrightText: NOASSERTION

FileName: ./nrfx/mdk/system_nrf52840.c
SPDXID: SPDXRef-File-system-nrf52840.c
FileChecksum: SHA1: 1712c372feb09c391c5a1437239c1df9d7c9dd61
FileChecksum: SHA256: 04f9af048d8c24607bcbd74a6062a57474ae851f823d39f8e6fcf4997d442362
LicenseConcluded: BSD-3-Clause
LicenseInfoInFile: BSD-3-Clause
FileCopyrightText: NOASSERTION

##### Package: stm32-sources

PackageName: stm32-sources
SPDXID: SPDXRef-stm32-sources
PackageLicenseConcluded: NOASSERTION
PackageLicenseDeclared: NOASSERTION
PackageCopyrightText: NOASSERTION
PackageDownloadLocation: https://github.com/zephyrproject-rtos/hal_stm32
PackageVersion: 22925907a6faeb601fc9a0d8cbb65c4b26d38043
FilesAnalyzed: false
PackageComment: Utility target; no files

##### Package: mbedtls-sources

PackageName: mbedtls-sources
SPDXID: SPDXRef-mbedtls-sources
PackageLicenseConcluded: NOASSERTION
PackageLicenseDeclared: NOASSERTION
PackageCopyrightText: NOASSERTION
PackageDownloadLocation: https://github.com/zephyrproject-rtos/mbedtls
PackageVersion: 66ed2279d6222056af172c188eaf4dcfed481032-dirty
FilesAnalyzed: false
PackageComment: Utility target; no files

and the content of modules-deps.spdx would look like this:

SPDXVersion: SPDX-2.2
DataLicense: CC0-1.0
SPDXID: SPDXRef-DOCUMENT
DocumentName: modules-deps
DocumentNamespace: http://spdx.org/spdxdocs/zephyr-c175a74f-dfb6-464d-b6de-18292aa77aba/modules-deps
Creator: Tool: Zephyr SPDX builder
Created: 2024-01-29T12:43:38Z

Relationship: SPDXRef-DOCUMENT DESCRIBES SPDXRef-example-application-deps
Relationship: SPDXRef-DOCUMENT DESCRIBES SPDXRef-cmsis-deps
Relationship: SPDXRef-DOCUMENT DESCRIBES SPDXRef-hal-nordic-deps
Relationship: SPDXRef-DOCUMENT DESCRIBES SPDXRef-stm32-deps
Relationship: SPDXRef-DOCUMENT DESCRIBES SPDXRef-mbedtls-deps

##### Package: example-application-deps

PackageName: example-application-deps
SPDXID: SPDXRef-example-application-deps
PackageLicenseConcluded: NOASSERTION
PackageLicenseDeclared: NOASSERTION
PackageCopyrightText: NOASSERTION
PackageDownloadLocation: NOASSERTION
FilesAnalyzed: false
PackageComment: Utility target; no files

##### Package: cmsis-deps

PackageName: cmsis-deps
SPDXID: SPDXRef-cmsis-deps
PackageLicenseConcluded: NOASSERTION
PackageLicenseDeclared: NOASSERTION
PackageCopyrightText: NOASSERTION
PackageDownloadLocation: NOASSERTION
ExternalRef: SECURITY cpe23Type cpe:2.3:o:arm:cmsis-rtos:2.1.2:*:*:*:*:*:*:*
ExternalRef: PACKAGE_MANAGER purl pkg:github.com/ARM-software/CMSIS_5@5.9.0
FilesAnalyzed: false
PackageComment: Utility target; no files

##### Package: hal-nordic-deps

PackageName: hal-nordic-deps
SPDXID: SPDXRef-hal-nordic-deps
PackageLicenseConcluded: NOASSERTION
PackageLicenseDeclared: NOASSERTION
PackageCopyrightText: NOASSERTION
PackageDownloadLocation: NOASSERTION
FilesAnalyzed: false
PackageComment: Utility target; no files

##### Package: stm32-deps

PackageName: stm32-deps
SPDXID: SPDXRef-stm32-deps
PackageLicenseConcluded: NOASSERTION
PackageLicenseDeclared: NOASSERTION
PackageCopyrightText: NOASSERTION
PackageDownloadLocation: NOASSERTION
FilesAnalyzed: false
PackageComment: Utility target; no files

##### Package: mbedtls-deps

PackageName: mbedtls-deps
SPDXID: SPDXRef-mbedtls-deps
PackageLicenseConcluded: NOASSERTION
PackageLicenseDeclared: NOASSERTION
PackageCopyrightText: NOASSERTION
PackageDownloadLocation: NOASSERTION
ExternalRef: SECURITY cpe23Type cpe:2.3:a:arm:mbed_tls:2.4.2:-:*:*:*:*:*:*
ExternalRef: PACKAGE_MANAGER purl pkg:github.com/Mbed-TLS/mbedtls
FilesAnalyzed: false
PackageComment: Utility target; no files

[ceolin]

The contents look reasonable to me. What I am not sure is the output format. Have you tested it against some tool that searches for CVEs in SBOM ?

This is gold btw, thanks for working on it :)

[tgagneret-embedded]

I submited modules-deps.spdx to cve-bin-tool:

• PURL are correctly detected (to be detected, version must be provided in the PURL).
• CPE are detected but it's due to my local changes, PR is not merged yet.

So it looks good to me. Do you think of something in particular that could not work ?

[tgagneret-embedded]

I also run it against pyspdxtools and it validates it. Moreover SPDX specification allows a list of externalRef.