This living guide is intended to explain to users the why, when, and how of security incident response at GitLab.
If an urgent security incident has been identified or you suspect an incident may have occurred, Security Operations on-call can be paged by:
/security <issue description>in GitLab Slack
For lower severity requests or general Q&A, GitLab Security is available in the
#Security channel in GitLab Slack and the Security Operations team can be alerted by mentioning
@sec-ops-team. If you suspect you've received a phishing email please see: What to do if you suspect an email is a phishing attack.
Security incident investigations are conducted when a security incident has been detected on GitLab.com, regardless of whether it's a single user or multiple projects, and these investigations are handled with the same level of urgency and priority. Indicators can be reported to us either internally, by a GitLab team member, or externally. It is the Security team's responsibility to determine when to investigate, dependent on the identification and verification of a security incident. The GitLab Security team identifies security incidents as any violation, or threat of violation, of GitLab security, acceptable use or other relevant policies.
Security incidents may (and usually do) involve sensitive information related to GitLab, GitLab's customers or employees, or users who (in one way or another) have engaged with GitLab. GitLab, while codifying the Transparency value, also strongly believes in and strives to maintain the privacy and confidentiality of the data its' employees, customers, and users have entrusted us with.
A confidential issue means any data within the issue and any discussions about the issue or investigation are to be kept to GitLab employees only unless permission is explicitly granted by GitLab Legal, GitLab Security Director, or the GitLab Executive Team.
Security incident investigations must begin by opening a tracking issue in the Security Operations project. This tracking issue will be the primary location where all work and resulting data collection will reside throughout the investigation. All artifacts from an investigation must be handled per the Artifact Handling and Sharing internal only runbook.
NOTE: The tracking issue, any collected data, and all other engagements involved in a Security Incident must be kept strictly confidential.
Assigning severity to an incident isn't an exact science and it takes some rational concepts mixed with past experiences and gut feelings to decide how bad a situation may be. When considering severity, look at:
After taking these types of questions into consideration, review the Overall Impact to help place a severity rating on the incident.
#secops_####where #### is the GitLab issue number in the Security Operations project.
Once an incident has been identified and its severity set, the incident responder must attempt to limit the damage that has already occurred and prevent any further damage from occurring. The first step in this process is to identify impacted resources and determine a course of action to contain the incident while potentially also preserving evidence. The containment strategy will vary based on the type of incident being responded to but can be as simple as marking an issue confidential to stop an information disclosure or to block access to a network segment. It is important to remember that the containment phase of incident response is typically a short-term solution to limit damage and not to produce a long term fix for the underlying problem. Additionally the impact of the mitigation on the service must be weighed against the severity of the incident.