Security Incident Response Team - SIRT

GitLab Security Incident Response Team Overview

The Security Incident Response Team - SIRT is on the forefront of security events that impact both GitLab.com and GitLab the company.

Our Vision

To detect security incidents before they happen and to respond promptly when they do happen.

Our Mission Statement

Ensure maximum operational uptime of mission critical infrastructure and informational assets in its daily operations. This mission is achieved by providing effective crisis response, timely distribution of security notifications, continuous monitoring of potential issues, postmortem of major incidents for training and environmental awareness.

The Team

Team Members

The following people are permanent members of the SIRT

Person Role
Joaquin Fuentes Director, Security Operations
Valentine Mairet Security Manager, SIRT
Matt Coons Security Manager, SIRT
Shrishti Choudhary Security Manager, SIRT
Mitra Jozenazemian Staff Security Engineer, SIRT
Harjeet Sharma Staff Security Engineer, SIRT
Janina Roppelt Senior Security Engineer, SIRT
Laurens Van Dijk Senior Security Engineer, SIRT
Chathura Kuruwita Senior Security Engineer, SIRT
Sean Gillespie Senior Security Engineer, SIRT
Bala Allam Security Engineer, SIRT
Leslie Anzures Security Engineer, SIRT
Ellis Coulson Security Engineer, SIRT

Services We Provide:

  1. Reactive - Services design to respond to active incident handling, including but not limited to
    • Incident analysis
    • Incident response support and coordination
    • Incident response resolution
    • Detection and response engineering
  2. Proactive - Services designed to improve the infrastructure and security processes of Gitlab before any incident occurs or is detected. The main goals are to avoid incidents and to reduce the impact and scope when they do occur.
    • Cyber Threat Analysis of vulnerability warnings and security advisories
    • Monitor Adversaries’ activities and related trends to help identify future threats
    • Configuration and maintenance of security tools, applications, and infrastructure
    • Detection and response engineering
  3. Administrative - Services design to assist with requests from Gitlab’s Legal and HR Departments.

Engaging SIRT

The SIRT is on-call 24/7/365 to assist with any security incidents. If an urgent security incident has been identified or you suspect an incident may have occurred, please refer to Engaging the Security Engineer On-Call.

Information about SIRT responsibilities and incident ownership is available in the SIRT On-Call Guide.

Incident Management and Review

As part of the incident management and review process the SIRT maintains a recurring meeting that takes place on Monday of each week. During this meeting all of the previous weeks incidents, and any incidents that are currently open are reviewed. The review process covers the incident’s scope, impact, the work performed to mitigate and remediate the incident, next steps, blockers, and current status. These meetings are also an opportunity to discuss mishandled incidents and process improvements.

Limited Access

Information about security incidents or investigations is considered limited access and is not shared with all team members. After being resolved, a determination will be made as to whether or not the incident or investigation issue contains Materially Non-Public Information (MNPI). Only incidents or investigation issues that do not contain MNPI will be made visible to GitLab team members. More information about how this aligns with GitLab’s value of Transparency can be found on the Transparency by Default page. The workflow for this is:

graph TD
    A[Security incident occurs] --> |Incident reported| B[SIRT automation creates a private project]
    B -->C[SIRT automation creates issue in new project]
    C -->D[Reporter added to the issue/project]
    D -->E[Other team members are added as needed*]
    E -->|Incident is resolved| F[Determine whether or not the incident contains MNPI]
    F -->|no MNPI present| G[Make visible to GitLab team members]
    F -->|MNPI present| H[Keep confidential]

*A pre-defined list of team members are automatically added when the incident is ~severity::1.


Engaging the Security Engineer On-Call
How to Engage the Security Engineer On-Call
GitLab Security Incident Response Guide
This is a Controlled Document Inline with GitLab’s regulatory obligations, changes to controlled documents must be approved or merged by a code owner. All contributions are welcome and encouraged. Purpose The Security Incident Response Team (SIRT) is on-call 24/7/365 to assist with any security incidents. If an urgent security incident has been identified or you suspect an incident may have occurred, please refer to Engaging the Security Engineer On-Call.
Security Incident Classification
How we determine severity and priority within Security Incidents
Security incident communications plan
This is a Controlled Document Inline with GitLab’s regulatory obligations, changes to controlled documents must be approved or merged by a code owner. All contributions are welcome and encouraged. Purpose GitLab takes the security of our clients’ information extremely seriously, regardless of whether it’s on GitLab.com or in a self-managed instance. In keeping with GitLab’s value of transparency we believe in communicating about security incidents clearly and promptly. Scope This communication response plan maps out the who, what, when, and how of GitLab in notifying and engaging with internal stakeholders and external customers on security incidents.
Security Shadow: Security Operations
Completion of each course you will receive a certificate. At the completion of all 3 courses your name will be recognized on this page. Security Incident Response Team (SIRT) GitLab’s Security Incident Response Team is the first line of defense for the GitLab SaaS and GitLab as an organization. The primary goal of SIRT is to minimize and control damage from security incidents. This is accomplished through the development and deployment of detection tools to identify when a security incident has occurred, taking action to identify and contain the event to limit its scope and impact, remediating the underlying issue that led to the security event, and recovering from the security event so that operations can return to normal.
Last modified September 6, 2023: Replace taps with spaces (69f17a79)