Update handbook files for change from 30 to 90 day disclosure policy

### CVE IDs

We use CVE IDs to uniquely identify and publicly define vulnerabilities in our products. Since we publicly disclose all security vulnerabilities 30 days after a patch is released, CVE IDs must be obtained for each vulnerability impacting self-managed to be fixed. The earlier obtained the better, and it should be requested either during or immediately after a fix is prepared.

We use CVE IDs to uniquely identify and publicly define vulnerabilities in our products. Since we publicly disclose all security vulnerabilities 90 days after a patch is released, CVE IDs must be obtained for each vulnerability impacting self-managed to be fixed. The earlier obtained the better, and it should be requested either during or immediately after a fix is prepared.

We currently request CVEs [through our CVE project](https://about.gitlab.com/security/cve/). Keep in mind that some of our security releases contain *security related* enhancements which may not have an associated [CWE](https://cwe.mitre.org/) or vulnerability. These particular issues are not required to obtain a CVE since there's no associated vulnerability.

- All security patches are pushed to the public repository.

- The public is notified via the GitLab blog release post, security alerts email, and Twitter.

The GitLab issue should then be closed and - after 30 days - sanitized and made public. If the report was received via HackerOne, follow the [HackerOne process](/handbook/security/product-security/psirt/runbooks/hackerone-process/#closing-out--disclosing-issues).

The GitLab issue should then be closed and - after 90 days - sanitized and made public. If the report was received via HackerOne, follow the [HackerOne process](/handbook/security/product-security/psirt/runbooks/hackerone-process/#closing-out--disclosing-issues).

### Process for disclosing security issues

At GitLab we value [being as transparent as possible](/handbook/values/#transparency), even [when it costs](/handbook/values/#transparency-is-most-valuable-if-you-continue-to-do-it-when-there-are-costs). Part of this is making confidential GitLab issues about security vulnerabilities public 30 days after a patch. The process is as follows:

At GitLab we value [being as transparent as possible](/handbook/values/#transparency), even [when it costs](/handbook/values/#transparency-is-most-valuable-if-you-continue-to-do-it-when-there-are-costs). Part of this is making confidential GitLab issues about security vulnerabilities public 90 days after a patch. The process is as follows:

1. Check for a `~keep confidential` tag. If one exists

   1. Decide whether this tag is still appropriate and in line with our [Transparency value](/handbook/values/#transparency)

1. Edit the Confidentiality of the issue and set it to Public

1. Remove the `~publication-pending` label, if one exists.

To facilitate this process the [GitLab Security Bot](https://gitlab.com/gitlab-com/gl-security/engineering-and-research/automation-team/appsec-escalator) comments on confidential issues 30 days after issue closure when they are not labeled `~keep confidential`.

To facilitate this process the [GitLab Security Bot](https://gitlab.com/gitlab-com/gl-security/engineering-and-research/automation-team/appsec-escalator) comments on confidential issues 90 days after issue closure when they are not labeled `~keep confidential`.

### Handling Disruptive Researcher Activity

### High-level description of the process

GitLab's HackerOne process manages vulnerability reports through a structured workflow where security researchers submit findings through HackerOne, which are then triaged by the HackerOne team before moving to GitLab's security team. The PSIRT engineer on rotation assigns, validates, and imports valid reports into GitLab issues, calculating CVSS scores to determine severity and bounty amounts. They follow specific protocols for different vulnerability types (exposed secrets, vulnerability chaining, DNS takeovers), maintain regular communication with reporters, and ensure proper remediation tracking. After fixes are deployed, reports are closed and may be publicly disclosed following a 30-day waiting period, with successful reporters potentially earning both bounties and Ultimate licenses.

GitLab's HackerOne process manages vulnerability reports through a structured workflow where security researchers submit findings through HackerOne, which are then triaged by the HackerOne team before moving to GitLab's security team. The PSIRT engineer on rotation assigns, validates, and imports valid reports into GitLab issues, calculating CVSS scores to determine severity and bounty amounts. They follow specific protocols for different vulnerability types (exposed secrets, vulnerability chaining, DNS takeovers), maintain regular communication with reporters, and ensure proper remediation tracking. After fixes are deployed, reports are closed and may be publicly disclosed following a 90-day waiting period, with successful reporters potentially earning both bounties and Ultimate licenses.

## Key Stakeholders and Responsibilities

- Issue management and disclosure:

  - Communicate regularly with reporters (at least monthly)

  - Follow SLA exception process when needed

  - Close and disclose issues after patches are released (30-day waiting period)

  - Close and disclose issues after patches are released (90-day waiting period)

- Additional benefits:

  - Researchers with 3+ valid reports are eligible for 1-year Ultimate licenses

  - HackerOne Triage Team members receive Ultimate licenses

    - Fill in the `01 - Duplicate` common response. Include the link to the GitLab issue.

    - The team member may use their discretion if the reporter asks to be added as a contributor to the original H1 report;

        however, the default is to not add because the corresponding GitLab issue will

        be made public 30 days after the patch is released. If it is decided to add the

        be made public 90 days after the patch is released. If it is decided to add the

        duplicate reporter, ensure that the report does not have reporter sensitive information before allowing access.

        `05 - Duplicate Follow Up, No Adding Contributors/Future Public Release` common response

        can be used when denying the request to add as a contributor.

When a patch is released and the award process complete, it is time to close the HackerOne issue.

After 30 days, follow the [process for disclosing security issues](/handbook/security/engaging-with-security/#process-for-disclosing-security-issues).

After 90 days, follow the [process for disclosing security issues](/handbook/security/engaging-with-security/#process-for-disclosing-security-issues).

Once this has occurred, the HackerOne issue can also be publicly disclosed on

a case-by-case basis, following the same process to remove sensitive information.

We should not disclose, or request to disclose, a HackerOne issue while the GitLab issue