Merge branch 'memory-safety-req-and-acc' into 'main_publish'

Note: 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.

**[REQ-MEM-KEV-1]**: Web browser interfaces that are, or could potentially be, exposed to untrusted data shall undergo automated dynamic analysis to identify vulnerabilities (for example, via techniques such as fuzzing in an environment that enables the detection of memory access errors).

**[REQ-MEM-KEV-1]**: The web browser's source code that parses untrusted, non-trivial data, shall undergo ongoing automated dynamic analysis to identify vulnerabilities.

**[REQ-MEM-KEV-2]** The web browser source code shall undergo automated static analysis to identify vulnerabilities (for example, via LLM code analysis). 

Example: Code that parses media files is subjected to fuzz testing in an environment that enables the detection of memory safety errors, such as LLVM sanitisers.

**[REQ-MEM-KEV-3]** The web browser source code shall make use of languages, language features, libraries, and/or automation-enforced coding conventions that prevent well-known classes of vulnerability from being introduced (for example, via the use of memory safe languages, bounds checked container classes, restricting use of raw pointers).

**[REQ-MEM-KEV-2]** The product's source code shall undergo ongoing automated static analysis to identify vulnerabilities.

Example: Via LLM code analysis, static application security testing tools.

**[REQ-MEM-KEV-3]** The product shall be implemented using programming languages, language features, and/or automation-enforced coding conventions that limit the introduction of memory safety vulnerabilities.

Example: Via the use of memory safe languages, bounds checked container classes, restrictions on the use of raw pointers.

## 5.3 Secure by default configuration

Example: Usage of cross-origin options such as `X-Frame-Options` or `Cross-Origin-Resource-Policy` allow source origins to specify usage constraints for products to receive and enforce.

**[REQ-MEM-MAS-1]** The web browser shall not include unneeded functionality that is, or could potentially be, exposed to untrusted data (for example, shall not expose code implementing an unused file format).

**[REQ-MEM-MAS-1]** The web browser shall use operating system functionality to restrict the capabilities and privileges of architectural components of the web browser.

**[REQ-MEM-MAS-2]** The web browser shall validate or otherwise render harmless untrusted data before exposing it to complex parsing functionality implemented in a non-memory safe language, or in a privileged process.

Example: Via sandboxed processes, system call filtering.

## 5.12 Exploitation Mitigation Mechanisms

**[REQ-ISO-EMM-3]**: The product shall reduce the privileges of its various components with respect to the operating system to the level required to perform their tasks.

**[REQ-MEM-EMM-1]** The web browser shall include assertions to the correctness of program state, which fail safely (for example, an unexploitable crash) when violated (for example, via the use of ASSERT() or CHECK() statements).

**[REQ-MEM-EMM-1]** The web browser shall include runtime assertions as to the correctness of program state, which fail safely when violated.

Example: Via the use of ASSERT() or CHECK() statements that result in an unexploitable crash.

**[REQ-MEM-EMM-2]** The web browser shall use compiler features designed to reduce the risk of exploitation.

**[REQ-MEM-EMM-1]** Portions of the web browser that are not implemented in a memory safe language shall employ mitigations to reduce exploitability of memory safety vulnerabilities (for example, via compiler flags, hardened allocators).

Example: stack canaries, source code fortification, variable initialisation.

**[REQ-MEM-EMM-1]** The web browser should make use of mitigation technologies provided by the operating system and/or hardware when appropriate  (for example, hardware-assisted memory tagging, ASLR).

**[REQ-MEM-EMM-3]** The web browser shall use mitigation technologies provided by the operating systems and/or hardware on which the web browser is designed to run.

**[REQ-MEM-EMM-1]** Web browser processes should only have access to a restricted set of operating system capabilities and privileges as required by their function (e.g. via sandboxing, system call filtering)

Example: hardware-assisted memory tagging, Address Space Layout Randomization.

<mark>Editor's note: Should sandboxing generally be considered by memory safety, or isolation?</mark>

## 5.13 Logging and Monitoring

Proposed ESR code: LOG

Proposed ESR code: KEV

### [ACC-MEM-KEV-1]

Assessment of [REQ-MEM-KEV-1]

**Assessment Reference:** The web browser's source code that parses untrusted, non-trivial data shall undergo ongoing automated dynamic analysis to identify vulnerabilities.

**Assessment Objective:** The manufacturer conducts ongoing automated dynamic analysis to identify vulnerabilities in the web browser.

**Assessment Preparation:**

- Documentation describing how code is selected to undergo automated dynamic analysis.

- Documentation describing how, and how often, the automated dynamic analysis is conducted.

- Documentation describing a methodology for measuring and improving the code coverage of their dynamic analysis tools over time.

- Code coverage reports.

- A sample of bug tracker entries generated by each dynamic analysis technique described in the documentation.

