Security at GitLab

Purpose

This policy is intended to outline the access management controls implemented by GitLab.

Scope

These controls apply to information and information processing systems at the application and operating system layers, including networks and network services.

Roles & Responsibilities

Policy

Access requests and reviews

Access requests are opened for all new or changing access. (AC-2)

Purpose

This policy is intended to outline the change management controls implemented by GitLab.

Scope

Changes, in the context of this policy, are defined as modifications, including, but not limited to:

• Creation/development/implementation of new systems, integrations, features, key reports, databases, etc.
• Changes to configurations
• Deployment of patches or vendor supplied changes not managed by the vendor
• Modifications to data schemas
• System deprecation
• New access or role creation
• Broadly speaking, any change that will impact how team members carry out their responsibilities

The policy applies to changes that are made to systems assigned a Critical System Tier of Tier 1 Mission Critical, Tier 2 Business Critical, and Tier 3 Business Operational.

Product Security Code Contributions

Security Engineers typically act as Subject Matter Experts and advisors to GitLab’s engineering teams. Security Engineers may wish to make a larger contribution to GitLab products, for example a defense-in-depth measure or new security feature.

Like any contributor, follow the Contributor and Development Docs, paying particular attention to the issue workflow, merge requests workflow, style guides, and testing standards.

Security Engineers will need to collaborate with and ultimately hand over their work to a team in the Development Department. That team will be responsible for prioritisation, review, rollout, error budget, and maintenance of the contribution. Security Engineers should ideally open an Issue or Epic as early as possible, labeled with the candidate owning team. The team can inform implementation or architectural decisions, highlight existing or upcoming work that may impact yours, and let them plan capacity for reviewing your work.

👋 Welcome to Corporate Security, we’re glad you’re here! You may also know us as the former IT Operations team that moved from the Finance to Security division in early 2024.

Need Help?

Please try exploring the following pages to see if your question has been answered in the handbook pages. If not, please ask in the #it_help channel and one of our Support Analysts will reply as soon as possible.

How are critical projects defined?

These projects aren’t considered a function of OKRs (e.g., ambitious) but are considered critical because they

• must be accomplished fully within a specific time frame; and
• require cross-functional collaboration; and
• address immediate-term risks within security or GitLab

Critical Projects must use the label sec-okr::p0.

Vulnerability Reports and HackerOne

GitLab receives vulnerability reports by various pathways, including:

• HackerOne bug bounty program
• Reports or questions that come in from customers through Zendesk.
• Issues opened on the public issue trackers. The security team can not review all new issues and relies on everyone in the company to identify and label issues as ~bug::vulnerability and @-mention @gitlab-com/gl-security/product-security/appsec on issues.
• Issues reported by automated security scanning tools

For any reported vulnerability:

Purpose

To ensure the proper operation and security of GitLab.com, GitLab logs critical information system activity.

Scope

The audit logging policy applies to all systems within our production environment. The production environment includes all endpoints and cloud assets used in hosting GitLab.com and its subdomains. This may include third-party systems that support the business of GitLab.com.

Roles & Responsibilities

Policy

• GitLab shall log and monitor critical information system activity.
• Logs must be retained for a defined period of time.
• Logs must not be modified and or deleted.
• Access to audit log data must be limited based on the principle of least privilege.

Inline with GitLab’s Continuous Monitoring Controls System Owners are responsible for determining what constitutes “critical information system activity” in their respective system based on their experience and professional judgement

Purpose

The Data Classification Standard defines data type and categories and provides the associated Data Classification of each for the purposes of determining the level of protection to be applied to GitLab and Customer data throughout its lifecycle.

Scope

The Data Classification Standard applies to all GitLab team members, contractors, consultants, vendors and other service providers that handle, manage, store or transmit GitLab data.

Roles & Responsibilities

GitLab Responsibilities

• GitLab team members, contractors, consultants, vendors and all other service providers acting on behalf of GitLab are required to review and understand this data classification standard, and how to handle data according to the classification levels below unless otherwise noted.

Passwords at GitLab

