Security at GitLab

Security Vision and Mission

Our vision is to transparently lead the world to secure outcomes.

Our mission is to enable everyone to innovate and succeed on a safe, secure, and trusted DevSecOps platform. This will be achieved through 5 security operating principles:

1. Accelerate business success with a focus on:
   • Prioritize ‘boring’, iterative solutions that minimize risk
   • Find ways to say Yes
   • Understand goals before recommending solutions
   • Use GitLab first
2. Efficient operations with a focus on:
   • Technical controls over handbook rules
   • Leverage automation first (robots over humans)
   • Responsible decisions (Spending, Tooling, Staffing, etc) over low ROI (return on investment) decisions
   • Reusable or repeatable over singular solutions
3. Transparency with a focus on:
   • Responsible protection of MNPI (material non-public information)
   • Evangelize dogfooding of GitLab publicly
   • Lead with metrics
   • Balance security with usefulness
4. Risk Reduction with a focus on:
   • Secure by default
   • Preventative controls over detective controls
   • Solving root causes over treating symptoms
   • Visibility through Coverage, Discoverability, Observability
5. Collaborative Culture with a focus on:
   • Working together on common solutions
   • Solve shared problems with shared solutions
   • Simplifying language for everyone to understand
   • Avoiding security jargon
   • Seek opportunities to help others succeed

To help achieve the vision of transparently leading the world to secure outcomes, the Security Division has nominated a Security Culture Committee.

Division Structure

The Security Division provides essential security operational services, is directly engaged in the development and release processes, and offers consultative and advisory services to better enable the business to function while minimising risk.

To reflect this, we have structured the Security Division around four key tenets, which drive the structure and the activities of our group. These are :

Product Security	Security Operations	Threat Management	Security Assurance
Application Security Infrastructure Security Product Security Engineering Security Architecture Security Research Security Threat & Vulnerability Management	Security Incident Response Team (SIRT) Trust and Safety Security Logging Red Team	Identity Engineering, Infra, and Ops	Field Security Security Compliance Security Governance Security Risk

Secure the Product - The Product Security Department

The Product Security Department is primarily focused on Securing the Product. This reflects the Security Division’s current efforts to be involved in the Application development and Release cycle for Security Releases, Infrastructure Security, and our HackerOne bug bounty program.

The term “Product” is interpreted broadly and includes the GitLab application itself and all other integrations and code that is developed internally to support the GitLab application for the multi-tenant SaaS. Our responsibility is to ensure all aspects of GitLab that are exposed to customers or that host customer data are held to the highest security standards, and to be proactive and responsive to ensure world-class security in anything GitLab offers.

Protect the Company - The Security Operations Department

Security Operations Department teams are primarily focused on protecting GitLab the business and GitLab’s platform. This encompasses protecting company property as well as to prevent, detect and respond to risks and events targeting the business and our platform. This department includes the Security Incident Response Team (SIRT) and the Trust and Safety team.

These functions have the responsibility of shoring up and maintaining the security posture of GitLab’s platform to ensure enterprise-level security is in place to protect our new and existing customers.

Lead with Data - The Threat Management Department

Threat Management Department teams are cross-functional. They are responsible for collaborating across the Security Division to identify, communicate, and remediate threats or vulnerabilities that may impact GitLab, our Team Members or our users and the community at large.

Assure the Customer - The Security Assurance Department

The Security Assurance Department is comprised of the teams noted above. They target Customer Assurance projects among their responsibilities. This reflects the need for us to provide resources to our customers to assure them of the security and safety of GitLab as an application to use within their organisation and as a enterprise-level SaaS. This also involves providing appropriate support, services and resources to customers so that they trust GitLab as a Secure Company, as a Secure Product, and Secure SaaS

Other groups and individuals

Security Program Management

Security Program Management is responsible for complete overview and driving security initiatives across Product, Engineering, and Business Enablement. This includes the tracking, monitoring, and influencing priority of significant security objectives, goals, and plans/roadmaps from all security sub-departments. Security Program Manager Job Family

Security Program areas of focus

• Drive Accountability & Visibility for Program Objectives & Goals
• Drive, Gather, & Examine Program Needs & Opportunities through Intra & Inter Organizational Collaboration
• Provide Insights & Suggestions Impacting Program Strategy & Roadmap
• Assist in Gathering & Prioritizing Program Risks, Requirements, & Alignment to Influence Remediation
• Drive & Define Acceptance Criteria, Value Proposition, Milestones to Visualize and Communicate Program Effectiveness
• Develop Repeatable, Scalable, Efficient, Effective, Processes & Procedures

