SBOM for STM32 firmware project

[dgep]

Hi,

I have this toolchain and need to generate a SBOM:

• STM IDE v1.18
• STM IDE GNU Tools for STM32 13.3.Rel1
• STM32Cube FW_L4 V1.18.1, specified in `\*.ioc` file
• STM32_USB_Device_Library (v2.0_Cube)
• STM32CubeMX 6.14.0
• FreeRTOS (10.3.1)

How could I turn this into a SBOM?

I tried scanning the folder strucutre with syft but this did not work. 

I then tried to manually make a syft Json file, but when testing for vulnerabiliteies (like e.g. here ) i could not find them. I am not sure how to specify the above components, such that they get recognized by the automated search engine (Grype).

I found a statement from ST, that SBOMs will be provided for their products, but I could not find said lists for my toolchain. Some repositories on the GitHub Repositores contain `sbom_cdx.json`. However, I struggle to connect my Toolchain components to the repositories on Github (there are over 700 and for example "stm32cubeIDE" returns 0). 

Any help is appreciated!

 

Related Links:

• Wikipage on STM32 Security
• Thiha2025 having a similar Problem

 

 

 

[dgep]

Ok I "reverse-engineered" one of the sbom_cdx.json (example) with syft. When running

syft convert sbom_cdx.json -o converted.json

We receive a syft JSON with the data given by ST.  

Deleting from this until it breaks I found out (what is probably obvious for others), that the CPE identifier is the deciding component. CPE identifiers can be found with this search engine. 

Here is a minimal syft json example, which will return a vulnerability with grype: 

{
 "artifacts": [
{
 "name": "STM",
 "version": "1.17.0",
 "cpes": [
 {
 "cpe": "cpe:2.3:o:st:stm32cubel4_firmware:*:*:*:*:*:*:*:*",
 "source": "declared"
 }
 ]
}
],
 "artifactRelationships": [], 
 "files": [], 
 "source": {},
 "distro": {},
 "descriptor": {},
 "schema": {
 "version": "16.1.3",
 "url": "https://raw.githubusercontent.com/anchore/syft/main/schema/json/schema-16.1.3.json"
 }
}

 

[dgep]

Thanks for moving this to the correct forum. 

Does somebody here have experience with this?

[Dor_RH]

Hello @dgep,

For our firmware packages, we use Black Duck to generate the SBOM.

The ST Cube SBOM is meant as a reference to describe ST‑provided components: it does not replace your own project SBOM. You can copy the relevant details from ST’s SBOM (component name, version, license, origin) for the libraries you actually use, instead of creating that information from scratch.

For STM32CubeIDE and STM32CubeMX, you will find the Additional License Terms in the tool documentation on st.com.

I hope my answer has been helpful. When your question is resolved, please mark this topic as the solution. This will help others find the answer more quickly.

Thank you for your contribution.

Best regards,
Dor_RH

[Chen Embedded Software LLC]

I ran into the same problem: Syft finds nothing in a CubeIDE project because there's no package manager, and a hand-made SBOM only matches in Grype if the CPE is exactly right.

I wrote a small open-source tool for this: https://github.com/chen-embedded/fwsbom
It reads versions from the vendored sources (FreeRTOS task.h, Mbed TLS, lwIP, FatFs, the HAL driver's __STM32xx_HAL_VERSION defines, CMSIS, and others), uses CPEs checked against the NVD dictionary, and can use the .map file from your build to drop components the linker discarded:

pip install git+https://github.com/chen-embedded/fwsbom
python -m fwsbom . --map Debug/yourproject.map --linked-only -o sbom.cdx.json
grype sbom:sbom.cdx.json

On a test project with FreeRTOS 10.0.1, Mbed TLS 2.16.0, lwIP 2.1.2, FatFs R0.12 and cJSON 1.7.12, Grype reports 57 matches.
It also picks up the ST USB Device/Host library versions and reads the STM32Cube firmware package version (e.g. FW_L4 V1.18.1) straight from your .ioc file. Feedback welcome.