Passwords are one of the primary mechanisms that protect GitLab information systems and other resources from unauthorized use. GitLab’s password standard is based, in part, on the recommendations by NIST 800-63B. The password standard sets the requirements for constructing secure passwords and ensuring proper password management. GitLab utilizes 1Password for password management.

1Password

1Password is a password manager that can be used in two different ways - as a standalone application (by purchasing a standalone license) or as a hosted service (by subscribing). GitLab uses 1Password for Business which is a hosted service.

Purpose

This document outlines information security password standards intended to protect GitLab information systems and other resources containing confidential (Red and Orange) GitLab data from unauthorized use, where technically feasible.

Scope

Applies to all GitLab team members, contractors, advisors, and contracted parties interacting with GitLab computing resources and accessing confidential data.

Roles & Responsibilities

Standard

Constructing secure passwords and ensuring proper password management is essential. GitLab’s password standards are based, in part, on the recommendations by NIST 800-63B. To learn what makes a password truly secure, read this article or watch this conference presentation on password strength.

Purpose and Scope

The purpose of this security logging standard is to define GitLab’s requirements for security logging. This document covers both security logging in GitLab’s SIEM (Devo) as well as security logging requirements for systems not sending logs to GitLab’s SIEM.

Roles & Responsibilities

Security Logging Requirements

Security logs are generated by applications and systems used on GitLab and are primarily used for security monitoring, security incident response and cyber threat hunting.

This page contains information on secure training initiatives sponsored by the GitLab Security team.

Security Development Process

For information on developing security fixes in GitLab, please see the Patch Release runbook for preparing security fixes. (Required)

Secure Coding Guidelines

The GitLab Secure Coding Guidelines (Required) cover how to address specific classes of vulnerabilities that have been identified in GitLab.

Secure Code Warrior

GitLab uses Secure Code Warrior to provide ongoing secure coding training. Eligible team members can log in via Okta.

gitleaks on your laptop

If you ended up on this handbook page it’s probably because you have been pointed here during a git commit by our gitleaks installation on your local machine. The tool gitleaks is being used on GitLab endpoints to prevent a common security issue, namely accidental commits of secrets like Personal Access Token or other credentials to public repositories. It is important that all repositories are covered as a leaked access token in one repository can impact all repositories and projects to which your account has access.

Google Cloud Resources

Some Google Cloud resources, if deployed with default settings, may introduce risk to shared environments. For example, you may be deploying a temporary development instance that will never contain any sensitive data. But if that instance is not properly secured, it could potentially be compromised and used as a gateway to other, more sensitive resources inside the same project.

Below are some steps you can take to reduce these risks.

From FY24-Q2 - Individual Growth Plan

Since the launch of the company wide Individual Growth Plan in Workday per FY24-Q2 we recommend Security team members to leverage that tool in Workday to collaborate with their manager on their career path and growth opportunities. Team members can read all about that progress in this guide. We have deprecated the The Individual Development Plan (IDP) template

Till FY24-Q2 - Individual Development Plan

The Individual Development Plan (IDP) template was used by Security team members till FY24-Q1 to help collaborate on a team member’s career path and growth opportunities. The template was designed to document a team member’s personal choices and the direction they want to take their career while allowing their manager to provide guidance and assist with career growth. The use of this template is entirely voluntary and optional. In fact, the template format and process used are also both flexible and adaptable to each manager and team member. Feel free to adapt the template in manners that meet the needs of the manager and team member.

Purpose

GitLab has adopted the ISO/IEC 27001:2022, ISO/IEC 27017:2015 and ISO/IEC 27018:2019 standards for our information security management system (ISMS) to provide GitLab team members, customers and community members with a high level of assurance on the robustness of our information security policies, standards and procedures, and the strength of our control environment. The purpose of this document is to define the boundaries and objectives of GitLab’s ISMS.

Why

There are various reasons why you might want to isolate your work notebook from other devices in your home network:

• Security concerns. The security of individual devices on your home network might vary. Some are notoriously insecure (e.g. smart home devices) or some might simply lack the latest security patches. Isolating devices with poor security from your work notebook (and other sensitive private devices) can increase the security of your work notebook.
• Privacy concerns. GitLab is an all-remote company, with many of its employees working from home. As a side-effect, our work notebooks typically end up being connected to the same network as our personal devices, which allows for network access between these two groups of devices and may raise privacy concerns.

