Security Incident Response Team - SIRT

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

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.

View page source - Edit this page - please contribute.