Product development

In keeping with our core values and the belief that everyone can contribute, the Security Division is committed to dogfooding and contributing to the development of the GitLab product.

---

Contacting the Team

Reporting vulnerabilities and security issues

For information regarding GitLab’s HackerOne bug bounty program, and creating and scheduling security issues, please see our engaging with security page and our Responsible Disclosure Policy.

Reporting an Incident

If an urgent security incident has been identified or you suspect an incident may have occurred, please refer to Engaging the Security Engineer On-Call. Examples include, but are not limited to:

• Lost or stolen devices
• Leaked credentials
• Endpoint compromise or infection
• Exposure of sensitive GitLab data

GitLab provides a panic@gitlab.com email address for team members to use in situations when Slack is inaccessible and immediate security response is required.

This email address is only accessible to GitLab team members and can be reached from their gitlab.com or personal email address as listed in Workday. Using this address provides an excellent way to limit the damage caused by a loss of one of these devices.

Additionally if a GitLab team member experiences a personal emergency the People Group also provides an emergency contact email.

Sub-groups and projects

Many teams follow a convention of having a GitLab group team-name-team with a primary project used for issue tracking underneath team-name or similar.

• @gitlab-com/gl-security is used for @‘mentioning the entire Security Division
• @gitlab-com/gl-security/security-managers is used for @‘mentioning all managers in the Security Division
• Security Division Meta is for Security Division initiatives, ~meta and backend tasks, and catch all for anything not covered by other projects
• Security Assurance (@gitlab-com/gl-security/security-assurance)
  • @gitlab-com/gl-security/security-assurance/sec-compliance
  • @gitlab-com/gl-security/security-assurance/field-security-team
  • @gitlab-com/gl-security/security-assurance/security-risk-team
  • @gitlab-com/gl-security/security-assurance/governance
• Product Security (@gitlab-com/gl-security/product-security)
  • Product Security Meta For department wide management and planning issues.
  • @gitlab-com/gl-security/product-security/appsec is the primary group for @‘mentioning the Application Security team.
• Security Operations (@gitlab-com/gl-security/security-operations) Security Operations Department
  • @gitlab-com/gl-security/security-operations/sirt is the primary group for @‘mentioning the Security Incident Response Team (SIRT).
    • SIRT (private) for SIRT issues.
  • @gitlab-com/gl-security/security-operations/trust-and-safety is the primary group for @‘mentioning the Trust & Safety team.
• Security Threat Management
  • Identity and Access Management
    • @gitlab-com/gl-security/identity/infra
    • @gitlab-com/gl-security/identity/ops
  • @gitlab-com/gl-security/security-operations/redteam
  • @gitlab-com/gl-security/security-research
  • @gitlab-com/gl-security/threatmanagement/vulnerability-management

Slack Channels

