Does ST provide a software bill of materials (SBOM) for the code generated and included when STM32CubeMX is used for configuration?

[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.

[malcolm23]

Hi Pavel,

According to the Federal Government and the NTIA infrastructure they've put in place, SBOMs are a supply-chain responsibility for every party involved. There seem to be three approaches:

1. ST could indeed decide its chips are indeed not for use in "critical infrastructure" (as defined by the Federal Government 2022 Omnibus Bill), at which time they would not be usable in any medical device, hospital, power distribution, phone network, or any components intended for use directly or indirectly in any of these industries; but I don't think that would be a wise business decision.

2. ST could decide not to publish SBOMs, at which time random users would be forced to assign/allocating NTIA software IDs on behalf of ST - that would be akin to those random users releasing/assigning ST software IDs and version numbers to the NTIA / Federal Government - I don't think ST wants to have random users hand out ST version identifiers to the federal government in conflicting/inconsistent formats.

3. ST could update its release process to leverage any of a number of open-source tools capable of publishing SBOMs during the build process. At which time ST software would become significantly more attractive to companies whose products are directly or indirectly used in "critical infrastructure".

In conclusion; anyone doing business directly or indirectly with the US federal government has just had their hands tied - we need SBOMs from our vendors in order to continue to make products. We don't have a choice - as of last month (October 2023) the FDA started instantly denying all FDA medical device submissions that don't include accurate and complete SBOMs covering the entire software supply chain. We are unable to release new medical devices unless *EVERYONE* up the supply chain that publishes software also includes SBOMs.

If ST is going to continue with the "Not our problem" stance then we need to know as soon as possible and switch to vendors that follow the Federal Government guidelines - such as NXP who have material and even host training seminars on SBOMs and mitigating security risks.