Re-organize the metrics section and add an appsec organization section

- [Customer Escalations regarding security scanner findings](../application-security/responding-customers-scan-review-requests.md)

- [Security Compliance](../../../security/security-assurance/)

## Appliction Security Organization

Learn more how our team work is organized on [this specific page](appsec-organization.md). You will find how we plan our work and our main repositories used in our daily work.

## Contacting us

Team members can reach the AppSec team by:

Learn how GitLab is implementing [Reproducible Builds](/handbook/security/product-security/application-security/reproducible-builds/) for our build processes.

## Milestone Planning

The GitLab Application Security team plans work based around Milestones, see [this page for a description of that process](/handbook/security/product-security/application-security/milestone-planning/)

## Application Security Automation and Monitoring

Learn more about the automation initiatives that the Application Security team uses on the [Application Security Automation and Monitoring page](/handbook/security/product-security/application-security/application-security-automation-monitoring/)

---

title: "Application Security Team Organization"

description: Application Security page on how the team is organized

---

This page provides you with the resources:

- To understand how the work of the team is organised

- To know in which repositories we are performing our work

## Work Organization

The Application Security team organizes the work on a monthly milestone basis. To know more how we do it, please consult our specific milestone planning page [here](milestone-planning.md)

## Important Repositories

The Application Security team maintains several key repositories that support [our mission](_index.md#application-security-mission). These repositories enable collaboration with Engineering and Product teams while maintaining our security standards and processes.

### Team organization and planning

**Purpose**: Central repository for team operations, issue tracking, and cross-team collaboration  

**Location**: [appsec-team tracker](https://gitlab.com/gitlab-com/gl-security/product-security/appsec/appsec-team)  

**Key Uses**:

- Track team initiatives and operational improvements

- Coordinate cross-team collaboration efforts

- Plan milestone work

### Application Security reviews

**Purpose**: Repository to request and perform AppSec reviews  

**Location**: [appsec-team reviews](https://gitlab.com/gitlab-com/gl-security/product-security/appsec/appsec-reviews/)  

**Key Uses**:

- Feature design reviews

- Architecture assessments

Learn more about our security review process in our [dedicated page](appsec-reviews.md)).

### Security Tools & Automation

**Purpose**: Houses our automation tooling  

**Location**: [Tooling repository](https://gitlab.com/gitlab-com/gl-security/product-security/appsec/tooling)  

**Key Uses**:

- Automation scripts

### Threat Modeling Resources

**Purpose**: Templates and documentation for threat modeling activities  

**Location**: [Threat modeling repository](https://gitlab.com/gitlab-com/gl-security/product-security/appsec/threat-models)  

**Learn More**: [Threat Modeling Process](./threat-modeling/)

### PSIRT Operations

**Purpose**: Central repository for PSIRT team operations and issue tracking.  

**Location**: `gitlab-com/gl-security/product-security/appsec/psirt`  

**Learn More**: [PSIRT Services](./appsec-operations/psirt-services/)

## Useful Information For External Customers

### Public Security Resources

- [GitLab Security Disclosure](https://about.gitlab.com/security/disclosure/)

  - Details our coordinated security disclosure policy and process

- [HackerOne Bug Bounty Program](https://hackerone.com/gitlab)

  - Our Bug Bounty HackerOne program policy

- [GitLab Release and Patch Releases Process](/handbook/engineering/releases/)

  - Consult our Handbook page dedicated to our Release and Patch Release Process

### Documentation

- [How to Secure our Application Using GitLab Application Security Features](https://docs.gitlab.com/ee/user/application_security/secure_your_application.html)

- GitLab Instance Hardening Recommendations:

  - Our [official documentation](https://docs.gitlab.com/security/hardening/) (shipped with each version and available in self-managed instance documentation)

  - Our [Handbook recommendations](https://about.gitlab.com/security/hardening/)

The AppSec Engineer responsible for the task is expected to assign this label to an issue when work on the issue is started or completed.

## Key Performance Indicators

These metrics track our team's capacity to handle critical security workloads.

### Merge Request Review Coverage Rate

This KPI tracks our ability to review security-relevant merge requests that introduced a vulnerability, with or without prior security review. It is tracked through a security review miss rate that we target to get as close to 0% as possible, as that would mean that any merge request that was reviewed by the application security team did not end up introducing a vulnerability.

#### How It's Measured

1. __Merge Request Classification Requirements__

   - `AppSecWorkType::VulnFixVerification` must be applied to security fix verification Merge Requests

   - `AppSecWorkType::SecurityMRReview` must be applied to all other security code reviews, including those performed during triage rotation or as part of the stable counter part MR review.

2. __Vulnerability Source Tracking__

   - Apply `appsec-kpi::vulnerability-introduced` label to Merge Requests identified as introducing vulnerabilities

#### Calculation Method

```text

`Security Review Miss Rate` = (Merged Vulnerability-introducing Merge Requests with Application Security review / Total vulnerability-introducing Merge Requests) * 100

```

Where:

- Total vulnerability-introducing Merge Requests = Merge Requests labeled with `appsec-kpi::vulnerability-introduced`

- Vulnerability-introducing Merge Requests _without_ Application Security review = `appsec-kpi::vulnerability-introduced` Merge Requests lacking both `AppSecWorkType::SecurityMRReview` or `AppSecWorkType::VulnFixVerification`

- Merged Vulnerability-introducing Merge Requests with Application Security review = `appsec-kpi::vulnerability-introduced` Merge Requests with either `AppSecWorkType::SecurityMRReview` or `AppSecWorkType::VulnFixVerification`

## FAQ

### What labels should I add to have my work considered in the capacity metrics?

---

title: "Application Security - Capacity Indicators, Classifications, and Workflows"

---

## Key Performance Indicators

These metrics track our team's capacity to handle critical security workloads.

### Merge Request Review Coverage Rate

This KPI tracks our ability to review security-relevant merge requests that introduced a vulnerability, with or without prior security review. It is tracked through a security review miss rate that we target to get as close to 0% as possible, as that would mean that any merge request that was reviewed by the application security team did not end up introducing a vulnerability.

#### What I Need To Do To Have This KPI Measured?

1. __Merge Request Classification Requirements__

   - `AppSecWorkType::VulnFixVerification` must be applied to security fix verification Merge Requests

   - `AppSecWorkType::SecurityMRReview` must be applied to all other security code reviews, including those performed during triage rotation or as part of the stable counter part MR review.

Those two labels are applied as part of our capacity metrics and our day-to-day operation. You can find more details on the [capacity metric dedicated page](capacity.md) on the [Type of Work Classification](capacity.md#type-of-work-classification). To understand how we work and how we are applying those labels, you can consult our dedicated page about [Milestone Planning](../milestone-planning.md).

1. __Vulnerability Source Tracking__

   - Apply `appsec-kpi::vulnerability-introduced` label to Merge Requests identified as introducing vulnerabilities

1. __Vulnerability Prevention Tracking__

   - Apply `appsec-kpi::vulnerability-prevented` label to Merge Requests where vulnerabilities were identified and prevented during security review

#### Calculation Method

```text

`Security Review Miss Rate` = (Merged Vulnerability-introducing Merge Requests with Application Security review / Total vulnerability-introducing Merge Requests) * 100

```

Where:

- Total vulnerability-introducing Merge Requests = Merge Requests labeled with `appsec-kpi::vulnerability-introduced`

- Vulnerability-introducing Merge Requests _without_ Application Security review = `appsec-kpi::vulnerability-introduced` Merge Requests lacking both `AppSecWorkType::SecurityMRReview` or `AppSecWorkType::VulnFixVerification`

- Merged Vulnerability-introducing Merge Requests with Application Security review = `appsec-kpi::vulnerability-introduced` Merge Requests with either `AppSecWorkType::SecurityMRReview` or `AppSecWorkType::VulnFixVerification`