Application Security

Last updated: May 27, 2025

Application Security Mission

The Product Application Security subdepartment works with GitLab engineers and product teams to anticipate and prevent the introduction of vulnerabilities during design and development, ensuring delivery of high quality software GitLab customers can trust. We also identify, assess, and respond to security vulnerabilities discovered in GitLab products and services that are reported through Coordinated Vulnerability Disclosure practices.

Value Proposition

The Application Security subdepartment provides operational application of DevSecOps engineering and methodology, as well as data insights and security consultation that enables GitLab engineers to easily deliver high quality secure products and services to customers, while maintaining feature capabilities and velocity to market.

Scope & Responsibilities

We organize our work into five pillars that emphasize Developer UX in the context of traditional DevSecOps programs. We call this the Secure Developer eXperience, or SDX.

• SDX: Learn: security training, governance, policy, documentation, and standards.
• SDX: Design: threat modeling, feature design guidance and consultation, and design reviews.
• SDX: Code: static analysis, software component analysis and supply chain security, use of approved tools and methodologies in development, deprecation of unsafe functions, etc.
• SDX: Verify: dynamic analysis testing, penetration testing, remediation of critical vulnerabilities, and final security reviews prior to release.
• SDX: Maintain: establishment of an incident response plan, managing Coordinated Vulnerability Disclosure, bug bounty program administration, and critical product security incident response release and post-release operations.

The Application Security sub-department includes two teams, the Secure Design & Development Team and the Product Security Incident Response Team (PSIRT).

Shared Accountabilities & Collaborations

The Application Security team partners with several other teams across the Security Division to deliver end-to-end security solutions that work for GitLab engineers. The following strategic security programs have multiple stakeholders across the Security Division and company.

Supply Chain Security

Application Security’s accountability is shared by both SD&D and PSIRT. Additional Product Security teams involved in Supply Chain Security include Security Platforms & Architecture, Vulnerability Management, and Infrastructure Security.

Dogfooding

Application Security’s accountability is to use GitLab security products in our work and be participants in providing actionable Customer Zero feedback through the Security Platforms & Architecture team, who is the Dogfooding DRI for Product Security.

Vulnerability Management

The Application Security Team’s accountability is shared by both SD&D and PSIRT. The Vulnerability Management is DRI for Vuln Management tooling development and implementation.

Secure by design

The Secure Design and Development Team’s accountability is feature focused, assessing threats through Threat Modeling and feature design reviews. (SDX: Design). The Security Platforms & Architecture team is DRI for Threat Modeling strategy company-wide, while AppSec is a critical stakeholder in this strategy.

Security Response

The Product Security Incident Response Team’s accountability is to triage and technically assesses critical and exploitable vulnerabilities, determine company and customer risk, and coordinate external communications regarding these issues. PSIRT has several partners across the company including:

• Security Operations is DRI for Incident Command and Threat Detection (IOCs, TTPs)
• Security Research is a key partner on exploitability and POC development
• PR and Communications
• Legal
• Delivery
• Customer Support

Out of Scope

• SBOM production
• Container Scanning
• Customer Escalations regarding security scanner findings
• Security Compliance

Appliction Security Organization

Learn more how our team work is organized on this specific page. 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:

• Finding your Stable Counterpart on the Product sections, stages, groups, and categories page
• Mentioning @gitlab-com/gl-security/product-security/appsec on GitLab
• Submit an issue in the AppSec Team repository
• Asking in #sec-appsec or mentioning @appsec-team on Slack
• For cross team collaboration improvement opportunities, use this template for collaboration improvement opportunities

FY26 Primary Focus Areas

In FY26, our key focus areas are:

Organizational Upleveling:

• Establish Product Security Incident Response Team (PSIRT)
• Expand Security Design & Development team services at scale

Support Company and Division Priorities:

• Authorization & Authentication
• AI Security & Safety
• Supply Chain security
• Security Interlock

FY26 Metrics

Application Security is rebuilding our operational business health metrics in FY26. These metrics are in addition to Key Risk Indicators, project-level metrics, or sub-team specific metrics. For many of these, metrics instrumentation and reporting mechanisms are still forthcoming. As the team matures, these metrics will evolve and be shared on this page.

Useful resources for AppSec engineers

PTO

Team members that are taking PTO for 5 days or more must both discuss time off with their manager prior to scheduling to ensure visibility and adequate team operational coverage and create a PTO coverage issue to organize their coverage during their time off. The PTO coverage issue should:

• List any potential requests that could come to the team while on PTO
• The team member taking PTO should organize their work accordingly and ensure the PTO coverage issue contains the context required to handle the work
• Assign primary and secondary responsible team members

AppSec team members should add any important information related to the work they are covering for the person on PTO and AppSec manager(s) should add any important announcement to see upon their return.

Roles & Responsibilities

Please see the Application Security Job Family page.

Helpful Quicklinks

• The AppSec private group that contains other private subgroups and projects
• The appsec-lab group on Staging. This has an Ultimate license.
• Bug bounty council search
• Upcoming patch release
• GitLab Project Security dashboard
• Security issue board that tracks ongoing issues (hackerone and others)
• The latest releases
• Overview of a project member permissions
• The DevOps stages and their different groups. This page contains information on the development teams, their areas of focus, and their team members as well as the AppSec stable counterparts. It is used to assign issues to the stable counterparts.
• The product features listed by groups that own them
• List of merged security issues in gitlab-org. Note: It can include results from the security mirror gitlab-org/security/.
• Application Security KPIs & Other Metrics, including Embedded KPIs which can be filtered by section, stage, or group, please see this page.

The list above is not exhaustive and is subject to be modified as our processes keep evolving.

Stable Counterparts

Please see the Application Security Stable Counterparts page.

Application Security Reviews

Please see the Application Security Reviews page.

RCAs for Critical Vulnerabilities

Please see the Root Cause Analysis for Critical Vulnerabilities page

Application Security Engineer Runbooks

Please see the Application Security Engineer Runbooks page index

Meeting Recordings

The following recordings are available internally only:

• AppSec Sync
• AppSec Leadership Weekly

Backlog reviews

When necessary a backlog review can be initiated, please see the Vulnerability Management Page for more details.

GitLab Secure Tools coverage

As part of our dogfooding effort, the Secure Tools are set up on many different GitLab projects (see our policies). This list is too dynamic to be included in this page, and is now maintained in the GitLab AppSec Inventory.

Projects without the expected configurations can be found in the inventory violations list (internal link).

GitLab Inventory

Learn more about the GitLab AppSec Inventory.

Responding to customer scan review requests

Please see the Responding to customers security scanners review requests page.

Reproducible Vulnerabilities

Learn how to identify or remediate security issues using real examples with GitLab’s Reproducible Vulnerabilities.

Reproducible Builds

Learn how GitLab is implementing Reproducible Builds for our build processes.

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

Content Review and Updates

This charter will be reviewed quarterly to ensure alignment with company and divisional priorities, the GitLab Security product roadmap, and relevant business and operational changes. Updates may occur more frequently as business operations evolve.

Next scheduled review: June 30, 2025

View page source - Edit this page - please contribute.