Product Security Engineering

Mission Statement

The Product Security Engineering (ProdSecEng) team’s mission is to create proactive and preventative controls which will scale with the organization and result in improved product security. We build “paved roads” through product-first code contributions and automation that enables secure software development while maintaining Engineering’s velocity.

Value Proposition

We provide hands-on engineering expertise, scalable automation solutions, and product contributions to enable the Product Security (ProdSec) department to focus on high-value security initiatives than manual work, and GitLab’s product teams can rapidly deliver security capabilities that solve real customer problems.

FY27 Primary Focus Areas

Bottom line up front: In order to make progress on this mission, the ProdSecEng team’s FY27 key focus areas are:

• Vulnerability management product features and automation
• Active maintenance, sunsetting, and integration of tools into the product

Scope and Responsibilities

Primary Areas of Ownership

ProdSecEng owns the management and delivery of security engineering work across the following areas:

1. Security Enhancement Features: We design and develop security features and improvements that reduce GitLab’s product risk and enhance the product’s security capabilities for customers.
2. ProdSec Automation: We collaborate with other ProdSec teams on automation opportunities that reduce their manual burden and improve security capabilities and efficiency.
3. “Paved Roads” for Security: We create product-first solutions and standards that make it easy for development teams to implement security best practices without friction.
4. ProdSec Tooling Integration: We identify custom ProdSec tooling that should be integrated into GitLab and manage the implementation, rollout, and handover to appropriate product teams.
5. Security Requirements Implementation: We work with the teams in the wider Security Division to translate their security requirements and use cases into product features and capabilities.
6. Proof of Concepts and Validation: We develop proofs-of-concept and validate that proposed security solutions meet real-world needs before broader implementation or team handoff.
7. Maintainers of existing ProdSec tooling: We maintain multiple projects and custom tooling on behalf of the Security Division (the full list is confidential and available to GitLab Team Members only). This is our primary source of candidates for GitLab product integration.
8. Documentation and Knowledge Transfer: We create and maintain documentation, runbooks, and guides that enable other teams to understand and leverage our contributions.

Interface Points

ProdSecEng sources work from several key areas and interfaces with teams that provide input to our backlog:

• ProdSec Automation Requests:

  • ProdSec teams identify automation candidates that would reduce manual security work burden.
  • We evaluate requests against our automation request template criteria and integrate high-impact items into our backlog.
  • What this interface looks like: Regular engagement to identify priorities, review completed automation, and discuss opportunities.

• Existing GitLab Security Enhancement Issues:

  • This includes issues within the custom tooling projects we maintain, or security-related issues across GitLab projects that require security engineering.
  • We assess fit against our mission and capacity, then either commit to the work or identify the appropriate owning team.
  • What this interface looks like: Issues are labeled as ~ProdSecEng Candidate for our evaluation. Issues may be initiated by any team or team member. We triage and prioritize async through issue discussions.

• Cross-functional Security Requests:

  • Other security teams (Vulnerability Management, Security Compliance, Security Risk, Trust & Safety, SIRT) may identify product or automation needs.
  • We evaluate these requests and integrate high-impact items into our backlog.
  • What this interface looks like: The ProdSecEng team is mentioned in issues or work items, or async discussion in shared channels.

• Product Security Risk Register (PSRR):

  • Security Platforms & Architecture (SPA) and the other ProdSec teams identify systemic risks in the PSRR that require product engineering solutions.
  • We translate these risks into product features, tooling integrations, or automation that mitigates identified risks.
  • What this interface looks like: Regular alignment with SPA on PSRR priorities, and ongoing collaboration on risk mitigation strategies.

• Security Interlock and Product Validation:

  • ProdSec teams validate that new and existing GitLab security features meet real-world use cases through Customer Zero initiatives.
  • What this interface looks like: Participation in Security Interlock epics and feedback collection from ProdSec teams.

Out of Scope

Below are areas outside of ProdSecEng’s scope (and the DRI you can refer to instead):

