The purpose of this document is to establish a standardized framework for classifying security incidents based on their severity and priority. This classification system enables the Security Incident Response Team to respond appropriately to security incidents, allocate resources effectively, and ensure consistent communication about incidents across the organization.
The purpose of this document is to establish a standardized framework for classifying security incidents based on their severity. This classification system enables the Security Incident Response Team (SIRT) to respond appropriately, allocate resources effectively, and ensure consistent communication about incidents across the organization.
## Scope
This document applies to all security incidents affecting GitLab's infrastructure, services, applications, and data. SIRT will use the criteria defined in this document when assigning labels and will refer to the [SIRT Escalation Guide](/handbook/security/security-operations/secops-oncall/) for escalation procedures.
This document applies to all security incidents affecting GitLab's infrastructure, services, applications, and data. SIRT will use the criteria defined in this document when assessing incident severity and will refer to the [SIRT Escalation Guide](/handbook/security/security-operations/secops-oncall/) for escalation procedures.
## Roles & Responsibilities
@@ -25,28 +25,18 @@ This document applies to all security incidents affecting GitLab's infrastructur
## Procedure
### Priority
The priority label is used to indicate the importance and guide the response timing of the incident. Priority labels are expected to be set based on the circumstances of the incident, number of impacted users, and affected systems. Priority should be adjusted as the incident is worked and the conditions change.
| Immediate | A service which is critical for day-to-day operations is unavailable. The incident's sphere of impact is expanding rapidly, or quick action may make it possible to limit its scope. Time-sensitive work or customer actions are affected. The incident affects high-status individuals or organizations (i.e., upper management or major clients).<br><br>Unauthenticated RCE vulnerability on production instances. | Immediate response from SEOC is needed. <br><br>Work should continue in every region (follow-the-sun), with updates per shift in relevant channels. | \~priority::1 |
| High | The fact that an indicent is still ongoing influences the urgency score. Furthermore, if credentials were leaked in the process, we need to act sooner than possible.<br><br>A patched RCE vulnerability on production instances. | The issue can wait until next business day.<br><br>Work should continue in every assigned region, with daily updates in relevant channels. | \~priority::2 |
| Moderate | Affected services are optional and used infrequently. The effects of the incident appear to be stable. Important or time-sensitive work is not affected.<br><br>A patched RCE vulnerability on production instances that is being rolled out to the wider public. | No urgent action required, but actively monitored by SIRT.<br><br>Work should continue in every assigned region.<br><br>Updates are posted in the incident issue when needed. | \~priority::3 |
| Low | Limited to no affected services. Actions being taken are cleanup or preventative.<br><br>A previously revoked and investigated access token has been discovered. | No action required, monitored in case the situation changes.<br><br>Updates are posted in the incident issue when needed. | \~priority::4 |
| Eventually | False positives kept open for review, informational notices. | No action required, handled when/if SIRT has spare cycles.<br><br>Updates are posted in the incident issue when needed. | \~priority::5 |
### Severity
The severity label is used to indicate the actual or potential impact and helps determine the priority of the incident. Severity should remain the highest level assessed once triage has been done. If it is determined the severity was inaccurately assessed, it should be updated with why the adjustment was made and how we arrived at that conclusion clearly documented in the issue comments.
The `severity` label is used to indicate the actual or potential impact of a security incident. This label is the single source of truth for determining the required response urgency, communication plan, and resource allocation. The severity should be set during the initial triage and cannot be adjusted.
GitLab uses the following company-wide matrix to determine severity:
| Impact | Example | GitLab Label |
| --- | --- | --- |
| Critical | Severe impact to production data confidentiality, integrity or availability is likely if immediate action is not taken. Current controls do not satisfactorily mitigate the risk. Possibility of mass customer impact. Or, reputational risk is severe. | \~severity::1 |
| High | Impact to production data confidentiality, integrity or availability is likely if one or more security controls are circumvented. Current controls mitigate the initial risk. Customer impact or high likelihood of customer impact. Or, reputational risk is high. | \~severity::2 |
| Moderate | Unlikely to impact production data confidentiality, integrity or availability unless multiple security controls fail or are bypassed. Current controls mitigate the initial risk. No customer impact. Or, reputational risk is moderate. | \~severity::3 |
| Low | No risk to impact production data confidentiality, integrity or availability unless multiple security controls fail or are bypassed. Current controls are adequate. No risk of customer impact. Reputational risk is low or highly unlikely. | \~severity::4 |
| Severity:1 **Critical** | **Customer Impact:**<br> Very high impact on users: their customers or business outputs will be impacted <br><br>**OR**<br><br>**GitLab Impact:**<br> Probable or severe damage to the business |Immediate all-hands response | - Customer-facing service is down <br> - Confirmed data breach or exposure of red/orange data <br> - Customer data loss <br> - Low-complexity, validated exploit scenario to GitLab’s platform or supply chain. <br> - Critical RCE that isactively exploited or that is unpatched, reachable, and has no exploitability telemetry <br> - Critical vulnerability that has public exposure (press, customers, 0-day by researcher) <br> - External actor controls a highly privileged GitLab service account|
| Severity:2 **High** | **Customer Impact:**<br> Significant impact on users: their internal operations will be disrupted <br><br>**OR**<br><br>**GitLab Impact:**<br> Possible or elevated damage to the business | Assigned resources, cross-team coordination, and regular stakeholder updates | - Customer-facing service is unavailable for some customers<br> - Core functionality is significantly impacted<br> - Privilege escalation scenarios requiring account compromise or insider-threat motive and knowledge<br>- High severity vulnerability with evidence of exploitation OR high press attention<br>- Suspected unauthorized access into sensitive GitLab systems<br>- Malware detection in GitLab's cloud infrastructure |
| Severity:3 **Medium** | **Customer Impact:**<br> Moderate impact on users: their internal operations may be hampered <br><br>**OR**<br><br>**GitLab Impact:**<br> Unlikely or mild damage to the business | Resources are diverted to address beyond normal operating procedures | - Slight performance degradation<br>- Non-critical features not performing optimally<br>- Commodity malware detection in non-critical systems |
| Severity:4 **Low** | **Customer Impact:**: <br> Low impact on users: their internal operations may be altered <br><br>**OR**<br><br>**GitLab Impact:** Minimal damage to the business | Issue is resolved following standard procedures | - An inconvenience to customers, workaround available<br>- Usable performance degradation<br>- GitLab security policy violations that do not impact red/orange data |
