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 [Application Security Architecture](/handbook/security/product-security/security-platforms-architecture/security-architecture/) and [Security Research](/handbook/security/product-security/security-platforms-architecture/security-research/), we focus on systemic product security risks and work cross-functionally to mitigate them while maintaining Engineering's development velocity.
The Security Platforms and Architecture (SPA) sub-department protects GitLab's platform and products by identifying, prioritizing, and mitigating security risks across the entire product lifecycle. Composed of [Security Architecture](/handbook/security/product-security/security-platforms-architecture/security-architecture/), Application Security(/handbook/security/product-security/application-security/), and [Security Research](/handbook/security/product-security/security-platforms-architecture/security-research/), we combine strategic security architecture with operational application security to enable GitLab to be the most secure software factory platform on the market. We work with GitLab engineers and product teams to anticipate and prevent vulnerabilities during design and development, and ensure delivery of high-quality software GitLab customers can trust. We focus on systemic product security risks and operational application security, working 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.
We provide security expertise and operational support throughout the software development lifecycle so that GitLab and our customers can create quality, secure software with high velocity. Our teams translate 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](/handbook/security/product-security/security-platforms-architecture/risk-register/) 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](/handbook/security/product-security/security-platforms-architecture/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.
-**Application-layer Architecture Consultations and Review**: Proactively consult on and conduct security architecture reviews for large, complex, strategic, and high-impact projects, specifically at the application-layer
-**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.
| **Area** | **Description** | **Primary Team** |
| ------- | ------- | ------- |
| **Security Reviews** | Feature-level security reviews, final security reviews prior to release, ongoing design guidance | Application Security |
| **Security Architecture Reviews** | High-level architecture reviews, design reviews for large/complex/strategic initiatives requested by AI, Sec Section, or Core DevOps functional leadership | Security Architecture |
| **Security Research** | Proactive identification of unknown security risks and vulnerabilities in the GitLab ecosystem | Security Research |
| **[Security Interlock](/handbook/security/product-security/security-platforms-architecture/security-interlock/)** | Cross-divisional Customer Zero efforts and dogfooding coordination | Security Architecture |
| **Security Visions and Standards** | Development and communication of security visions and standards to proactively enable teams to make sound security decisions and establish clear expectations for secure software delivery. | Security Architecture and AppSec |
| **Product Security Metrics** | Design and implementation of metrics collection systems | Security Architecture |
| **Direct Product Contributions** | Security feature development, POCs, and engineering contributions to the GitLab product | All SPA Teams |
| **Thought Leadership** | Blog posts, conference talks, or other public and internal thought leadership contributions that establish GitLab as a leader and trusted enabler for secure software development | All SPA Teams |
### 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](/handbook/security/security-assurance/security-risk/), who owns and operates the broader [Risk Register](/handbook/security/security-assurance/security-risk/storm-program/).
- We partner with InfraSec when initiatives require both application-layer and infrastructure inputs
-**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]
- Vulnerability impact analysis and POC development [Requestor: Vuln Management]
-[Technical Security Validation](/handbook/security/security-assurance/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.
@@ -48,56 +49,54 @@ We provide proactive risk assessments, architectural security solutions and stan
### Out of Scope
- Non-escalated security design reviews of moderate or low-impact features [DRI: AppSec]
- Security Architecture related to infrastructure/cloud/data security [DRI: InfraSec]
- Vulnerability Management Operations [Team: [Vulnerability Management](/handbook/security/product-security/vulnerability-management/) and [Security Compliance](/handbook/security/security-assurance/security-compliance/)]
- Incident Response Management [Team: [SecOps](/handbook/security/security-operations/) and /handbook/security/product-security/psirt/]
## 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-research` and`@gitlab-com/gl-security/product-security/security-architecture`
- Slack: Use #security_help or #security_discuss and tag `@security-platforms-architecture` or `@appsec-team`
- GitLab Tags for Issue/MR discussion: `@gitlab-com/gl-security/security-research`,`@gitlab-com/gl-security/product-security/security-architecture`, or `@gitlab-com/gl-security/product-security/appsec`
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
## FY27 Primary Focus Areas
In FY26, our key focus areas are:
- Merge Security Architecture, Application Security, and Security Research into one team
- Deliver operational excellence for security reviews of new features
- Implement scaling investments to maximize security coverage and support and reduce risk
- Key Risk Areas: AI Security, Software Supply Chain Security, and AuthN/Z
- Software Supply Chain and Ecosystem Security
- Authorization and Authentication
- AI Security
## FY27 Metrics
## 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.
SPA maintains metrics at many levels. The following are SPA-level strategic and operational metrics we intend to build and report on in FY27. 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.
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.
The following are key metrics we will start tracking in FY27 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.
| **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](https://gitlab.com/gitlab-com/gl-security/security-assurance/security-risk-team/storm-risk-register/-/issues/?sort=created_date&state=opened&label_name%5B%5D=Department%3A%3AProduct%20Security&first_page_size=20)(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. |
| **Security Review Coverage** | Validates delivery of our team's primary value stream by confirming features requing security review receive appropriate coverage | TBD | 90%+ | Quarterly | End-of-Quarter Readout Issue | |
| **Security Findings Incorporation Rate** | Measures whether our team's work (vulns from Research, findings from security reviews, etc.) is being prioritized and incorporated into the product | TBD | 75% | Quarterly | End-of-Quarter Readout Issue | |
| **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](https://gitlab.com/groups/gitlab-com/gl-security/-/epics/350)(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](https://gitlab.com/gitlab-com/gl-security/product-security/product-security-meta/-/issues/142)(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 | |
| **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 | 2+/Quarter | 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](https://gitlab.com/groups/gitlab-org/-/merge_requests/?sort=created_date&state=merged&label_name%5B%5D=ProdSec-SPA-Contribution) | 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. |
| **PSRR Operational Metrics:** | These metrics provide comprehensive visibility into our Product Security Risk Register's contents, hot spots, and priority | Issue Counts with PSRR Labels | 1 Risk per functional leader prioritized each quarter | Quarterly | [Internal Dashboard](https://10az.online.tableau.com/#/site/gitlab/views/ProductSecurityRiskRegister/Dashboard?:iid=1) | |
| **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](https://gitlab.com/gitlab-com/gl-security/security-research/sec-research/-/issues/250#note_2245509822)) | 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](https://gitlab.com/gitlab-com/gl-security/product-security/product-security-meta/-/issues/166) | 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.
