Does ST provide a software bill of materials (SBOM) for code generated by STM32CubeMX ?

[JPetr.1]

I'm using STM32F2xx, STM32F4xx, STM32F7xx and STM32L0xx firmware supplied by STM32CubeMX. I need to generate an SBOM for cybersecurity purposes. Can ST provide that or provide documentaiton that can be referenced to generate the SBOM?

[Bob S]

Do you need the executable files or the source files?

Either way, the files "generated" by CubeMX depend on your configuration, so there can't be a generic list of files provided. Source files depend on which peripherals and middleware you have enabled. The executables and related compiler/linker output depend on the name of your project and your linker/post link commands (i.e. do you generate a hex file? listing? disassembly? map?,etc.).

How about just look at the directory tree generated by CubeMX and import that as your s/w BOM. Or the contents of the "Release" directory?

[JPetr.1]

I’m not looking for a list of files. The SBOM is a very specific list of software components that includes the manufacturer, component name, version, and a list of sub-components. For instance, the STM32F4xx firmware package would be a component. Azure RTOS would be a sub component of that. ThreadX and fileX would be sub-components of that. The manufacturer assigns names and version numbers to each component and sub-component. Google SBOM and see what I mean.

[Tesla DeLorean]

Yeah, I don't see ST generating that in a complete and reliable manner, surely it's something you could grep-n-strings, or mine the objects and libraries, more comprehensively and reliably, and generate an actual report/analysis. I'm not sure how this can be pushed off, and have any credibility. It's the sort of thing that'll be handed off to an intern. I can't even get them to do basic SW QA, and I've been trying for 12+ years.

Lot of old and broken Middleware in there for sure. FATFS 0.12c 2017 ?

There was a list of subcomponents used is STM32 Cube Programmer, not sure how well licenced any of that stuff is, and I for sure haven't seen any source. I think it was in the release notes.

I once gave a cybersecurity "expert" who wanted to review one of our devices firmware the .HEX file, apparently didn't have a script for that.

Not saying is not a good first step, I just think it'll be a lot more eye opening to DIY

[malcolm23]

SBOMs are becoming critically important across many industries. By Sept 14th 2023 all vendors (the entire supply chain from the application down through all libraries) must produce SBOMs for any software considered critical infrastructure by the US government (defense, utility, medical, etc.)

I make use of numerous STM32 processors and the STM32CubeMX libraries; but if I can't get official SBOMs provided by ST; I'm either going to have to switch to vendors that do or reimplement the drivers by hand.

SBOMs are used to secure a supply chain. The producer of a software item must be the person who creates the SBOM, and the consumer can then use it (verifying they have received and are using a valid version). If a consumer creates the SBOM then the chain of custody (and security) is broken as the consumer may have been the victim of a supply chain attack.

 

See: https://www.whitehouse.gov/wp-content/uploads/2022/09/M-22-18.pdf, https://www.ntia.doc.gov/files/ntia/publications/sbom_minimum_elements_report.pdf, https://csrc.nist.gov/csrc/media/Presentations/2023/fda-s-medical-device-program-and-sbom/images-media/JWilkerson-ssca-forum-053123.pdf

[Pavel A.]

>  By Sept 14th 2023 all vendors (the entire supply chain from the application down through all libraries) must produce SBOMs for any software considered critical infrastructure by the US government (defense, utility, medical, etc.)

ST libraries and cube-generated code are not a critical infrastructure, for any reasonable purpose. Also, most STM32s are not intended for 'critical' usages. Let them do their job and don't push your chores to them?

 

[SL_Matt]

Pavel, you don't seem to understand the bureaucracy we are forced to deal with here.

Anything that the government decides is critical (say a data center) is made up of both critical and noncritical components but the buyers have a mandate that everything has an SBOM. The thermostats in that data center probably run on STM32 processors. Power monitoring, lighting control, and many other components will have low cost ARM processors packed with 3rd party software. 

We aren't launching satellites. These tasks are not really critical components at all, but they can allow additional attack vectors on critical components. Uncle Sam just wants to know (nay, DEMANDS to know) what software components we use so that known vulnerabilities can be managed, tracked, and mitigated. 

@JPetr.1 For any 3rd party licensed software (including open source) that they will provide there will copies of the license agreement with the software. You have to determine what you are using based either on CubeMX selections or files compiled. Assume anything in the Middleware section is 3rd party.

[MKori.1]

@JPetr.1, this is a very good question, and I would also be interested in getting SBOMs from ST for their software. Nevertheless, I'm not sure if this will happen soon. ST doesn't sell the middleware but the hardware and provide the software for free as open source. Therefore, I don't see them as supplier regarding the software (disclaimer: opinion, I'm not a lawyer) and think we have to solve this on our own like we will have to if we use some other open-source software.

Have you tried using SBOM generation tools like Syft (https://github.com/anchore/syft) on the complete folder? This should, in theory, detect all included components if the source is available.

 

[MC.5]

Hi there,

as of march 2025 there are news, ST is going to provide a solution:

https://community.st.com/t5/developer-news/stm32cube-software-is-ready-for-automated-sbom-amp-security/ba-p/777224 

[Pavel A.]

OK so now we have a nice bot-generated manifest of components in the "cube" package. The file for STM32CubeU3

In that, we can find the IDs assigned to the CMSIS, BSPs for Nucleos, original and modified ThreadX libraries.... so much. Some 3rd party commercial libraries there are "evaluation version".

Will this stuff go into a real product firmware? Else, how much this BOM is going to help? Any patch or change or your own will invalidate the manifest reference.

The only genuine component there maybe are the ST device CMSIS files.

[debugging]

https://wiki.st.com/stm32mcu/wiki/Security:Deep_dive_on_CRA

For products placed on the market (1st sales) and made available on the market (after the CRA effective date),  -  really confusing terms - those products need to complay with CRA. the would mean if you have already released project that won't change but is still sold (imports), the SBOM is needed., But there is no SBOM xml data for these products  now (i.e F4). Even the products is not Class I, II or III,  still a self assessment is required.

How to generate this SBOM from existing projects ?