Labels

Issues relating to api/webhook inconsistencies

Issues related to additional coverage in the GitLab API

Issues related to the Merge Request approvals feature: http://doc.gitlab.com/ee/workflow/merge_request_approvals.html

A label applied to Merge Requests that were later identified as having introduced a vulnerability during a security release. This label is used for tracking review coverage metrics and should be applied retroactively to the original Merge Request when a vulnerability is discovered. The purpose of this label is to help measure the Application Security team's effectiveness in preventing vulnerabilities through code review by tracking which vulnerability-introducing changes went through security review gitlab-com/content-sites/handbook!11439

A label applied to Merge Requests in which a vulnerability was identified and prevented going into production if it was fixed before being merged. This label is used for tracking review coverage metrics. The purpose of this label is to help measure the Application Security team's effectiveness in identified vulnerabilities through code review.

This label is applied by an AppSec team member when all findings from AppSec's SAST rules have been reviewed. See https://gitlab.com/gitlab-com/gl-security/appsec/sast-custom-rules

This label is applied automatically when AppSec's SAST rules are flagged on a merge request. See https://gitlab.com/gitlab-com/gl-security/product-security/appsec/sast-custom-rules

Added when automation has detected a SAST violation of GitLab's AppSec team's rules. See https://gitlab.com/gitlab-com/gl-security/product-security/appsec/sast-custom-rules

Add this label when AppSec's SAST rules were helpful, informative, and/or not unhelpful. See https://gitlab.com/gitlab-com/gl-security/product-security/appsec/sast-custom-rules

Apply this label if AppSec's SAST rules were unhelpful and/or incorrect. See https://gitlab.com/gitlab-com/gl-security/product-security/appsec/sast-custom-rules

Denotes issues used for the security release process retrospective in the Application Security team

Label to organize all issues related to Atlassian Integration

Actions which can permanently affect the state of an instance, group, project or data are key events that we want to maintain a log of, since they generally cannot be undone.

Because the data in an instance is very sensitive, we will record logs of actions that are used to copy, mirror, or export that data.

Events likely to generate a high volume of data that could affect performance. This type of event could be served in Webhook-based audit events.

Tokens such as Personal Access Tokens can give anyone who holds them the permissions the token has. Steps done with these tokens will be logged in case a token falls into inappropriate hands and the changes made with it need to be undone.