@@ -102,7 +102,7 @@ In addition to memory safety, compiled software is a potential target based on p
#### 5.2.3.1 Requirement
1.**REQ-SSD-03 (MI-FZ95)-1** The product shall be checked for memory errors by running a tool that exercises the functions of the product in an environment that permits measuring code coverage and detecting memory access errors, and
1.**REQ-SSD-03 (MI-FZ95)-1** The product shall prevent or mitigate _common memory errors_, and
2.**REQ-SSD-03 (MI-FZ95)-2** the product technical documentation shall record all memory errors detected with a rationale for how each error does not constitute an unacceptable risk.
This requirement can be satisfied by using one of several methods identified by unique numbers. After selecting one method, carry out the corresponding numbered step within each section of this assessment. Only one method is necessary to complete the assessment.
#### 6.2.3.1 Objective
Prevent unauthorized memory access.
#### 6.2.3.2 Preparation
None
None.
#### 6.2.3.3 Activities
Run the tool while measuring code coverage and monitoring for memory access errors until 95% code coverage has been reached
Carry out one of the following methods. Only one method is necessary to complete the assessment.
Method 1: For all cybersecurity-relevant executables that may have memory errors, run the executable in an environment that allows measurement of code coverage and detection of common memory errors. While running the executable, vary the inputs to the product's interfaces that are normally accessible in the product's intended use. Use the code coverage tool to determine which lines of code have been exercised. Continue this process until each line of code that can reasonably be exercised deterministically by providing specific input values has been executed. For each memory error detected, document why it does not constitute an unacceptable risk.
Method 2: For all cybersecurity-relevant executables that may have memory errors, run the executable in an environment that allows measurement of code coverage and detection of common memory errors. While running the executable, vary the inputs to the product's interfaces that are normally accessible in the product's intended use. Use the code coverage tool to determine which lines of code have been exercised. Use a risk-based approach and the output of the code coverage measurements to decide when testing is complete. For each memory error detected, document why it does not constitute an unacceptable risk.
Method 3: Run a tool that tests the boundaries of the input values (minimum valid, maximum valid, minimum possible, maximum possible, off-by-one, etc.) while monitoring for memory errors. For each memory error detected, document why it does not constitute an unacceptable risk.
Method 4: Review source code to determine its language and what exceptions to memory safety exist. For each use of memory-unsafe features or code, document why it does not constitute an unacceptable risk.
#### 6.2.3.4 Verdict
PASS if **all** of the following are fulfilled:
Choose the method with the same number as the method used to carry out the Activities. Only one method is necessary to complete the assessment.
Method 1: PASS if **all** of the following are fulfilled:
* All code that could be deterministically exercised by varying the inputs has been executed, and
* all reported memory errors are documented and justified.
* Code coverage was at least 95%, and
Otherwise FAIL
Method 2: PASS if **all** of the following are fulfilled:
* The interfaces have been properly covered from a risk perspective, and
* all reported memory errors are documented and justified.
Otherwise FAIL
Method 3:
PASS if **all** of the following are fulfilled:
* All boundary values tested, and
* all memory errors detected are documented and justified.
Otherwise FAIL
Method 4:
PASS if **all** of the following are fulfilled:
* Source code is in a memory-safe language, and
* the documentation of all uses of unsafe memory features convincingly demonstrates that each one does not present a cybersecurity risk.
Otherwise FAIL
#### 6.2.3.5 Evidence
Choose the method with the same number as the method used to carry out the Activities. Only one method is necessary to complete the assessment.
Method 1:
* Logs of code coverage tool
* Memory error report
* Documentation of any memory errors
Method 2:
* Documentation of decision on how much to test using a risk-based approach
* Logs of code coverage tool
* Memory error report
* Documentation of any memory errors
Method 3:
* Logs of boundary testing tool
* Memory error report
* Documentation of any memory errors
Method 4:
* Source code
* Documentation of unsafe memory features
#### 6.2.3.6 Guidance for "risk-based approach"
The test scope should be selected based on a risk-based approach. This includes considering the product's intended use and prioritizing functions and interfaces that process untrusted inputs, provide access to security-relevant assets, or execute critical operations, since memory access errors in such areas may have a greater cybersecurity impact.
### 6.2.4 REQ-SSD-04 (MI-BTIN) Boundary testing of inputs that may cause memory errors
