Product Security Engineering
The Product Security Engineering team's mission is to create proactive and preventative controls which will scale with the organization and result in improved product security.
Security Platforms & Architecture
Security Platforms & Architecture Team Charter
Last Updated: October 3, 2025
Mission Statement
The Security Platforms and Architecture (SPA) team addresses complex security challenges facing GitLab and its customers to enable GitLab to be the most secure software factory platform on the market. Composed of Security Architecture and Security Research, we focus on systemic product security risks and work cross-functionally to mitigate them while maintaining Engineering’s development velocity.
Value Proposition
We provide proactive risk assessments, architectural security solutions and standards, product security expertise and guidance, and direct product contributions so that GitLab and our customers can create quality, secure software with high velocity. Our team translates security expertise into public and internal thought leadership contributions that establish GitLab as a leader and trusted enabler for secure software development.
Scope and Responsibilities
Primary Areas of Ownership
- Product Security Risk Register: SPA is the DRI for organizing and presenting risks in the PSRR and facilitating its operational cadences. We also lead comprehensive risk identification, assessment, and prioritization efforts and work cross-organizationally to create the strategies, roadmaps, and standards required to enhance GitLab’s security posture, protect our customers, and address complex security challenges at scale.
- Security Research: We assess the GitLab ecosystem to identify previously unknown security risks and vulnerabilities.
- Direct Product Contributions: We contribute directly to the product’s evolution by Designing secure architecture solutions and executing proofs-of-concept that accelerate engineering teams’ delivery of security improvements.
- Security Interlock: SPA is the DRI for coordinating cross-divisional Customer 0 efforts of new features and internal dogfooding of existing features that align to risk reduction, ensuring the platform’s security capabilities meet real-world security use cases.
- Architecture Consultations and Review: Proactively consult on and conduct security architecture reviews for large, complex, strategic, and high-impact projects.
- Security Visions and Standards: We develop and communicate security visions and standards to proactively enable teams to make sound security decisions and establish clear expectations for secure software delivery.
- Product Security Metrics: We design, implement metrics collection systems, and regularly present metrics that accurately measure both strategic and operational effectiveness across ProdSec teams.
- Thought Leadership: SPA translates our security expertise into public and internal thought leadership contributions that establish GitLab as a leader and trusted enabler for secure software development.
- Peer Team Support: SPA supports our peer teams across the organization and enables them to accomplish their security goals by providing automation, informal training, documentation, and mentorship.
Interface Points
- Product Security Risk Register:
- All Product Security teams contribute to the creation, updating, and treatment of risks in the PSRR.
- We collaborate with the Security Risk Team, who owns and operates the broader Risk Register.
- Security Interlock:
- All Product Security teams contribute real-world testing of GitLab features and provide feedback to improve product usability, functionality, and effectiveness.
- SPA consolidates and delivers structured feedback to Security Product Managers and Engineering teams to drive feature enhancements that address actual security team workflows and requirements.
- Security Team Escalations: We respond to requests for support in areas including -
- Vulnerability impact analysis and POC development [Requestor: AppSec]
- Security reviews requiring additional expertise [Requestor: AppSec or InfraSec]
- Common themes and pain points requiring product capability development, automation work, custom tooling, or standards [Requestor: AppSec or InfraSec]
- Technical Security Validation of high-risk systems used by GitLab [Requestor: Security Risk]
- Product/Engineering Collaboration:
- SPA influences GitLab’s security and compliance roadmap, recognizing we are a canary for external enterprise-grade customer needs.
- Compliance Framework Implementation and Operations: SPA partners with Security Compliance and Engineering Teams on the roadmap to obtain and maintain certifications to customer-required security frameworks.
- Field Security: SPA supports and leverages Field Security to communicate security guidance and build customer trust.
Out of Scope
- Non-escalated security design reviews of moderate or low-impact features [DRI: AppSec]
- Routine vendor third-party risk assessments [DRI: Security Risk]
- External Penetration Testing Coordination [DRI: AppSec]
- Vulnerability Management Operations [DRI: Vulnerability Management, AppSec, and Security Compliance]
Communication Channels
Routine communications with the SPA team happen through the following:
- Slack: Use #security_help or #security-discuss and/or tag
@security-platforms-architecture - GitLab Tags for Issue/MR discussion:
@gitlab-com/gl-security/security-researchand@gitlab-com/gl-security/product-security/security-architecture
In the event of an emergency, GitLab Team Members should page the Security Incident Response Team in any channel using the command /security.
FY26 Primary Focus Areas
In FY26, our key focus areas are:
- Software Supply Chain and Ecosystem Security
- Authorization and Authentication
- AI Security
FY26 Metrics
SPA maintains metrics at many levels. The following are SPA-level strategic and operational metrics we intend to build and report on 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. The SPA team launched in FY26Q1. As the team matures, these metrics will evolve.
Note: These tables require horizontal scrolling to see completely.
Strategic Metrics
The following are key metrics we will start tracking in FY26 to measure the SPA team’s success delivering upon our charter, with E-Group as our intended audience. These reflect the reality that our ultimate success lies not in our individual activity, but requires working across teams and driving results that directly benefit our customers.
| FY26 Key Metric | Why It Matters | How it’s Calculated | Target Thresholds | Measurement Frequency | Reporting Mechanism | Additional Notes |
|---|---|---|---|---|---|---|
| Product Security Risk Mitigations Completed | This metric demonstrates our effectiveness at driving cross-organizational solutions to systemic security risks that could impact GitLab’s platform and customers | The count of merged MRs linked to risks in the Product Security Risk Register (Internal) | Baseline Required | Monthly | Monthly Product Security Risk Register Report (to be established) | This Monthly Product Security Risk Register Report will also detail other PSRR operational metrics like number of new risks documented, reviewed, assigned, prioritized, remediated, mitigated to an acceptable level, and closed. However, for purposes of executive-level metrics, we will focus on mitigations. After we have initial data, we will consider weighting these MRs, perhaps along risk severity levels. |
| Customer Zero Feedback Delivered | This metric tracks our effectiveness at partnering with product teams to validate that new security features meet real-world requirements and deliver value before they reach our customers | Manual count of C0 Issues completed and their outcomes | Baseline Required | End of Milestone | FY26 Security Interlock Epic Comments (internal) | This metric is dependent upon submissions from Product and Engineering |
| Percentage of product-applicable security processes effectively supported by GitLab features | This metric measures our success in enabling Product Security teams to effectively secure GitLab using our own product features, demonstrating their real-world value for enterprise security teams and validating GitLab’s All-in-One DevSecOps narrative | TBD (Internal) | Baseline Required | TBD | TBD | The designation of ‘product-applicable’ accounts for the possible existence of GitLab-specific security processes that lack utility for GitLab customers. We will evaluate these as they are identified. |
| Thought Leadership Contributions | This metric tracks our active efforts to position GitLab as a security thought leader, influencing both internal practices and the industry | Count of public blog posts, conference talks, interviews, or other public works | Baseline Required | Quarterly | End-of-Quarter Readout Issue | |
| Direct Security Feature Contributions | This metric tracks our team’s delivery of security features and improvements that enhance our security posture, reduce platform risk, and enable GitLab and its customers to create secure software | The count of merged MRs by SPA with the label “ProdSec-SPA-Contribution” applied | Baseline Required | Quarterly | End-of-Quarter Readout Issue | This likely needs to mature and take into account MR weight/complexity. We will iterate over time after we start tracking. |
Operational Metrics
| FY26 Key Metric | Why It Matters | How it’s Calculated | Target Thresholds | Measurement Frequency | Reporting Mechanism | Additional Notes |
|---|---|---|---|---|---|---|
| Security Research Identified Vulnerabilities | This metric tracks our Security Research Team’s effectiveness at proactively identifying vulnerabilities before they can impact GitLab or our customers | Count of bug::vulnerability identified by Security Research over time, weighted by severity (sample GLQL) | Baseline Required | Quarterly | End-of-Quarter Readout Issue | |
| PSRR Operational Metrics: Number of new well-articulated risks documented, reviewed, assigned, prioritized, remediated, mitigated to an acceptable level, and closed | These metrics provide comprehensive visibility into our Product Security Risk Register’s effectiveness at identifying, processing, and resolving security risks throughout their lifecycle. | TBD | Baseline Required (See Notes) | Monthly | Monthly Product Security Risk Register Report (to be established) | Early in FY26, we expect to see the number of newly documented risks rise and exceed the number of those prioritized, addressed, and closed. After this initial influx, we should see more balance among these metrics. |
Review and Updates
This charter will be updated quarterly to ensure alignment with company and divisional priorities, the GitLab Security product roadmap, and critical risks in the StORM and Product Security Risk Registers.
Next scheduled review: January 30, 2026
Product Security Risk Register
The Product Security Risk Register (PSRR) is driven by and follows the StORM process from our Security Risk Team.
Security Architecture
Security Architects are the trusted security advisors of GitLab Engineering.
Security Interlock
The Security Interlock Initiative is a cross-functional partnership across the Security, Engineering, and Product divisions that drives GitLab to effectively support real-world security use cases and deliver the best DevSecOps platform on the market.
Security Research
The Security Research team contributes to the Security Vision and Mission through projects that focus on identifying, quantifying, and developing solutions for complex security risks facing GitLab and its users.
Last modified October 14, 2025: Remove trailing spaces (
3643eb9e)