**Assessment Activities:**

The following steps are to be carried out in order:

1. Review the documentation.

2. Review the code coverage reports.

3. Review the bug tracker entries.

**Assignment of Verdict:**

- **Pass**:

    - The documentation describes a methodology for how code is selected to undergo automated dynamic analysis.

    - The documentation describes one or more dynamic analysis techniques and how they are automated and integrated into the web browser's software development lifecycle.

    - The documentation describes a robust methodology for measuring and improving the code coverage of their dynamic analysis tools over time.

    - Code coverage reports demonstrate that the dynamic analysis achieves the coverage targets defined in the manufacturer's methodology, or show documented progress toward those targets.

    - The bug tracker entries show evidence of being filed in an automated fashion as described in the documentation. 

    - The bug tracker entries describe identified vulnerabilities.

    - The bug tracker entries show the identified vulnerabilities have been fixed.

- **Fail**: 

    - Any of the above are not fulfilled.

**Supporting Evidence:**

- Log of documentation and bug tracker entry review.

### [ACC-MEM-KEV-2]

Assessment of [REQ-MEM-KEV-2]

**Assessment Reference:** The web browser's source code shall undergo ongoing automated static analysis to identify vulnerabilities.

**Assessment Objective:** The manufacturer conducts ongoing automated static analysis to identify vulnerabilities in the web browser.

**Assessment Preparation:**

- Documentation describing the automated static analysis that is conducted.

- A sample of bug tracker entries generated by each static analysis technique described in the documentation.

**Assessment Activities:**

The following steps are to be carried out in order:

1. Review the documentation.

2. Review the bug tracker entries.

**Assignment of Verdict:**

- **Pass**:

    - The documentation describes one or more static analysis techniques and how they are automated and integrated into the web browser's software development lifecycle.

    - The bug tracker entries show evidence of being filed in an automated fashion as described in the documentation. 

    - The bug tracker entries describe identified vulnerabilities.

    - The bug tracker entries show the identified vulnerabilities have been fixed.

- **Fail**: 

    - Any of the above are not fulfilled.

**Supporting Evidence:**

- Log of documentation and bug tracker entry review.

### [ACC-MEM-KEV-3]

Assessment of [REQ-MEM-KEV-3]

**Assessment Reference:** The manufacturer shall use programming languages, language features, and/or automation-enforced coding conventions that limit the introduction of memory safety vulnerabilities.

**Assessment Objective:** The web browser's source code is hardened against the introduction of memory safety vulnerabilities.

**Assessment Preparation:**

- Documentation describing the techniques the manufacturer uses to limit the introduction of memory safety vulnerabilities into the web browser.

- Documentation describing how those methods are applied to the architectural components of the web browser.

- For architectural components to which those methods are not applied, documentation describing the mitigations in place to reduce the risk of memory safety vulnerabilities from being successfully exploited.

- Documentation describing the policies by which those methods are applied to the web browser's software development lifecycle.

- Relevant software development lifecycle artefacts, such as design documents, bug tracker entries, security review outcomes. 

- The web browser's source code.

**Assessment Activities:**

The following steps are to be carried out in order:

1. Review the documentation.

2. For each of the methods used to limit the introduction of memory safety vulnerabilities, confirm via spot checks of the source code that the method is applied in accordance with the documentation.

3. Confirm the relevant software development lifecycle policies are being followed via spot checks of artefacts.

**Assignment of Verdict:**

- **Pass**:

    - The documentation describes methods that limit the introduction of memory safety vulnerabilities.

    - The documentation maps those methods to the architectural components of the web browser.

    - The mitigations applied to relevant architectural components convincingly reduce the risk of memory safety vulnerabilities from being successfully exploited.

    - The relevant software development lifecycle policies are being followed.

- **Fail**: 

    - Any of the above are not fulfilled.

**Supporting Evidence:**

- Log of documentation, source code, and artefact review.

## 6.3 Secure by design

Proposed ESR code SBD

Proposed ESR code: MAS

### [ACC-MEM-MAS-1]

Assessment of [REQ-MEM-MAS-1]

**Assessment Reference:** The web browser shall use operating system functionality to restrict the capabilities and privileges of architectural components of the web browser.

**Assessment Objective:** The web browser takes steps to limit exposed operating system attack surface, which also serves to limit the consequences of successful exploitation, unless a documented functional requirement necessitates elevated privileges.  

**Assessment Preparation:**

- Documentation describing the operating system functionality used by the web browser to limit exposed operating system attack surface and limit the consequences of successful exploitation. 

- Documentation describing how those methods are applied to the architectural components of the web browser.

- For architectural components to which those methods are not applied, documentation describing the rationale for this decision, and mitigations in place to reduce exploitation risk.

- The web browser's source code.