• #security; Used for general security questions and posting of external links for the great discussions. Company wide security relevant announcements are announced in #whats-happening-at-gitlab and may be copied here.
• #security-department - Daily questions and discussions focused on work internal to the Security Division. Can be used for reporting when unsure of where to go.
• #abuse - Used for reporting suspected abusive activity/content (GitLab Internal) as well as general discussions regarding anti-abuse efforts. Use @trust-and-safety in the channel to alert the team to anything urgent.
• #security-department-standup - Private channel for daily standups.
• #incident-management and other infrastructure department channels
• #security-alert-manual - New reports for the Security Division from various intake sources, including ZenDesk and new HackerOne reports.
• #hackerone-feed - Feed of most activity from our HackerOne program.
• Other #security-alert-* and #abuse* - Multiple channels for different notifications handled by the Security Division.
• Use the @sirt-members mention in any Slack channel to tag the members of the Security Incident Response Team (SIRT).
• Use the @sec-assurance-team mention in any Slack channel to tag the members of the Security Compliance, Risk, and Governance & Field Security teams.
• Use the @field-security mention in any Slack channel to tag the members of the Field Security team.
• Use the @appsec-team mention in any Slack channel to tag the members of the Application Security team.
• Use the @trust-and-safety mention in any Slack channel to tag the members of the Trust & Safety team.
• Use the @security-identity mention in any Slack channel (or #security-identity-ops) to tag members of the Identity team.

Division, Department, and Team updates

We believe it is important to share regular updates at various levels of the Security Division, and we use Slack as the primary mechanism for providing these updates. Our updates are open to all GitLab team members using the following process:

• Start of each month: A thread per-department is started in #security-department by each department leader (CorpSec, ProdSec, SecAssurance, SecOps). These threads are pinned for the duration of the month.
  • Thread template:
    • <MONTH> <DEPARMENT> Weekly Updates
    • Example: August Product Security Weekly Updates
• Weekly: At least once a week, teams provide updates they wish to share within the appropriate thread. For example, updates from Vulnerability Management would be placed in the Product Security thread for the given month.
  • These weekly updates, while highly encouraged, are strictly optional and should represent content that ICs and managers feel should be highlighted. Teams are encouraged to define processes and DRIs around these updates that work for them.
  • Individuals providing the weekly updates are encouraged to use the “Also send to #security-department” option within the thread to increase visibility.
• End of each month: Departmental leaders prepare a monthly update, including no more than three updates per team, and post it in #ciso within the first week of the following month.
  • Each monthly update should include a brief preface written by the departmental leader covering any notable themes or other strategic updates.
  • Each of the three updates per-team should be no more than 2-3 sentences and include at least one link to allow readers to gain additional context. Links should be to GitLab Issues or Epics wherever possible. If information is confidential and not able to be added to an Issue or Epic, a note should be added indicating this.
  • It is recommended that departmental leaders build their monthly update over the course of the month via a GitLab issue (see an example) in collaboration with their managers and senior ICs.

Ransomware

For an overview of the communication and response process for a suspected ransomware attack, please see our Responding to Ransomware page.

---

Important topics

Tokens

The following best practices will help ensure tokens are handled appropriately at GitLab. For detailed requirements regarding the use of tokens at GitLab, please see our token management standard.

1. When creating a Personal Access Token, be sure to choose the appropriate scopes that only have the permissions that are absolutely necessary.
2. Oftentimes a Project Access Token might be sufficient instead of a Personal Access Token. Project Access Tokens have a much more limited scope and should be preferred over Personal Access Tokens whenever possible.
3. Always set an expiration for your tokens when creating them. Tokens should preferably expire in a matter of hours or a day.
4. Be mindful to keep these personal access tokens secret. Be particularly careful not to accidentally commit them in configuration files, paste them into issue or merge request comments, or otherwise expose them.
5. Please consider periodically reviewing your currently active Personal Access Tokens and revoking any that are no longer needed.
6. Personal Access Tokens will be highly discouraged within the GitLab production environment, and disallowed/disabled wherever possible. Existing tokens shall remain, but additional issuance will not be permissible/possible.
7. If you believe a personal access token has been leaked, revoke it immediately (if possible) and contact the security team using the /security Slack command.

Receive notification of security releases

• To receive security release blog notifications delivered to your inbox, visit our contact us page.
• To receive release notifications via RSS, subscribe to our security release RSS feed or our RSS feed for all releases.
• For additional information regarding security releases, please visit the Delivery Team’s security releases page.

Resources

Tools

• Incident-Tools (private) for working scripts and other code during or while remediating an incident. If the tool is applicable outside of the GitLab.com environment, consider if it’s possible to release when the ~security issue becomes non-confidential. This group can also be used for private demonstration projects for security issues.
• security-tools (mostly private) contains some operational tools used by the security teams. Contents and/or configurations require that most of these projects remain private.

Calendar

We welcome GitLab team members to join meetings that are on our shared Security Calendar.

Other Frequently Used GitLab.com Projects

Security crosses many teams in the company, so you will find ~security labeled issues across all GitLab projects, especially:

• gitlab-foss
• gitlab
• infrastructure
• production

When opening issues, please follow the Creating New Security Issues process for using labels and the confidential flag.

Other Resources for GitLab Team Members

• Security Best Practices, using 1Password and similar tools, are documented on their own security best practices page.
• Secure Coding Training.
• GitLab.com data breach notification policy.
• GitLab Internal Acceptable Use Policy.
• For GitLab.com, we have developed a Google Cloud Platform (GCP) Security Guidelines Policy document, which outlines recommended best practices, and is enforced through our security automation initiatives.
• GitLab Security Tanuki for use on security release blogs, social media and security related swag as appropriate:
  • Web-RGB
  • Print-CMYK
  • and one exclusively for stickers.
• Security READMEs
• Working in Security
• Contributing to GitLab the product as a Security team member
• Threat Modeling

AI in Security Learning Group

This group is setup to help interested Security team members get up to speed with AI technologies and how to secure them. For more information, see the AI in Security Learning Group page.