We at GitLab are committed to helping our customers succeed. When a GitLab.com customer reaches out for assistance with a security incident that is the result of their implementation or use of GitLab, we will do our best to assist with the investigation by providing additional information surrounding the event, if available.
If a GitLab.com customer determines that the information available through the Audit Events feature doesn't provide suffcient information about activities taken on the customer's account, GitLab may provide reasonable assistance by performing additional log-dives under certain conditions and requirements.
Technical Account Managers (TAMs) and GitLab Support are our customers' main contacts at GitLab. These teams will ensure that the communication with the customer takes place as efficiently as possible, will provide status updates regarding the log request, and ultimately hand out any artefacts that might result from the request to the customer.
GitLab Support handles non-complex application log requests that are within a 7-day time window from the time of the request.
GitLab's Security Incident Response Team handles complex, extensive requests. In order to maximize efficiency and provide results in a timely manner, customers will not be able to interface with the relevant security team directly during these requests. All communication with the customer is channelled through GitLab Support or the dedicated TAM.
confidentialissue in the SIRT tracker using the
information_requesttemplate. The author of the issue ensures that the request contains all required information.
@gitlab-com/gl-security/sirton the issue. The requesting customer must not be added to the issue.
@lasayersshould only be requested if an exception is required.
Each request for assistance should comply with the conditions outlined in this section
The assistance outlined on this page only applies to paying GitLab.com customers on the Premium or Ultimate plans. It does not apply to free accounts, trial accounts, accounts on deprecated support plans, or accounts that are not subject to payment for other reasons.
Requests for assistance can only apply to the GitLab.com account that the customer owns. GitLab will not be providing assistance or information about GitLab.com accounts that the requesting customer does not own.
If a specific request applies to a GitLab.com account that is not owned by the requesting customer, a legal subpoena will be required. For such cases, the customer should reach out to GitLab Legal.
At this time, GitLab is unable to perform log-dives exceeding a 1-month time window from the time of the request. The scope of the request should be specific and as narrow as possible. If it is determined by GitLab that the scope is too broad and excessive, GitLab may request for the scope to be narrowed, or inform the customer of the cost they will incur in performing the investigation.
Please note that because of the amount of logs that GitLab.com generates daily, log-dives exceeding a 7-day time window from the time of the request will take longer to complete.
The request should contain a list of specific GitLab.com resources of interest - projects, users, groups. If the list is considered excessive, GitLab will ask for the request to be re-scoped. This is to ensure that the request is handled in a timely and resource-efficient manner.
The request should contain a list of specific GitLab.com events of interest. If the list is considered excessive, GitLab will ask for the request to be re-scoped. This is to ensure that the request is handled in a timely and resource-efficient manner.
Log-dives can be time consuming. The GitLab teams performing the log-dives will be providing updates through the designated issue. GitLab Support/Account Owner/TAM will relay the updates to the customer. Attempts to contact GitLab Security or its individuals on the status of the request will be unanswered. This applies to out-of-band communication as well (i.e. social media, personal e-mails, phone calls).
Due to the volume of
access logs generated daily on GitLab.com, we are currently not able to perform log-dives on
access logs (i.e. HTTP requests) directly. Instead, we're relying on application logs and logs generated by other componenets of our production stack.
Information provided from logs should be redacted to ensure that we are not disclosing (i) GitLab Confidential or system information or (ii) any information pertain to accounts other than those subject to the request.
This process applies to GitLab.com only. GitLab is unable to produce logs for self-managed customers.
GitLab Premium or Ultimate plans provide access to the Audit Events feature, which should provide the required information to help advanced customers to monitor the security and health of their GitLab.com accounts. This process is an extension of that feature that will: