Update Automation tooling to reflect migration to vulnmapper

#### Automation

We use the [security-triage-automation](https://gitlab.com/gitlab-org/secure/tools/security-triage-automation) tool in conjunction with [scheduled pipelines in the release project](https://gitlab.com/gitlab-org/security-products/release/-/blob/master/.gitlab/ci/security-triage-automation.yml?ref_type=heads) to handle the following tasks:

We use [The Vulnmapper tool](https://gitlab.com/gitlab-com/gl-security/product-security/vulnerability-management/vulnerability-management-internal/vulnmapper) to automate our vulnerability lifecycle, it performs these actions for us

1. [Create security issues for FedRAMP vulnerabilities (Container Scanning results only) still detected on the default branch](https://gitlab.com/gitlab-org/secure/tools/security-triage-automation#process-vulnerabilities-for-a-given-project), executed at least once, on the first day of the month to match with FedRAMP compliance report cadence.

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/product-security/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 Actionable Tracking issues with appropriate labels to clarify ownership, operating syste ect. This is filtered to FedRAMP Issues only at this stage.

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

1. Updating & Closing Issues when a vulnerability is resolved.

Note: Our goal is to centralize automation for vulnerability management in the [Vulnmapper tool in the nearest future](https://gitlab.com/gitlab-com/gl-security/product-security/vulnerability-management/vulnerability-management-internal/vulnmapper/-/milestones/4#tab-issues) and standardize our processes across the company. However, so far we're following the existing process based on the [security-triage-automation tool](https://gitlab.com/gitlab-org/secure/tools/security-triage-automation).

VulnMapper does not close vulnerabilities, this is performed by [Auto resolve vulnerabilites](https://gitlab.com/gitlab-org/gitlab-org-security-policy-project/-/blob/main/.gitlab/security-policies/policy.yml?ref_type=heads#L211) security policy at the `gitlab-org` level is configured to resolve vulnerabilities.

#### Automation failures

On a weekly basis: review the vulnerability report to resolve no longer detected ones and close related issues. Note: It is not necessary to investigate vulnerabilities that are no longer detected.

1. Visit `Vulnerability Report Dashboards` to verify that there are vulnerabilities that can be resolved.

2. Execute the `security-triage-automation` tool to [resolve vulnerabilities and close their issues](https://gitlab.com/gitlab-org/secure/tools/security-triage-automation#resolve-vulnerabilities-and-close-their-issues). This tool must be executed separately for each project that have vulnerabilities to resolve.

3. Verify in `Vulnerability Report Dashboards` that vulnerabilities have been resolved.

#### Manually creating security issues for FedRAMP vulnerabilities

Last working day before the 1<sup>st</sup> of the month, create security issues

for FedRAMP vulnerabilities of the `CONTAINER_SCANNING` type, and `CRITICAL`, `HIGH`,

`MEDIUM`, `LOW`, and `UNKNOWN` severity levels by executing the `security-triage-automation`

tool to [process vulnerabilities for a given project](https://gitlab.com/gitlab-org/secure/tools/security-triage-automation#process-vulnerabilities-for-a-given-project)

(please make sure to adjust CLI options accordingly). This tool must be executed

separately for each project.

1. Visit `Vulnerability Report Dashboards` to verify that there are vulnerabilities that can be resolved by the security policy noted above.

1. Notify Vulnerability management of these vulnerabilities for investigation.

1. Vulnmapper will automatically close a tracking issue within 24 hours of the linked vulnerability is marked as resolved.

#### Manually creating deviation requests for FedRAMP vulnerabilities

</details>

##### Troubleshoothing

- **`GITLAB_ACCESS_TOKEN` has expired**. The automation relies on API requests to manage vulnerabilities and issues on various projects. This requires specific permissions and authentication is achieved with a Private Access Token generated on the service account `gl-service-security-triage` (credentials available in 1Password). If the token is expired, a new one (with `api` scope) must be generated by signing in with this account on gitlab.com and then the new value must be configured in [the settings](https://gitlab.com/gitlab-org/security-products/release/-/settings/ci_cd) of the `release` project.

##### FedRAMP vulnerabilities

To ensure compliance, the management of FedRAMP vulnerabilities is handled by [automation](#automation). Please check the manual process fallback for additional details.