1. How to read this document?
This document is limited to STM32 deliverables and focuses on embedded software. It aims to explain the security policies put in place around embedded software delivered under their own licenses. It does not replace the license terms & conditions of each component/package.
Explanations and policies are subject to change.
Legacy software support may be done on a case-by-case basis only.
These policies are being set forth on new packages/components only.
2. Why a secure development process?
The EU’s Cyber Resilience Act (CRA) and Radio Equipment Directive (RED) and other regulations are putting a strong emphasis on security affecting the way developers select component and manage them across the entire device lifecycle.
ST cares about security. From product development lifecycle up to deliverables provided to our developers to build their software with security by design as a target.
3. What STM32 offers to help your secure development process?
To help developers put in place their secure development process, STM32 is extending its own secure development with:
· Global secure development process across all STM32 embedded software teams
· Public set of security policies
· In some case a security assurance level
· Transparency & Active vulnerabilities management
· State-of-the-art ST internal tools and reporting methodologies
This shall simplify the developer’s way to regulation’s compliance.
4. Global secure development process across all STM32 embedded software teams
The purpose of this process is to make sure that security is part of the software development process for every new STM32 embedded software and within every development team.
The process starts with the definition of software development and includes:
- The classification of the intended software component/package: According to the security impact of the component/package to be developed a selection of security level is done to be able to apply specific security policies.
- An early Software Composition Analysis (SCA): to scan all components used to create the package and verify their conformance to License, Copyrights and security policies requirements. Security policies are applied within the SCA by setting automated configurations within the toolset used to manage the SCA process.
- During the coding phase, developers are provided with security design & coding guidelines and will apply best the defined security coding rules.
o ST is using is long experience in software development and security expertise and has defined his own security coding guideline documents.
o At various stages of the development Static Application Security Testing (SAST) may be applied, in accordance with the security policies set by the software component/package security level.
- During the software test, in addition to the validation, additional SCA & SAST may be done. According to policies Dynamic Application Security Testing (DAST) may be run.
- At the time of delivering the software a final run of SCA is done providing a public report in the form of a machine-readable Software Bill of Material (SBOM). The human readable list of components being also available next to the SBOM within the component/package. From the machine readable SBOM, developers will have the capability to scan for vulnerabilities on their components/packages and decide for security mitigations via component updates or other means. STM32 is also preparing the availability of Vulnerability EXposure (VEX) in the form of a CSAF compliant document. This VEX will inform developers about the current vulnerabilities of components/packages. This shall be available in the coming months.
- During component/package lifecycle, SCA will continue with vulnerability scans and security updates, or patch, will be developed according to its security policies.
Below pictures explain the way a Development & Operation process (DevOps) can move to a Development Security & Operation process (DevSecOps).
5. Software Bill of Material (SBOM)
SBOM management is strongly automated and delivered synchronized with the package delivery. CycloneDX is a modern ECMA standard (ECMA-424) for the software supply chain. The specification originates and is led by the OWASP Foundation and supported by the global information security community.
Features about SBOM delivered by ST:
- One SBOM file per package
- Machine-readable CycloneDX format
- For converting the CycloneDX SBOM into other format, developers shall refer to public commercial or open source
- Additional human-readable available inside the component/package license document
- Enables automatic security scan policies
- Includes Open Sources & external 3rd party deliverables
- In the case of package, every component is tracked
The SBOM is available today on a few early packages like STM32CubeN6, U3, F4, but will be generalized to all packages intended for maintenance.
SBOM file (“sbom_cdx.json” ) can be found within the github main project directory.
6. Software Security Classification
To better focus on the security need, a level of security has been defined within ST security policies. On STM32 we could distinguish 4 levels:
- Non applicable:
- A set of packages, with no security function nor security assets, provided as a development example and not planned for final production purposes.
- Old packages, obsolete and with no further maintenance planned
- Examples could include HomeKit, STVS, etc …
- Low:
- Software that do not manage security functions nor security assets
- Examples could include STM32CubeC0, LibJPEG, LPBAM, etc.
- Medium
- Software managing security functions or security assets, but without security robustness claims
- Examples could include STCryptoLib, MATTER, FreeRTOS, etc.
- High
- Software managing security functions or security assets, with security robustness claims
- Examples could include Secure Manager, STxRoT, RSSe extensions, etc.
Classification applies to each package, or each component, delivered standalone. A package class Low can include packages with higher class if they are independently delivered in standalone packages and classified accordingly.
The classification will be public and available within the package documentation.
| SW Security
Level |
Description | Examples |
| Not applicable | Legacy packages, or non-commercial packages | HomeKit, STVS … |
| Low | Software that do not manage security assets | STM32CubeC0, LibJPEG, LPBAM … |
| Medium | Software handling security assets or processes without security robustness claim | STCryptoLib, MATTER, FreeRTOS, … |
| High | Software handling security assets or processes with security robustness claim | Secure Manager, STxRoT, RSSe extensions, … |
7. Security Policies
The purpose of the security policies is to adapt the security measures according the defined package/component security classification.
This may impact SCA, secure coding, SAST and DAST as well as penetration testing activities on each package/component/
Indeed, depending on the software classification the security measures/focus to put may vary, based on the risk model.
The policies can be summarized using the table below:
| SW Security
Level |
SCA | Secure Coding | SAST | DAST | Penetration testing |
| Not applicable | No | None | None | None | None |
| Low | Yes | Basic | On selected components | Basic | On selected components |
| Medium | Yes | Medium | Limited | Medium | On selected components |
| High | Yes | High | High | High | Yes |
8. Software Composition Analysis (SCA)
Except for the non-applicable level, every package/component will go through SCA and provide SBOM.
Delivery policy of the SBOM is aligned with package/component delivery policy.
9. Secure Coding
Focus on security coding is differing according to the secure policy. STM32 software developers will be trained on secure coding, but application, validation and waiver processes may vary depending on the classifications.
Coding rules are based on:
- Secure coding guidelines
- Code reviews
- Readability & maintainability reviews
10. Static Application Security Testing (SAST)
SAST methodologies using state-of-the-art tools will be available to all STM32 developers based on:
• MISRA C
• CERT® C
• Specific SAST tools
According to the classification, the depth of analysis as well as the reviews and waiver managements may vary.
To be noted that SAST can be done thoroughly to any component, at the developer’s decision, only on certain components, based on a risk analysis/ For example HAL drives are always following a static analysis for quality and for security on certain sensitive HAL.
11. Dynamic Application Security Testing (DAST)
Dynamic analysis has the capability to find further problems that a static analysis could not. However, its applicability cannot be done on a large scale. It is the ownership of the STM32 developer to decide which specific part of the software presents higher risks and put in place the proper tests.
12. Penetration testing
Similarly to DAST penetration testing may be done on selected components, based on risk analysis, with a focus on Higher security classifications.
DAST & penetration testing include techniques & tools such as:
- Side channel attacks
- Fuzzing tests
- LDRA
13. Public vulnerability monitoring
Monitoring public vulnerabilities is essential at the various stages of the software lifecycle; during development it will help developers use the right component versions or put in place mitigations during the development itself. At publication it will inform about the status minimizing the risk. During the maintenance phase it will help developers decide for updates & mitigations via patch or other measures.
Table below defines the rules in place for vulnerability monitoring:
| SW Security
Level |
Monitoring Scan | Additionally
Version scans |
Further monitoring rules |
| Not applicable | None | None | None |
| Low | For each new release | 1x previous version | 6-month |
| Medium | For each new release | 2x previous version | Monthly |
| High | For each new release | 2x previous version | Daily |
14. Security updates
The willingness of the STM32 team is to minimize the risks and exposures of our developers. Therefore, a focus on mitigating the risks of vulnerability will be done, based on the security classifications, the risks levels (severity) and the security assurance in place. Please note that fix may happen on next release +1, if timing is insufficient (for example if a recent vulnerability is identified too close to the planned release date).
The following table tentatively lists the policies for security updates:
| SW Security
Level |
Vulnerability Severity | Correction
If no certification |
Correction
If certification & SFR impact | |
| Not applicable | Any | No commitment | ||
| Low | Any | Commercially reasonable effort for next releases – if planned | ||
| Medium | Low | Commercially reasonable effort for next releases – if planned | ||
| Medium | ||||
| High | Fix or full workaround
Best effort for next releases – patch possible | |||
| Critical | ||||
| High | Low | Commercially reasonable effort for next releases – if planned | Fix or full workaround
Best effort for next releases – patch possible | |
| Medium | ||||
| High | Fix or full workaround
Mandatory for next releases – patch possible | |||
| Critical | ||||
This table is subject to change or its application may vary depending of vulnerability and mitigation solution.
Note: Security Functional Requirement (SFR) as per Security Evaluation Standard for IoT Platforms (SESIP) / EN 17927 standard
15. IMPORTANT SECURITY NOTICE
The STMicroelectronics group of companies (ST) places a high value on product security, which is why the ST product(s) identified in this documentation may be certified by various security certification bodies and/or may implement our own security measures as set forth herein. However, no level of security certification and/or built-in security measures can guarantee that ST products are resistant to all forms of attacks. As such, it is the responsibility of each of ST's customers to determine if the level of security provided in an ST product meets the customer needs both in relation to the ST product alone, as well as when combined with other components and/or software for the customer end product or application. In particular, take note that: • ST products may have been certified by one or more security certification bodies, such as Platform Security Architecture (www.psacertified.org) and/or Security Evaluation standard for IoT Platforms (www.trustcb.com). For details concerning whether the ST product(s) referenced herein have received security certification along with the level and current status of such certification, either visit the relevant certification standards website or go to the relevant product page on www.st.com for the most up to date information. As the status and/or level of security certification for an ST product can change from time to time, customers should re-check security certification status/level as needed. If an ST product is not shown to be certified under a particular security standard, customers should not assume it is certified. • Certification bodies have the right to evaluate, grant and revoke security certification in relation to ST products. These certification bodies are therefore independently responsible for granting or revoking security certification for an ST product, and ST does not take any responsibility for mistakes, evaluations, assessments, testing, or other activity carried out by the certification body with respect to any ST product. • Industry-based cryptographic algorithms (such as AES, DES, or MD5) and other open standard technologies which may be used in conjunction with an ST product are based on standards which were not developed by ST. ST does not take responsibility for any flaws in such cryptographic algorithms or open technologies or for any methods which have been or may be developed to bypass, decrypt or crack such algorithms or technologies. • While robust security testing may be done, no level of certification can absolutely guarantee protections against all attacks, including, for example, against advanced attacks which have not been tested for, against new or unidentified forms of attack, or against any form of attack when using an ST product outside of its specification or intended use, or in conjunction with other components or software which are used by customer to create their end product or application. ST is not responsible for resistance against such attacks. As such, regardless of the incorporated security features and/or any information or support that may be provided by ST, each customer is solely responsible for determining if the level of attacks tested for meets their needs, both in relation to the ST product alone and when incorporated into a customer end product or application. • All security features of ST products (inclusive of any hardware, software, documentation, and the like), including but not limited to any enhanced security features added by ST, are provided on an "AS IS" BASIS. AS SUCH, TO THE EXTENT PERMITTED BY APPLICABLE LAW, ST DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, unless the applicable written and signed contract terms specifically provide otherwise.
16. IMPORTANT NOTICE – READ CAREFULLY
STMicroelectronics NV and its subsidiaries (“ST”) reserve the right to make changes, corrections, enhancements, modifications, and improvements to ST products and/or to this document at any time without notice. Purchasers should obtain the latest relevant information on ST products before placing orders. ST products are sold pursuant to ST’s terms and conditions of sale in place at the time of order acknowledgment.
Purchasers are solely responsible for the choice, selection, and use of ST products and ST assumes no liability for application assistance or the design of purchasers’ products.
No license, express or implied, to any intellectual property right is granted by ST herein.
Resale of ST products with provisions different from the information set forth herein shall void any warranty granted by ST for such product.
ST and the ST logo are trademarks of ST. For additional information about ST trademarks, refer to www.st.com/trademarks. All other product or service names are the property of their respective owners.
Information in this document supersedes and replaces information previously supplied in any prior versions of this document.
© 2025 STMicroelectronics – All rights reserved
17. References and useful links
- STM32Trust security framework
- STM32 Security wiki
- Product Security Response Team - PSIRT