- Tools to inspect a running binary.

**Assessment Activities:**

The following steps are to be carried out in order:

1. Review the documentation.

2. For each method of operating system functionality listed in the web browser documentation, confirm via spot checks of the source code that the method is applied in accordance with the documentation.

3. Run tools to inspect the running web browser.

**Assignment of Verdict:**

- **Pass**:

    - The documentation describes operating system functionality that can limit exposed operating system attack surface, and limit the consequences of successful exploitation. 

    - The documentation maps those methods to the architectural components of the web browser.

    - For each of the methods listed in the documentation as not being applied to an architectural component, the documentation convincingly describes the rationale for this decision.

    - The mitigations applied to relevant architectural components convincingly reduce the risk of exploitation.

    - For each method that results in changes readily inspectable in a running binary, tooling confirms the method is in use.

- **Fail**: 

    - Any of the above are not fulfilled.

**Supporting Evidence:**

- Log of documentation review.

- Log of tooling output.

### [ACC-EXT-MAS-1]

Assessment of [REQ-EXT-MAS-1]

Proposed ESR code: EMM

### [ACC-MEM-EMM-1]

Assessment of [REQ-MEM-EMM-1]

**Assessment Reference:** The web browser shall include runtime assertions as to the correctness of program state, which fail safely when violated.

**Assessment Objective:** The web browser contains runtime checks which help prevent the web browser from entering an unexpected state, which can lead to exploitable vulnerabilities.

**Assessment Preparation:**

- Documentation describing the techniques developers can use to ensure that runtime invariants hold and fail in an unexploitable fashion.

- The web browser's source code.

**Assessment Activities:**

The following steps are to be carried out in order:

1. Review the source code that implements the techniques developers can use to ensure that runtime invariants hold and fail in an unexploitable fashion.

2. Review the usage of the techniques within the source code.

**Assignment of Verdict:**

- **Pass**:

    - The techniques developers can use to ensure that runtime invariants hold and fail in an unexploitable fashion.

    - The techniques are widely used within the source code.

- **Fail**: 

    - Any of the above are not fulfilled.

**Supporting Evidence:**

- Log of source code review.

### [ACC-MEM-EMM-2]

Assessment of [REQ-MEM-EMM-2]

**Assessment Reference:** The web browser shall use compiler features designed to reduce the risk of exploitation.

**Assessment Objective:** The web browser uses hardening features provided by the compiler.

**Assessment Preparation:**

- Documentation describing the security relevant compiler flags and features that are enabled in the product's release configuration.

- The web browser's source code and build configuration.

- Tools to inspect compiled binaries.

**Assessment Activities:**

The following steps are to be carried out in order:

1. Review the documentation.

2. For each of the security relevant compiler flags and features listed in the web browser documentation, confirm via inspection of the web browser source code and build configuration that it is indeed being used in the build of the release configuration.

3. Run tooling against the web browser's compiled binaries.

**Assignment of Verdict:**

- **Pass**:

    - The compiler flags and features listed as being used in the web browser documentation are indeed being used in the build of the release configuration.

    - For each security relevant compiler flag, the enablement of which results are readily inspectable in the resulting compiled binary, tooling output confirms the feature is in a state that matches the web browser documentation.

- **Fail**: 

    - Any of the above are not fulfilled.

**Supporting Evidence:**

- Log of documentation review.

- Log of source code and build configuration review.

- Log of tooling output.

### [ACC-MEM-EMM-3]

Assessment of [REQ-MEM-EMM-3]

**Assessment Reference:** The web browser shall use mitigation technologies provided by the operating systems and/or hardware on which the web browser is designed to run.

**Assessment Objective:** The web browser uses hardening features provided by the operating system and/or hardware.

**Assessment Preparation:**

- Documentation describing the mitigation technologies provided by the operating system and/or hardware on which the web browser is designed to run, which are used by the web browser.

- Documentation describing the rationale for not using any mitigation technologies provided by the operating system and/or hardware on which the web browser is designed to run.

- The web browser's source code and build configuration.

**Assessment Activities:**

The following steps are to be carried out in order:

1. Review the documentation.

2. For each of the mitigation technologies listed in the web browser documentation, confirm via inspection of the web browser source code and build configuration that it is indeed being used in the release configuration.

**Assignment of Verdict:**

- **Pass**:

    - The mitigation technologies listed in the web browser documentation are indeed being used by the release configuration of the web browser.

    - For each of the mitigation technologies listed in the documentation as not being used, the documentation convincingly describes the rationale for this decision.

- **Fail**: 

    - Any of the above are not fulfilled.

**Supporting Evidence:**

- Log of documentation review.

- Log of source code and build configuration review.

### [ACC-EXT-EMM-1]

Assessment of [REQ-EXT-EMM-1]