Clarify public dependency CVE bump handling

- Include a bug fix in a patch release, please follow the steps on the [patch release runbook for GitLab engineers](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/patch/engineers.md). Security vulnerabilities in GitLab and its dependencies are to be addressed following the [Security Remediation SLAs](/handbook/security/product-security/vulnerability-management/sla/).

Bug fixes are worked on in the GitLab canonical repositories, while security fixes are worked on in the mirrored GitLab

security repositories to avoid revealing vulnerabilities before the release.

security repositories to avoid revealing vulnerabilities before the release. An exception is dependency-only version bumps that remediate vulnerabilities already covered by a public CVE or vendor advisory. These can be implemented in the canonical repositories when they follow the [dependency version bumps](/handbook/security/product-security/security-platforms-architecture/application-security/vulnerability-management#dependency-version-bumps) guidance in the Application Vulnerability Management Procedure.

For GitLab team members looking to prepare backports, refer to the [Patch release information dashboard](#patch-release-information-dashboard).

Check if the related confidential security issue has the label `~"security-fix-in-public"`. This label means that the security issue is [already accepted](/handbook/security/product-security/security-platforms-architecture/application-security/vulnerability-management/#fixing-in-public) to be addressed in public, so it is ok to have this MR in public. If it does not, escalate to SIRT via `/security` in Slack to have the MR and branch removed. Automation may already have flagged the MR and posted an internal note asking you to do this — the action is the same.

## Who can I contact if my Stable Counterpart is out of office?

In GitLab, @ mention `@gitlab-com/gl-security/product-security/appsec` and the AppSec engineer on rotation will respond. In Slack, reach out on `#security_help`.

When you intentionally create a public MR that is a dependency-only fix for an already-public vulnerability, make this clear in the MR description and include a link to the public advisory, following the guidance in [Dependency version bumps](/handbook/security/product-security/security-platforms-architecture/application-security/vulnerability-management#dependency-version-bumps). This helps AppSec when the MR is picked up by our monitoring.

## I ran a scan on 3rd party images used by GitLab and found vulnerabilities on them. Can they be updated?

GitLab products that follow an independent release cycle and are not aligned with the monthly GitLab security release are also required to have a process for developing security fixes and disclosing them to the customers. Either the [GitLab patch release process](https://gitlab.com/gitlab-org/release/docs/blob/master/general/security/engineer.md) or a recommended bare minimum process as below can be followed:

- Do not fix the security issue in public so that the vulnerability and the fix are not disclosed before it is ready to be publicly disclosed. Use a security mirror project under the private [Security group](https://gitlab.com/gitlab-org/security) for working on the security issue. In case the product is maintained in a private project then the fixes can be done directly in that project.

- Get the security fix reviewed by Appsec team.

- By default, **do not fix the security issue in public** so that the vulnerability and the fix are not disclosed before it is ready to be publicly disclosed. Use a security mirror project under the private [Security group](https://gitlab.com/gitlab-org/security) for working on the security issue. In case the product is maintained in a private project then the fixes can be done directly in that project.

- Get the security fix reviewed by the AppSec team.

- Request the Appsec team create a CVE request for the fixed vulnerability if the product is released to customers for their own installation.

- [Notify customers](#notifying-gitlab-users) about security fixes.

- Disclose the security issue following the [disclosure policy](https://about.gitlab.com/security/disclosure/#vulnerability-disclosure).

An explicit exception for certain **dependency-only version bumps that incorporate already-public security fixes** is documented in the [Fixing In Public](#fixing-in-public) section below.

#### Fixing In Public

The Application Security Team may give approval for a security issue to be addressed in public, either wholly or in part. Public issues and MRs must never include information that should remain confidential. Also, backports are not required for security issues fixed in public. Application Security engineers should:

- Second, consider creating a [public linked issue](https://docs.gitlab.com/ee/user/project/issues/related_issues.html) for specific work items.

- Finally, if the issue must remain confidential and creating additional issues is not desired then update the issue with a clear implementation proposal on what can be done in public and what must remain confidential, and add the `~"security-fix-in-public"` label.

The `~"security-fix-in-public"` label is applied only to the corresponding security issue (typically confidential) and must be added or removed exclusively by AppSec engineers. Other team members must not add or remove this label or use it directly on merge requests.

The security team monitors for unintended information disclosure via public MRs referencing confidential issues and will delete public branches and MRs that do not follow this process.

##### Dependency Version Bumps

When a vulnerability is fixed solely by bumping a dependency to a version that **already has a public CVE or vendor advisory**, the fix can be made directly in the canonical repository instead of the security mirror. This reduces overhead and gets the fix to users faster. The MR must not include information that should remain confidential, and its description must clearly state that it is an intentional public dependency update, including a link to the public advisory. When an AppSec engineer reviews the associated security issue as part of our monitoring, the `~"security-fix-in-public"` label should be used to record that this dependency bump is intentionally being handled in public.

### Notifying GitLab Users

Fixed vulnerabilities are mentioned in the [security release blog posts](https://about.gitlab.com/releases/categories/releases/) and it's possible to [receive notifications](/handbook/security/#receive-notification-of-security-releases) either through email or RSS.