Track Security Requirements on different projects

Any activity (Issues, Epics, MRs) in the Developer Advocacy teams radar.

AppSec work not covered by other AppSecWorkType labels

General administrative work on the Red Team (handbook updates, metrics, meetings, etc).

Indicates the work was associated to the AppSec Security release task issue duties

Indicates the work was associated to a customer escalating a security issue

Indicates the work was associated to a SIRT incidents and/or Security communications work

Indicates the work was associated to our tools and automation

Indicates the work was associated to cross-team help/collaboration

Indicates the work was associated to HackerOne administration

The work type isn’t entirely clear yet, but we don’t want to block progress for now.

Functionality required by GitLab Product Security teams.

A new tool, method, class, check that, gives GitLab’s contributors an easier way to perform an activity securely.

An MR that modifies existing non-vulnerable functionality to be more robust if an “earlier” security control fails.

Work done as part of the effort to integrate functionality from custom in-house tooling into a GitLab product.

Work performed to build, maintain, or augment outside-of-the-product custom tooling needed to satisfy Product Security requirements.

Localization matters specific to French (France)

Localization matters specific to Japanese