• Application security standards, reviews, or testing [DRI: AppSec]
• Infrastructure, cloud, or data security tooling or architecture [DRI: InfraSec]
• Vulnerability management operations [DRI: VulnMgmt]
• Vulnerability disclosure, disclosure, and triage [DRI: PSIRT]

Communication Channels

To reach ProdSecEng, you can go to:

• Ask in #security_help on Slack and @ mention the @product-security-engineering handle
• Mention @gitlab-com/gl-security/product-security/product-security-engineering on GitLab
• Submit an issue in the Product Security Engineering Team repository

In the event of an emergency, GitLab Team Members should page the Security Incident Response Team in any channel using the command /security

For internal team communications, our team has a private channel that we use: #prod-sec-eng-team-internal

ProdSecEng for short

For efficiency, we often refer to our team as ProdSecEng and avoid using the PSE acronym as it causes confusion with the Professional Services Engineer role.

Operating Model

ProdSecEng operates through a lightweight, iterative development process that emphasizes collaboration, clear ownership, and rapid delivery of security solutions. The following describes our core processes and how teams engage with us.

High-level Processes and Workflows

• Backlog Management: Issues are identified as ~ProdSecEng Candidate and triaged by the team to prioritize high-impact work.
• Refinement and Planning: Each milestone, team members perform ongoing refinement on candidate issues to ensure clarity, design, and readiness for development. The Security Engineering Manager is the DRI for prioritization decisions.
• Development: Team members follow a lightweight development process with workflow labels (~workflow::validation backlog, ~workflow::ready for development, ~workflow::in dev, ~workflow::in review, ~workflow::complete). Each issue has a defined weight and acceptance criteria.
• Handoff and Ownership: When work is complete, we transition ownership to the appropriate product team, providing documentation and support needed for long-term maintenance.
• Tooling Integration: For custom ProdSec tooling, we follow a structured process: create integration epics, identify discrete functionality, develop solution architecture, coordinate with eventual owning teams, and establish sunsetting roadmaps.

For a more detailed breakdown of these processes, jump to Detailed Processes Workflows.

Engagement Models

• ProdSec Collaboration: Regular or as-needed synchronization to identify automation candidates, review completed automation, and discuss current workload priorities.
• Product Team Coordination: Early engagement with product and engineering managers to align on proposed work, discuss existing initiatives, and establish clear ownership transitions.
• Cross-team Requests: We respond to requests from other security and company teams through the standard intake process, evaluating fit against our mission and capacity.
• Peer Review: Team members review each other’s merge requests to encourage collaboration, knowledge sharing, and maintain quality standards.

Operational Runbooks

For step-by-step procedures that ProdSecEng are responsible for, refer to our Please see our Runbooks page.

Success Metrics

ProdSecEng tracks metrics through labeled merge requests and issues. The following metric labels drive our tracking and reporting:

Metric Labels and Categories

Refer to our Tableau dashboard for metric data based on these labels.

Strategic KPI

Based off the metrics we collect, below are the strategic Key Performance Indicators (KPI) we track to tell how we are doing on our mission.

Operational Metrics

To track team efficiency, below are operational KPI we track.

Team Composition

Current Roles

The ProdSecEng team consists of:

• Security Engineering Manager: Leads team prioritization, roadmap planning, and milestone planning; manages cross-functional relationships
• Product Security Engineers: Design, develop, and validate security features, automation solutions, and tooling integrations

Development Goals

Our team is a mix of software and security engineers. Our plans for internal team growth and development are:

• Expand expertise in scalable security architecture and design patterns
• Develop hands-on experience with GitLab’s codebase and development practices
• Build capabilities in AI security integration and implementation
• Enhance product management skills to better translate security requirements into user-centric solutions
• Strengthen cross-team collaboration and communication skills

Review and Updates

This charter will be reviewed and updated quarterly to ensure alignment with company and divisional priorities, and the team’s actual way of working.

Next scheduled review: May 1, 2026

View page source - Edit this page - please contribute.