@@ -105,6 +105,9 @@ Software shall be designed and developed in a secure manner.
**Guidance:** In alignment with the Cyber Resilience Act Annex I Part I (1), this section addresses overarching risks and mitigations regarding the secure design and development of the product that are not specifically treated by other categorical essential requirements (such as confidentiality, access control, or secure updates). The requirements herein ensure the final product itself embodies security by design.
> [!NOTE]
> Security profiles (as described in Annex B) determine which of these controls can be utilised to mitigate the threat. In particular, across all security profiles only one—at most—of the following three is called for when applied to a single product: FZ95, BTIN, IMSL. See B.TK for more information.
#### 5.2.3.2 MI-SSCA: Static source code analysis for memory errors
All cybersecurity-relevant parts of the product shall be checked for known code patterns that produce common memory errors, such as:
@@ -141,7 +144,7 @@ The product shall be checked for memory errors by running a tool that exercises
The product shall be implemented in a memory-safe language. Any use of unsafe memory features shall be documented to explain why they are necessary and do not present a cybersecurity risk.
* Reference: TR-SSDD
* Objective: Prevent unauthorized memory access
* Objective: Prevent unauthorised memory access
* Preparation: None
* Activities: Review source code to determine its language and what exceptions to memory safety exist
* Verdict: Source code is in a memory-safe language and the documentation of all uses of unsafe memory features convincingly demonstrates that each one of them does not present a cybersecurity risk => PASS, otherwise FAIL
