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.
Vulnerability Management is the continual process of identifying, prioritizing, mitigating and remediating vulnerabilities. At GitLab we identify vulnerabilities in a number of different ways depending on the component being analyzed. This page will outline our vulnerability management standards for GitLab.
This Vulnerability Management Standard defines a consistent process to identify, document, categorize, manage, and remediate all vulnerabilities that impact in-scope GitLab systems in order to reduce the risk relating to security vulnerabilities that could impact the achievement of GitLab goals. For details on vulnerability management procedures, refer to the references section at the bottom of this page.
This standard applies to all systems that store, process or transmit GitLab production and/or GitLab customer data as well as GitLab software and software dependencies, based on the GitLab critical system tiering methodology. Specifically:
Component | Tooling | Notes |
---|---|---|
Infrastructure | Tenable.io | All cloud environments |
GitLab Product & Dependencies | GitLab, Twistlock, Trivy, Grype | AppSec Vuln Management |
Detected Later | HackerOne, Community reported, 3rd Party PenTest | HackerOne Process |
Role | Responsibility | Notes |
---|---|---|
Security Compliance Team | Responsible for oversight of supporting procedures as part of ongoing continuous control monitoring. Responsible for approving Deviation Requests (or getting approval from Agency) and closing DR issues once all linked vulnerability issues have been closed. | |
Vulnerability Management Team | Responsible for implementing and maintaining this Vulnerability Management Standard. Develop and maintain the (VulnMapper). Evaluate severity and priority, analyze the actual impacts, and make risk adjustment for the vulnerabilities that VulnMapper is unable to process from the scanner reports. | See additional notes below. |
Application Security Team | Setup and automate scanner runs, based on our policies. Collaborate with Development in the triage of vulnerabilities. | |
Infrastructure Security Team | Analyze the finding for validity and / or determine if a fix is available. Recommend a fix or solution. If appropriate, open an MR to remediate. | |
Security Automation Team | Develop and maintain the GitLab Security Bot, a.k.a. appsec-escalator | The Application Security team collaborates with Security Automation team maintaining this bot. |
All of GitLab | Responsible for adherence and implementation of this standard and supporting procedure(s) for vulnerabilities under their responsibility | |
Security Leadership (Code Owners) | Responsible for approving changes to this standard |
vulnerability issues
if not available already, adds appropriate severity, priority and other necessary labels, and reports Deviation Request issues
of vendor dependencies automatically.vulnerability issues
with necessary information such as CVSS score, severity and priority, package name and version etc., and reports Deviation Request issues
with risk adjustment evaluation when applicable. The AppSec team will collaborate and provide support to the Vulnerability Management team as needed.vulnerability issues
to a development group based on the best guess.
group::not_owned
was deprecated. There isn't a default development group to assign vulnerability issues
to and here's how development groups handle vulnerabilities. Make the best effort guess and avoid assigning the majority of vulnerabilities to a single development group.The following timelines or service level agreements (SLAs) are based on many factors - such as regulatory compliance, customer SLOs & SLAs, vulnerability impact, scope, prevalence in GitLab environments, impact if exploited, and defining reasonable turn-around times for mitigation and remediation to protect GitLab and our customers. All of these factors will be considered when mapping the priority to GitLab’s priority labels. All components in scope of Vulnerability Management are subject to the same SLAs. The SLAs are as follows:
CVSSv3 Score* | Severity | Priority | Time to mitigate | Time to remediate (TTR) |
---|---|---|---|---|
9.0-10.0 (Critical) | ~severity::1 |
~priority::1 |
Within 24 hours | 30 day SLA |
7.0-8.9 (High) | ~severity::2 |
~priority::2 |
N/A | 30 day SLA |
4.0-6.9 (Medium) | ~severity::3 |
~priority::3 |
N/A | 90 day SLA |
0.1-3.9 (Low) | ~severity::4 |
~priority::4 |
N/A | 180 day SLA |
* A vulnerability's severity is assigned using the first available value from this list:
For FedRAMP related vulnerabilities, all exception requests must follow the FedRAMP Vulnerability Deviation Request Procedure. For vulnerabilities in 3rd party (non-GitLab) dependencies, the SLA remediation timeframe re-starts once a patch/fix is released/published.
We understand that it is not always technologically feasible to use the latest dependency, package or container base image due the need to ensure the stability and performance of GitLab as a product and a service. Business decisions may be made to not remediate a vulnerability, or delay remediation, because remediation would impact performance or reliability too greatly, or introduce significant risk of doing so. Low risk vulnerabilities that may not be prioritized within the remediation SLAs should have an exception created and approved - documenting the low likelihood of exploitation due to layered security, other compensating controls, complexity of exploitation, etc. With this in mind we have a vulnerability exception process;
If you've identified a vulnerability that is a candidate for an exception, please open a vulnerability exception issue in the vulnerability management issue tracker.
Please fill all out the pertinent information requested in the template. For reference, the information required is as follows:
You will also need to describe the justification for the exception: Document any existing implemented compensating controls, factors complicating the remediation, and links to any ongoing and relevant remediation efforts.
We currently allow exception lengths based on priority/severity as follows:
P/S | 30-days | 60-days | 90-days | 365-days |
---|---|---|---|---|
priority::1/severity::1 | Yes |
No |
No |
No |
priority::2/severity::2 | Yes |
Yes |
Yes |
No |
priority::3/severity::3 | Yes |
Yes |
Yes |
Yes |
priority::4/severity::4 | Yes |
Yes |
Yes |
Yes |
After the issue is open, the requestor should assign the due date to match that of the associated remediation issue and assign to the proper approver. The severity and priority of the vulnerability will dictate the approval process. This is documented below:
P/S | Approver |
---|---|
priority::1/severity::1 | Head of Security or Infrastructure |
priority::2/severity::2 | Director of Security Operations |
priority::3/severity::3 | Security Manager, Security Incident Response Team |
priority::4/severity::4 | Security Engineer, Security Incident Response Team |
If you have any questions or concerns related to vulnerability management please contact the Vulnerability Management Team in #security-department
channel on slack, or you can open an issue in the Infrastructure Vulnerability Management issue tracker. All work being done to improve this process is also tracked in the issue tracker.
Any questions regarding ownership around vulnerability management can be answered in GitLab’s tech stack documentation.
Exceptions to this standard will be tracked as per the Information Security Policy Exception Management Process.