Fix broken linked to restructured vulnerability management pages

scans all images we produce to highlight CVE vulnerabilities. From those scans, the

[`vulnmapper`](https://gitlab.com/gitlab-com/gl-security/threatmanagement/vulnerability-management/vulnerability-management-internal/vulnmapper)

project creates issues in the project that created the vulnerable image, including

[SLAs](../../../../../security//product-security/vulnerability-management/#remediation-slas) to which we must adhere.

[SLAs](/handbook/security/product-security/vulnerability-management/sla/) to which we must adhere.

The Runner team member assigned the `Support & Security Responder` role in the weekly team task should triage and

review the list of CVEs and address any issues as appropriate:

- `Critical` severity issues should be addressed immediately.

- `High`, `Medium`, and `Low` severity issues should be addressed in the priority order of the

  [remediation SLAs](../../../../../security/product-security/vulnerability-management/#remediation-slas).

  [remediation SLAs](/handbook/security/product-security/vulnerability-management/sla/).

The procedure for addressing CVE issues is as follows:

Note that we do not yet automatically create security issues for non-FedRAMP vulnerabilities. Please see the [Non-FedRAMP vulnerabilities section](#non-fedramp-vulnerabilities) for more details.

1. [Resolve all vulnerabilities (both FedRAMP and non-FedRAMP) no longer detected on the default branch and close their issues](https://gitlab.com/gitlab-org/secure/tools/security-triage-automation#resolve-vulnerabilities-and-close-their-issues), executed every 2 days.

[The Vulnmapper tool](https://gitlab.com/gitlab-com/gl-security/threatmanagement/vulnerability-management/vulnerability-management-internal/vulnmapper) also provides some [automation to vulnerability management](/handbook/security/product-security/vulnerability-management/#automation) like:

[The Vulnmapper tool](https://gitlab.com/gitlab-com/gl-security/threatmanagement/vulnerability-management/vulnerability-management-internal/vulnmapper) also provides some [automation to vulnerability management](/handbook/security/product-security/vulnerability-management/automation/) like:

1. Adding labels to security issues to further classify the fix availability (fix_available, fix_unavailable, will_not_be_fixed, etc.).

1. Creating Deviation Request issues for FedRAMP related security issues that should have one.

#### Security Policy

We prioritize findings by their CVSS severities and [SLAs](/handbook/security/product-security/vulnerability-management/#remediation-slas), and currently focus on security findings with these severity levels:

We prioritize findings by their CVSS severities and [SLAs](/handbook/security/product-security/vulnerability-management/sla/), and currently focus on security findings with these severity levels:

- Critical

- High

| `~"bug::performance"` Browser Rendering <br> ([TBT](https://web.dev/tbt/))[^2] | Above 9000ms to timing out | Between 2000ms and 9000ms | Between 1000ms and 2000ms | Between 300ms and 1000ms | [Enablement Quality Engineering team](/handbook/engineering/infrastructure/test-platform/self-managed-platform-team/) |

| `~bug::ux` User experience problem [³](#ux) | "I can't figure this out." Users are blocked and/or likely to make risky errors due to poor usability, and are likely to ask for support. | "I can figure out why this is happening, but it's really painful to solve." Users are significantly delayed by the available workaround. | "This still works, but I have to make small changes to my process." Users are self sufficient in completing the task with the workaround, but may be somewhat delayed. |  "There is a small inconvenience or inconsistency." Usability isn't ideal or there is a small cosmetic issue. | [Product Designers](/handbook/product/ux/product-design/) of that Product group |

| `~"bug::availability"` of GitLab SaaS | See [Availability section](#availability) | See [Availability section](#availability) | See [Availability section](#availability) | See [Availability section](#availability) | |

| `~"bug::vulnerability"` Security Vulnerability | See [Vulnerability Remediation SLAs](/handbook/security/product-security/vulnerability-management/#remediation-slas) | See [Vulnerability Remediation SLAs](/handbook/security/product-security/vulnerability-management/#remediation-slas) | See [Vulnerability Remediation SLAs](/handbook/security/product-security/vulnerability-management/#remediation-slas) | See [Vulnerability Remediation SLAs](/handbook/security/product-security/vulnerability-management/#remediation-slas) | AppSec team |

| `~"bug::vulnerability"` Security Vulnerability | See [Vulnerability Remediation SLAs](/handbook/security/product-security/vulnerability-management/sla/) | See [Vulnerability Remediation SLAs](/handbook/security/product-security/vulnerability-management/sla/) | See [Vulnerability Remediation SLAs](/handbook/security/product-security/vulnerability-management/sla/) | See [Vulnerability Remediation SLAs](/handbook/security/product-security/vulnerability-management/sla/) | AppSec team |

| Global Search | See [Search Prioritization](/handbook/engineering/infrastructure/core-platform/data_stores/search/#severity-labels-for-search-issues-advanced-search-global-search) | See [Search Prioritization](/handbook/engineering/infrastructure/core-platform/data_stores/search/#severity-labels-for-search-issues-advanced-search-global-search) | See [Search Prioritization](/handbook/engineering/infrastructure/core-platform/data_stores/search/#severity-labels-for-search-issues-advanced-search-global-search) | See [Search Prioritization](/handbook/engineering/infrastructure/core-platform/data_stores/search/#severity-labels-for-search-issues-advanced-search-global-search) | |

| `~test` Bugs blocking end-to-end test execution | See [Blocked tests section](#blocked-tests) | See [Blocked tests section](#blocked-tests) | See [Blocked tests section](#blocked-tests) | See [Blocked tests section](#blocked-tests) | [Test Platform Sub-Department](/handbook/engineering/infrastructure/test-platform/) |

| `~GitLab.com Resource Saturation` Capacity planning warnings | Mean forecast shows Hard SLO breach within 3 months. | | | | Scalability Engineering Manager (who will hand over to EM that owns the resource) |

| **Severity**   | Incident root cause analysis `~corrective action` SLO | `~"type::bug"` resolution SLO | `~"GitLab.com Resource Saturation"` resolution SLO | Security `~vulnerability` SLO |

|----------------|---------|--------------------------------------------------------------------------------| ----|-----|

| `~"severity::1"` | 1 week  | The current release + next available deployment to GitLab.com (within 30 days) | Within 2 months | See [Vulnerability Remediation SLAs](/handbook/security/product-security/vulnerability-management/#remediation-slas) |

| `~"severity::2"` | 30 days | The next release (60 days)                                                   |  | See [Vulnerability Remediation SLAs](/handbook/security/product-security/vulnerability-management/#remediation-slas)  |

| `~"severity::3"` | 60 days | Within the next 3 releases (approx one quarter or 90 days) |  | See [Vulnerability Remediation SLAs](/handbook/security/product-security/vulnerability-management/#remediation-slas) |

| `~"severity::4"` | 90 days | Anything outside the next 3 releases (more than one quarter or 120 days).    |  |  See [Vulnerability Remediation SLAs](/handbook/security/product-security/vulnerability-management/#remediation-slas)  |

| `~"severity::1"` | 1 week  | The current release + next available deployment to GitLab.com (within 30 days) | Within 2 months | See [Vulnerability Remediation SLAs](/handbook/security/product-security/vulnerability-management/sla/) |

| `~"severity::2"` | 30 days | The next release (60 days)                                                   |  | See [Vulnerability Remediation SLAs](/handbook/security/product-security/vulnerability-management/sla/)  |

| `~"severity::3"` | 60 days | Within the next 3 releases (approx one quarter or 90 days) |  | See [Vulnerability Remediation SLAs](/handbook/security/product-security/vulnerability-management/sla/) |

| `~"severity::4"` | 90 days | Anything outside the next 3 releases (more than one quarter or 120 days).    |  |  See [Vulnerability Remediation SLAs](/handbook/security/product-security/vulnerability-management/sla/)  |

#### Examples of severity levels

Patch validation can be performed in 3 ways.

- Manually by cross examining the logs of the host with the vulnerability finding in [wiz.io](https://wiz.io).

- Reviewing vulnerability & tracking issue raised into GitLab by [Vulnerability Management teams automation] (/handbook/security/product-security/vulnerability-management/#automation)

- Reviewing vulnerability & tracking issue raised into GitLab by [Vulnerability Management teams automation] (/handbook/security/product-security/vulnerability-management/automation/)

- Reach out to Vulnerability Management in slack `#g_vulnerability_management`

### General OS (Ubuntu or other Linux) Version updates