@@ -669,29 +669,41 @@ The product shall not process input in such a way as to cause an internal memory
#### 5.2.X.x **MI-SSCA**: Static source code analysis for memory errors
All software and firmware in the product shall be checked for memory errors using a source code analysis tool that detects at least the following types of memory errors, if possible in the source code language:
All security-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:
* buffer overflow
* out-of-bounds
* use after free
* double free
* uninitialized variables
* dereference invalid pointer
* FIXME make this more rigorous
* use of uninitialized variables
* dereference of invalid pointer
All warnings, annotations, or other method of suppressing warnings from the analysis tool shall be accompanied by an explanation of why the code in question will not negatively affect the product assets under reasonably foreseeable conditions, including intentional attempts to exploit it.
The sufficiency of the source code analysis tool and the selected manner of running it shall be documented.
* Test: run a source code analysis tool on all firmware and software
* Result: no warnings, and any suppressed warnings have documentation showing why they are safe
* Output: the source code, the output of the source code analysis checker, and the documentation for suppressed warnings
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.
Guidance: Some compilers may meet this requirement with the correct compiler flags.
* Reference: TR-IMEM
* 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: Sufficiency 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
The product shall be checked for memory errors by running a tool that exercises the functions of the product in an environment while measuring code coverage and detecting memory access errors.
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. All memory errors detected shall be documented with a rationale for why it does not constitute an unacceptable risk.
* Test: run the tool until 95% code coverage is reached
* Result: no memory safety errors are detected
* Reference: TR-IMEM
* Objective: Prevent unauthorized memory access
* Preparation: None
* Activities: Run the tool while measuring code coverage and monitoring for memory access errors until 95% code coverage has been reached
* Verdict: Code coverage was at least 95%, all reported memory errors are documented => PASS, otherwise FAIL
* Evidence: Logs of code coverage tool, memory error report, any documentation of memory errors
#### 5.2.X.x MI-IMSL Implement in a memory-safe language
