Vulnerability Management Standard

1. You are here:
2. Handbook
3. Security at GitLab
4. Security Threat Management
5. Vulnerability Management Standard

On this page

• Purpose
• Scope
• Roles & Responsibilities
  • Additional Notes for Vulnerability Triaging
• Standard
  • Remediation SLAs
  • Risk Acceptance (Exceptions)
    • FedRAMP process
    • Non-FedRAMP process
      • Exception length restrictions
      • Exception approval matrix
• Contact
• Exceptions
• References

Purpose

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.

Scope

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

Roles & Responsibilities

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

Additional Notes for Vulnerability Triaging

1. The VulnMapper creates vulnerability issues if not available already, adds appropriate severity, priority and other necessary labels, and reports Deviation Request issues of vendor dependencies automatically.
2. For the vulnerabilities that VulnMapper cannot process automatically, the Vulnerability Management Team logs 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.
3. The Vulnerability Management Team assigns vulnerability issues to a development group based on the best guess.
   1. Note that 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.
   2. Vulnerability triage is a shared responsibility although the Vulnerability Management Team is the DRI. AppSec, InfraSec and respective feature domain development groups are responsible for providing evidence and/or analysis of GitLab-specific impact during vulnerability triage upon the Vulnerability Management Team's request. Vulnerability tracking issues should be assigned to the appropriate AppSec stable counterpart or development group for further analysis.
4. A typical workflow of triaging vulnerabilities will look like -
   1. Identify those issues where we know 100% sure that it goes to a specific group and have the VulnMapper Bot assign the issue to that development group.
   2. For all issues the VulnMapper Bot cannot assign and the Vulnerability Management Team is uncertain, assign those to the AppSec team.
   3. The Appsec counterpart could then assign the issue to the appropriate group after their triage.

Standard

• Application (WebApp and container) vulnerability scanning must occur on a minimum of a monthly basis.
• Infrastrucutre (operating systems and databases) vulnerability scanning must occur on a minimum of a monthly basis.
• Authenticated/credentialed scans should be performed wherever possible.
• Vulnerability scanners must be up to date (latest version), hardened to resist unauthorized use or modification.
• Third party penetration testing must be performed annually.
• Vulnerability remediation SLA timeframes begin as soon as a vulnerability is detected.

Remediation SLAs

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:

1. CVSSv3 base score.
2. CVSSv2 base score.
3. Base risk score reported by a vulnerability scanner.

Risk Acceptance (Exceptions)

FedRAMP process

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.

Non-FedRAMP process

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:

• Vulnerability title
• Tenable plugin-ID (if applicable)
• CVE (if applicable)
• Priority/Severity of Vulnerability
• Original remediation issue due date
• Length of requested exception
• List of applicable hosts or software packages

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.

Exception length restrictions

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

Exception approval matrix

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

Contact

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

Exceptions to this standard will be tracked as per the Information Security Policy Exception Management Process.

References

• Parent Policy: Information Security Policy
• Application Vulnerability Management Procedure
• Infrastructure Vulnerability Management Procedure
• Bug Bounties