Rewrite MI-VULH-2 section and update numbering

The product shall have vulnerability handling processes compliant with <a ref="_ref_3">[3] prEN 40000-1-3: "Cybersecurity requirements for products with digital elements – Vulnerability Handling".

The product shall have vulnerability handling processes compliant with <a ref="_ref_3">[3] prEN 40000-1-3: "Cybersecurity requirements for products with digital elements – Vulnerability Handling".

#### 5.2.18.2 MI-VULH: Vulnerability handling

#### 5.2.18.2 MI-VULH-1: Vulnerability Handling in the Product

The product shall have vulnerability handling processes compliant with <a ref="_ref_3">[3] prEN 40000-1-3: "Cybersecurity requirements for products with digital elements – Vulnerability Handling".

The product shall have vulnerability handling processes compliant with <a ref="_ref_3">[3] prEN 40000-1-3: "Cybersecurity requirements for products with digital elements – Vulnerability Handling".

  * Verdict: Vulnerability handling documentation is compliant with <a ref="_ref_3">[3] prEN 40000-1-3: "Cybersecurity requirements for products with digital elements – Vulnerability Handling" => PASS, otherwise FAIL

  * Verdict: Vulnerability handling documentation is compliant with <a ref="_ref_3">[3] prEN 40000-1-3: "Cybersecurity requirements for products with digital elements – Vulnerability Handling" => PASS, otherwise FAIL

  * Evidence: Vulnerability handling documentation, comparison with <a ref="_ref_3">[3] prEN 40000-1-3: "Cybersecurity requirements for products with digital elements – Vulnerability Handling"

  * Evidence: Vulnerability handling documentation, comparison with <a ref="_ref_3">[3] prEN 40000-1-3: "Cybersecurity requirements for products with digital elements – Vulnerability Handling"

> TODO-HAS: Make the below text into a mitigation for the vulnerability handling requirement above, or delete if no longer necessary.

#### 5.2.18.3 MI-VULH-2: Enabling Vulnerability Handling in Integrated Products

General Vulnerability Handling

When the product is intended for integration into subsequent products in a supply chain, system vulnerabilities may have a particularly high impact on the security characteristics of the final product. Therefore, manufacturers of operating systems intended for integration in subsequent products have a responsibility to enable the vulnerability handling processes of manufacturers which depend upon them. This is accomplished by sharing, as appropriate to the specific risks, details of the operating system's components to enable downstream manufacturers to participate in coordinated vulnerability handling procedures described in <a ref="_ref_3">[3] prEN 40000-1-3: "Cybersecurity requirements for products with digital elements – Vulnerability Handling". 

Operating Systems often provide the essential functionality of securely updating the underlying hardware and the installed software products which rely on the operating system.

  * Applicability: any operating system intended for integration in subsequent products, rather than use by an end-user

  * Reference: TR-VULH

Given this essential role of the operating system in maintaining the security of products which rely on operating systems, it is important that vulnerabilities in operating systems are remediated expediently and in coordination with manufacturers of products that rely upon them.

  * Objective: Vulnerability handling

  * Activities: Review product's SBOM for detailed lists of third-party components and verify the accuracy of identifiers of those components. If applicable and permissible, apply scanning and analysis techniques to the product to verify that the supplied SBOM is accurate and complete.

For operating systems that rely on third-party open source software components, the manufacturer's vulnerability handling process shall include:

  * Verdict:  Product's SBOM contains accurate identifiers for third-party components which can be verified from appropriate sources and unlisted third-party components are not discovered through product inspection => PASS, otherwise FAIL

1. recording of all third-party open source components by name, version, source location, and hash-based identifier;

  * Evidence: Logs from product analysis and comparison to supplied SBOM 

1. proactive monitoring of external sources for vulnerability disclosure regarding the third-party open source components;

This should be accomplished by implementing additional vulnerability handling steps according to common industry standards such as << INFORMATIVE REFERENCE TO FIRST GUIDANCE HERE >>, and by relying on accepted standards for precise software identification, such as << INFORMATIVE REFERENCE TO PURL and SWHID HERE >>.

Enabling Vulnerability Handling in Integrated Products

When Operating Systems are integrated into subsequent products in a supply chain, vulnerabilities in the operating system may have a particularly high impact on the security characteristics of the final product. Therefore, manufacturers of Operating Systems intended for integration in subsequent products have a responsibility to enable the vulnerability handling processes of manufacturers which depend upon them.

If an operating system's use cases support integration into subsequent products, then the manufacturer of the operating system shall provide:

1. clear documentation of all essential security capabilities which the operating system provides to the integrator, and

1. unique, unambiguous, and machine-readable identification of all components of the operating system, including third party components, in a format consistent with common vulnerability handling standards.

Providing this information enables the manufacturer which integrates the operating system to:

1. verify that the forseeable use of the final product can rely on appropriate security protections from the operating system, and

1. verify that the product, including components integrated in the operating system, is free of known vulnerabilities at the time it is placed on the market, and

1. proactively monitor for the disclosure of new vulnerabilities, including in the operating system and its components, which might affect the security of the final product.

## 5.3 Risk Mitigation Sets

## 5.3 Risk Mitigation Sets