How

Many home routers allow connected devices to be isolated, which prevents any direct network communication between selected devices. This section walks you through setting up an isolated WiFi specifically for your work notebook. The goals specifically are:

A penetration test is a process to identify security vulnerabilities in an application or infrastructure in order to evaluate the security of the system.

Purpose

This policy is intended to outline the penetration testing controls implemented by GitLab.

Scope

These controls apply to the applications and systems that fall within the scope of each specific penetration test.

Roles & Responsibilities

Policy

Planning

A third-party penetration test is conducted at least annually. (CA-8, SC-7(10))

Install GPG Keychain and import PGP Keypair

On a Mac, download and install the GPG Keychain application. Download the keypair file from the Support vault. It’s attached to the ‘security@gitlab.com PGP Keypair’ item. Open the GPG Keychain application and import the keypair file. It will ask for a password. Use the password saved on the vault item.

Now you will be able to encrypt, decrypt, and share the public key with others.

Purpose

This document defines asset management measures and requirements to support the protection of information assets in GitLab’s all remote environment. The measures and requirements noted within the standard are designed to create a secure infrastructure, work environment, and protect sensitive information from physical threats.

Scope

This standard applies to all GitLab team-members, contractors, advisors, and contracted parties interacting with GitLab computing resources and accessing company or customer data.

Aligned with GitLab’s overarching information security strategy and its three-year plan, the Product Security Department (PSD) within the Security Division is responsible for crafting and directing a comprehensive vision to bolster the cybersecurity posture of the GitLab platform.

What is Product Security at GitLab?

At GitLab, product security encompasses a broad range of cybersecurity disciplines that enable product and engineering teams to design, develop, deploy, maintain, and refine GitLab’s technologies securely. This goes beyond the conventional confines of security, covering everything from protecting developer workstations to ensuring the integrity of our production environments.

Purpose

The GitLab records retention and disposal standard lists the specific retention and secure disposal requirements for critical GitLab records. These minimum requirements inform design and maintenance decisions for all GitLab tier 1 and tier 2 critical systems.

Scope

The below retention and secure disposal requirements apply to all GitLab records enumerated in the table below stored in GitLab tier 1 and tier 2 critical systems.

Roles & Responsibilities

Retention & Disposal Requirements Procedure

Exceptions

Exceptions to these requirements will be tracked as per the Information Security Policy Exception Management Process.

Ransomware is a persistent threat to many organizations, including GitLab. In the event of a ransomware attack involving GitLab assets, it’s important to know the existing response procedures in place. Given the variability of targets in such attacks, it’s critical to adapt to existing circumstances and understand that disaster recovery processes are in place to avoid paying any ransom. GitLab’s red team has done extensive research to determine the most likely targets to be affected. As a result, the following guidelines are intended to help bootstrap an efficient response to protect the organization.

What is an RCA?

Root Cause Analysis (RCA) is a process to ultimately identify the root problem of an issue so that we may prevent it from occurring again. You can learn more about RCAs here.

To do this a DRI and all relevant other stakeholders from Security and the affected teams (as determined by the DRI) systematically work through a set of questions and discussion topics, as defined in our RCA Template.

Purpose

This policy is intended to establish requirements for the creation and management of security and technology related policies.

Scope

This policy applies to security and technology policies that fall within the scope of GitLab’s security compliance audits and assessments.

Roles & responsibilities

Policy

Policy creation and requirements

All in-scope policies must be created as version controlled documents in GitLab.

Exceptions

Exceptions to Security and Technology Policies must be tracked and approved by the policy approver(s) via an auditable format. An exception process should be defined in each policy.

