[HAS 63] 5.2.3 The first essential requirement (ESR1) of the CRA (Part I (1))...

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.

#### 5.2.3.2 MI-SSCA: Static source code analysis for memory errors

All cybersecurity-relevant parts of the product shall be checked for memory errors using a source code analysis tool that detects code that may produce common memory errors, such as:

All cybersecurity-relevant parts of the product shall be checked for known code patterns that produce common memory errors, such as:

* buffer overflow

* out-of-bounds

* use of uninitialized variables

* dereference of invalid pointer

The sufficiency of the source code analysis tool and the selected manner of running it shall be documented.

All warnings, annotations, or other method of suppressing warnings from the analysis tool shall be documented with a rationale for why it does not constitute an unacceptable risk.

Any identified memory errors or suppression of warnings shall be documented with a rationale for why it does not constitute an unacceptable risk.

* Reference: TR-SSDD

* Objective: Prevent unauthorized memory access

* Preparation: None

* Activities: Review the documentation on why the source code analysis tool is sufficient, how it is run, the source code for the product, the output of the source code analysis tool, and the documentation for any warnings or suppression of warnings

* Verdict: Sufficient documentation is acceptable, the method of running the tool is consistent with rationale, the output of source code analysis tool is consistent with the source code, all warnings or suppression of warnings have convincing documentation for why they are an acceptable risk => PASS, otherwise FAIL

* Evidence: The documentation on why the source code analysis tool is sufficient, how it is run, the source code for the product, the output of the source code analysis tool, and the documentation for any warnings or suppression of warnings

* Preparation: Determine the appropriate static source code analysis tool and the manner of running it to verify the absence of the listed errors

* Activities: Review the source code for the product by running the selected source code analysis tool. Review the documentation for any warnings or suppression of warnings.

* Verdict: The output of the source code analysis tool confirms the absence of the listed memory errors, or all warnings and suppressions have convincing documentation for why they are an acceptable risk => PASS, otherwise FAIL

* Evidence: The source code for the product, the output of the source code analysis tool, and the documentation for any warnings or suppression of warnings.

#### 5.2.3.3 MI-FZ95: Runtime code coverage checking with memory access error detection

#### 5.2.3.6 MI-SCFS: Secure compilation flags

All cybersecurity-relevant software shall be compiled with secure compilation flags and options appropriate to the target platform and language. All compilation flags used shall be documented as to their rationale, along with any exceptions or limitations. Any exceptions to the flags or warnings shall be documented as to why they do not create an unacceptable risk.

All cybersecurity-relevant software shall incorporate built-in exploit mitigation mechanisms appropriate to the target platform and language (e.g., Address Space Layout Randomization (ASLR), Data Execution Prevention (DEP/NX), or Stack Canaries). Any exceptions to these mitigations shall be documented as to why they do not create an unacceptable risk.

* Applicability: Product implemented in a compiled language

* Reference: TR-SSDD

* Objective: Secure software design and development

* Preparation: Document which flags should be used

* Activities: Review compilation flags, warnings, and documentation for exceptions

* Verdict: Documentation of flags exists, all warnings and exceptions are documented

* Evidence: Documentation of flags, build system files, documentation of warnings and exceptions

* Preparation: Document the exploit mitigations technically relevant to the architecture of the target platform.

* Activities: Inspect the compiled executable binaries to verify the presence of the required exploit mitigations, and review documentation for exceptions

* Verdict: Binaries actively implement the appropriate exploit mitigations, and all exceptions are documented and justified => PASS, otherwise FAIL

* Evidence: Output of binary analysis tools demonstrating the presence of exploit mitigations, and documentation of exceptions

### 5.2.4 TR-SCUD: Secure updates