@@ -376,6 +376,70 @@ This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 P
> NOTE: It is proposed that a cross-vertical task force could work on the technical requirements to be included in this clause.
### REQ-KEV-1: Testing for known exploitable vulnerabilities
In accordance with the requirement to apply effective and regular tests to the security of the product, the product shall be tested to demonstrate the absence or mitigation of known exploitable vulnerabilities. Testing shall specifically target known exploitable vulnerabilities that impact the product's architecture, platform, and the specific software components identified in the product's Software Bill of Materials (SBOM).
To demonstrate compliance, the manufacturer may rely on manual security testing (e.g., penetration testing), automated vulnerability scanners, or a combination of both, depending on what is most comprehensive and technically feasible for the product's technology stack.
The product shall be considered conformant with this requirement if it:
1. has no known exploitable vulnerabilities discovered during testing,
1. has discoverable known exploitable vulnerabilities whose age is consistent with the specification of how long vulnerabilities may go unfixed after public disclosure, as described in the vulnerability handling procedure for the product, or
1. for each detected vulnerability, has publicly available documentation explaining how the risk has been mitigated.
* Objective: Prevent exploitation of known exploitable vulnerabilities
* Preparation: Using the product's SBOM and relevant publicly accessible vulnerability databases (e.g. [GCVE](https://gcve.eu), [EUVD](http://euvd.enisa.europa.eu)), compile a list of target components and potential known exploitable vulnerabilities. Select the appropriate testing methodology (e.g., the most comprehensive automated scanners available, or a manual penetration test plan) to verify the mitigation of these vulnerabilities.
* Activities: On a new product, carry out a security update, run the tests, and compare the results with the generated list of known exploitable vulnerabilities.
* Verdict: No vulnerabilities found, or all reported vulnerabilities satisfy either the age or mitigation requirement => PASS, otherwise FAIL
* Evidence: Documented vulnerability handling policy, product SBOM, list of testing tools used or manual test plan, test reports/scan results, correlation of discovered vulnerabilities with documentation of mitigation or age of vulnerability.
### REQ-KEV-2: 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:
* buffer overflow
* out-of-bounds
* use after free
* double free
* use of uninitialized variables
* dereference of invalid pointer
Any identified memory errors or suppression of warnings shall be documented with a rationale for why it does not constitute an unacceptable risk.
* Objective: Prevent unauthorized memory access
* 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.
### REQ-KEV-3: Memory safty protections
The product shall protect against out-of-band memory access by implement at least one of the following mitigations:
1.**Runtime code coverage checking with memory access error detection**
The product shall be checked for memory errors by running a tool that exercises at least 95% 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.
* 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 and justified => PASS, otherwise FAIL
* Evidence: Logs of code coverage tool, memory error report, documentation of any memory errors
2.**Implement in a memory-safe language**
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.
* 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
* Evidence: Source code, documentation of unsafe memory features
3.**Boundary testing of inputs that may cause memory errors**
The input fields of the product that may produce memory errors shall be identified. The product shall be boundary tested for all such inputs while monitoring for memory errors. All memory errors detected shall be documented with a rationale for why it does not constitute an unacceptable risk.
* Objective: Prevent unauthorized memory access
* Preparation: Identify input fields in the product that may produce memory errors
* Activities: 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
* Verdict: All boundary values tested and all memory errors detected are documented and justified => PASS, otherwise FAIL
* Evidence: Logs of boundary testing tool, memory error report, documentation of any memory errors