Information security considerations such as regulatory, compliance, confidentiality, integrity and availability requirements are most easily met when companies employ centrally supported or recommended industry standards. Whereas GitLab operates under the principle of least privilege, we understand that centrally supported or recommended industry technologies are not always feasible for a specific job function or company need. Deviations from the aforementioned standard or recommended technologies is discouraged. However, it may be considered provided that there is a reasonable, justifiable business and/or research case for a security and technology policy exception; resources are sufficient to properly implement and maintain the alternative technology; the process outlined in this and other related documents is followed and other policies and standards are upheld.

Overview

As a member of the Security department, the Security Assurance sub-department provides GitLab customers with a high level of assurance around the security of GitLab SaaS service offerings.

There are five teams in the Security Assurance sub-department.

Security Assurance Sub-Department

Core Competencies

Field Security Core Competencies

• Sales Training (Security)
• Sales Enablement (Security)
• Customer Assurance (Security)
• Security Evangelization

Security Governance Core Competencies

• Security Policies, Standards and Control maintenance
• Security Assurance Metrics
• Regulatory Landscape Monitoring
• Security Awareness and Training
• Security Assurance Application Administration
• Security Assurance Automation

Security Risk Core Competencies

• Security Third Party Risk Management
• Tier 2 Operational Security Risk Management
• Business Impact Assessments
• Critical System Tiering

Security Compliance, Commercial Core Competencies

• Continuous Control Monitoring
• Security Certifications and Attestations
• User Access Reviews (non-SOX)
• Observation management for control failures and Tier 3 (system-level) risks
• GitLab Production Readiness: Compliance Assessment

Core Tools and Systems

The Security Assurance sub department utilizes a variety of tools to carry out day to day activities. The system admin is responsible for the following:

Mission Statement

The security department as a part of GitLab should follow and live up to the GitLab values and mission. The transparency value can be especially difficult for a security department to embrace and embody, as due to the confidentiality of their work, security people tend to be secretive and intransparent by default.

Intent and goals

The intent of the security culture committee is to maintain a welcoming and transparent environment within the security department.

Overview

This page is created as a result of the FY21Q4 Culture Amp survey, where Security team members expressed a desire to improve on the currently available L&D opportunities at GitLab. In order to paint a holistic picture of L&D resources available to team members, some of the resources detailed on this page are not Security-specific and are already documented in the handbook.

L&D resources available to all team members

GitLab provides a multitude of opportunities to learn and develop new skills on the topics of leadership, management, and DIB. GitLab Learn is the platform of choice that allows self-paced, on-demand courses. It also contains trainings offered through LinkedIn Learning. If you’re looking for a more flexible approach to learning the aforementioned skills, then perhaps the learning initiatives provided by the L&D team are something for you to consider.

Introduction and Purpose

The Security Division plays a critical role in ensuring the security of GitLab as a company, and of GitLab as a platform. In the pursuit of its charter, the division is committed to using (“dogfooding”) GitLab as much as possible in order to help improve the platform for all customers.

This dogfooding program aims to improve the effectiveness and efficiency of collaboration between Product Management and Security as it pertains to capabilities of the GitLab platform.

Overview

This page outlines the Security Division ecosystem, by describing the different processes of our departments. These processes, represented with diagrams, highlight the data flows between our teams but also with external actors like the Product or the Engineering divisions.

Objectives

This page describe how to maintain the Security Division ecosystem.

Scope of the Security Ecosystem

Every process where Security is involved should be documented in this page. Each Security Department is represented and responsible for their own diagrams.

Security OKRs

The Security organization executes quarterly Objectives and Key Results or OKRs.

How We Plan, Assign, and Execute Work

Four Mondays before the start of the fiscal quarter, in the days after the CEO shares OKRs with all of GitLab in the #okr channel, the CISO proposes OKRs for the Security Division in the OKR draft review meeting agenda for a maximum of 5 objectives. Security leaders are to propose draft OKRs to the CISO prior to the meeting for inclusion. From FY24 Q1 forward all Security OKRs are documented in the GitLab OKR project. For easy filtering, all Security Objective and KR issues have the division::Security label applied.

Security Planning

The Security Planning page catalogs the planning work prior to implementation offSecurity Department initiatives and projects that span multiple security teams and projects, or across the entire GitLab organization. This includes things from high level architecture designs for tools used by the Security to developing new or maturing organizational processes.

A Security Plan is done when the text is sufficient to create Epics, Milestones, and Issues with a enough detail to begin work. Requiring further work in the form of proof-of-concepts or spikes may also be an outcome of a “complete” Plan.

From converging on real-time critical events with SIRT, exploiting vulnerabilities with the Red Team or participating in live Customer Assurance calls with the Risk and Field Security team, you will have the opportunity to work next to security staff to gain valuable insight and working knowledge of security fundamentals across multiple domains. Each program includes hands-on activities to provide an authentic security team experience.

The Security Shadow program is designed to provide numerous benefits including

Completion of each course you will receive a certificate. At the completion of all 3 courses your name will be recognized on this page.

Restrictions

Please keep in mind that there are some restrictions on what can and cannot be shared as part of the shadow program, particularly related to high severity vulnerabilities or incidents.

For example if a shadow is watching an AppSec team member triage HackerOne issues and a High or Critical vulnerability is reported, the shadow call should end.

Completion of each course you will receive a certificate. At the completion of all 3 courses your name will be recognized on this page.

Security Compliance

Security Compliance: Where “Just do whatever you want” comes to die. Have you ever wondered where all those pesky security requests and requirements come from and why in the world you’re always being asked to provide evidence and talk through how systems are designed and configured? Well then good news! Come join the security compliance team for a shadow rotation where we’ll have you:

Security Threat Management Sub-Department

The Security Threat Management sub-department is responsible for identifying and remediating vulnerabilities or threats that may impact GitLab, our Team Members or our Customers and the community at large.

Security Threat Management Mission

The Security Threat Management sub-department’s mission is to support the business and our overall security efforts by ensuring that we are focused on real world threats and vulnerabilities that impact us. We accomplish this by:

Purpose

Secure software development is critical to developing and maintaining a safe and trusted application. This policy outlines the general components of GitLab’s software development lifecycle.

Scope

This policy applies to anyone developing, reviewing, and merging code at GitLab in support of GitLab’s production applications.

Roles and responsibilities

Policy

In-scope development activities are performed in accordance with GitLab’s product development flow. (SA-3)

Purpose

Secure software development is critical to developing and maintaining a safe and trusted application. This standard outlines the general components of GitLab’s software development lifecycle.

Scope

This standard applies to anyone developing code at GitLab in support of GitLab’s production applications. For in depth view of development process, see product development flow.

Roles and responsibilities

Standard

Inception and Requirements

This stage occurs across different mediums depending upon each team’s individual processes.

Purpose

In alignment with our company value of Transparency, one focus of the security organization is to lead the most transparent security organization in business today. Transparency by default requires us to challenge the status quo where security teams traditionally operate in a very private and closed-off manner. However, being open by default requires us to be even more diligent in our efforts of categorizing data in order to ensure the protection of our customers, company, and team member data. Therefore, our position is that all information and activities produced by the security team should be considered “Public by Default” unless defined below:

Women in Security Mission Statement

GitLab’s Women in Security group is established to provide support, skills and leadership development, and networking and mentorship opportunities for the women in GitLab’s security department. The group also seeks to inspire women and girls interested in entering or learning about the security industry.

Membership

While tailored for current female team members of the GitLab Security organization, we encourage and welcome the participation of all GitLab members who are dedicated to the support of women in the security industry.

Security Hiring

The company-wide mandate is justification for mapping Security headcount to around 5% of total company headcount. Tying Security Department growth headcount to 5% of total company headcount ensures adequate staffing support for the following (below are highlights and not the entire list of responsibilities of the Security Department):

• Security releases. At GitLab, the Security Department is DRI for critical and non-critical security releases.
• Detection/response for security incidents, which will increase as GitLab.com users increase.
• Preparation for becoming a public company.
• Running the GitLab public bug bounty program.
• Dogfooding and contributing to our product.
• Improving and maintaining the security of GitLab.com and related services.

Career Development and Opportunities at GitLab

Career opportunities at GitLab, personal growth, and development are important and encouraged. Security team members and managers are encouraged to use Individual Development Plans to help foster, guide, and assist with career growth.