We enhance the security posture of our company, products, and client-facing services. The security team works cross-functionally inside and outside GitLab to meet these goals. The security team does not work directly on security-centric features of our platform—these are handled by the development teams. The specialty areas of our team reflect the major areas of information security.
If you identified an urgent security issue, if something feels wrong, or you need immediate assistance from the Security Team, you have two options available:
/security Hi security team, I have a concern! Please see the following URL ... command.Please be aware that the Security Team can only be paged internally. If you are an external party, please proceed to Vulnerability Reports and HackerOne section of this page.
Both mechanisms will trigger the very same process, and as a result, the Security responder on-call will engage in the relevant issue within the appropriate SLA. If the SLA is breached, the Security manager on-call will be paged. Further information on GitLab's security response program is described in our Incident Response guide.
Note: The Security Team will never be upset if you page us for something that turns out to be nothing, but we will be sad if you don't page us and it turns out to be something. IF UNSURE - PAGE US.
The security team can be contacted at security@gitlab.com. External researchers or other interested parties should
refer to our Responsible Disclosure Policy for more information about reporting vulnerabilities. The security@gitlab.com
email address also forwards to a ZenDesk queue that is monitored by the security team.
For security team members, the private PGP key is available in the Security 1Password vault. Refer to PGP process for usage.
The Security Department focuses on two main top-level objectives.
In order to achieve our top-level goals and scale the tasks for these goals, the Security Department must grow headcount based on total headcount for all of GitLab, rather than total headcount for the Engineering function. This is because Security is a cross-functional role, and besides working with the rest of Engineering, also collaborates with other functions at GitLab, such as Legal, People, Finance, Product, Sales and Marketing. For pre-IPO cloud-native companies, the industry standard for Security headcount is 4-6% of total company headcount. We are following the boring solution approach here at GitLab by tying Security Department headcount to 5% of total company headcount.
Tying Security Department growth headcount to 5% of total company headcount will ensure adequate staffing support for the following (below are highlights and not the entire list of responsibilities of the Security Department):
Security Automation specialists help us scale by creating tools that perform common tasks automatically. Examples include building automated security issue triage and management, proactive vulnerability scanning, and defining security metrics for executive review. Initiatives for this specialty also include:
Application Security specialists work closely with development, product security PMs, and third-party groups (including paid bug bounty programs) to ensure pre and post deployment assessments are completed. Initiatives for this specialty also include:
The Security Operations team is here to manage security incidents across GitLab. This is often a fast-paced and stressful environment where responding quickly and maintaining ones composure is critical.
More than just being the first to acknowledge an issue when they arise, Security Operations is responsible for leading, designing, and implementing the strategic initiatives to grow the Detection and Response practices at GitLab. These initiatives include:
Security Operations can be contacted on slack via our handle @sec-ops-team or in a Gitlab issue using @gitlab-com/gl-security/secops. If your request requires immediate attention please review the steps for engaging the security on-call.
Abuse Operations specialists investigate malicious use of our systems. Initiatives for this specialty include:
Compliance enables Sales by achieving standards as required by our customers and help to verify that the outcomes the security team is trying to achieve are actually being met. This includes SaaS, on-prem, and open source instances. Initiatives for this specialty also include:
For additional information about the compliance program see the Security Compliance team handbook page or refer to GitLab's security controls for a detailed list of all compliance controls organized by control family.
Threat intelligence specialists research and provide information about specific threats to help us protect from the types of attacks that could cause the most damage. Initiatives for this specialty also include:
Strategic security specialists focus on holistic changes to policy, architecture, and processes to reduce entire categories of future security issues. Initiatives for this specialty also include:
The Field Security team serves as the public face for GitLab's Security Department. The Field Security team works closely with multiple teams within GitLab including:
Areas of responsibility for the Field Security team include:
Security research specialists conduct internal testing against GitLab assets, and against FOSS that is critical to GitLab products and operations. Initiatives for this specialty also include:
The External Communications Team leads customer advocacy, engagement and communications in support of GitLab Security Team programs. Initiatives for this specialty include:
GitLab's internal red team extends the objectives of penetration testing by examining the security posture of the organization and their ability to implement effective cyber defenses. Penetration testing is a specialized type of assessment conducted on information systems or individual system components to identify vulnerabilities that could be exploited by adversaries. Such testing can be used to either validate vulnerabilities or determine the degree of resistance organizational information systems have to adversaries within a set of specified constraints (e.g., time, resources, and/or skills). Red team exercises provide more comprehensive assessments that reflect real-world conditions over penetration testing. The exercises can further be used to improve security awareness and training and to assess levels of security control effectiveness. GitLab utilizes NIST 800-53 Revision 4 security control CA-8 to define the red team and their mission. The control can be found on NIST.gov.
The red team operates under a pre-defined set of rules of engagement. The rules of engagement exist to inform GitLab's team members on how the team operates during engagements. It provides guidelines for determining scope, the ethics we employ during our engagements, how we collaborate as a security team, and how we escalate vulnerabilities and exploits we discover during those engagements.
The Security team will collaborate with development and product management for security-related features in GitLab. The Secure team must not be mistaken with the Security Team.
We work closely with bounty programs, as well as security assessment and penetration testing firms to ensure external review of our security posture.
Information Security Policies are reviewed annually. Policy changes are approved by the Senior Director of Security and Legal. Changes to the Data Protection Impact Assessment Policy are approved by GitLab's Privacy Officer.
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 an information security 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.
In the event an employee requires a deviation from the standard course of business or otherwise allowed by policy, the Requestor must submit a Policy Exception Request to IT Security, which contains, at a minimum, the following elements:
The Senior Director of Security approves or denies IT Security Policy Exceptions.
If the business wants to appeal a decision by the Senior Director of Security, such appeal will be sent to Legal at legal@gitlab.com. Legal will draft an opinion as to the proposed risks to the company if the deviation were to be granted. Legal’s opinion will be forwarded to the CEO and CFO for final disposition.
Any deviation approval must:
~meta and backend tasks, and catch all for anything
not covered by other projects.gl-security/runbooks
should only be used for documenting specifics that would increase risk and/or
have customer impact if publicly disclosed.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-team-standup - Private channel for daily standups.#incident-management and other infrastructure team channels#security-alert-manual - New reports for the security team from various intake sources, including ZenDesk and new HackerOne reports.#hackerone-feed - Feed of most activity from our HackerOne program.#security-alert-* and #abuse* - Multiple channels for different notifications
handled by the Security Department.Security crosses many teams in the company, so you will find ~security labelled
issues across all GitLab projects, especially:
When opening issues, please follow the Creating New Security Issues process for using labels and the confidential flag.
| 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. |
The Security Department tracks their OKRs using the boards in the table below.
These boards aggregate work from the many subgroups and projects under gitlab-com/gl-security
used by the various subteams to track their work and projects. High level issues
and open issues that map directly to an OKR should be added to the board for the
quarter to provide visibility into the current work of the security team.
When creating an issue that maps to an OKR, apply the following group level labels so that it appears in the board:
~FY20Q3Security Management:: label for the appropriate team. For example: ~Security Management::Security Automation TeamThese labels can also be applied to MRs related to the work.
| Quarter | Board |
|---|---|
~FY20Q3 |
Board link |
~FY20Q2 |
Board link |
The definitions, processes and checklists for security releases are described in the release/docs project.
The policies for backporting changes follow Security Releases for Gitlab EE.
For critical security releases, refer to Critical Security Releases in the handbook for a high level description of communication, and the critical release checklist in release/docs.
The Security team needs to be able to communicate the priorities of security related issues to the Product, Development, and Infrastructure teams. Here's how the team can set priorities internally for subsequent communication (inspired in part by how the support team does this).
New security issue should follow these guidelines when being created on GitLab.com:
confidential if unsure whether issue a potential
vulnerability or not. It is easier to make an issue that should have been
public open than to remediate an issue that should have been confidential.
Consider adding the /confidential quick action to a project issue template.~security at a minimum.~bug or ~feature if appropriate~customer if issue is a result of a customer report~internal customer should be added by team members when the issue
impacts GitLab operations.~keep confidential. If possible avoid this by linking
resources only available to GitLab employees, for example, the originating
ZenDesk ticket. Label the link with (GitLab internal) for clarity.Occasionally, data that should remain confidential, such as the private project contents of a user that reported an issue, may get included in an issue. If necessary, a sanitized issue may need to be created with more general discussion and examples appropriate for public disclosure prior to release.
For review by the Application Security team, @ mention @gitlab-com/gl-security/appsec.
For more immediate attention, refer to Engaging security on-call.
~security IssuesThe presence of ~security modifies the standard severity labels(~S1, ~S2, ~S3, ~S4)
by additionally taking into account
likelihood as described below, as well as any
other mitigating or exacerbating factors. The priority of addressing
~security issues is also driven by impact, so in most cases, the priority label
assigned by the security team will match the severity label.
Exceptions must be noted in issue description or comments.
The intent of tying ~S/~P labels to remediation times is to measure and improve GitLab's
response time to security issues to consistently meet or exceed industry
standard timelines for responsible disclosure. Mean time to remediation (MTTR) is
a external
metric that may be evaluated by users as an indication of GitLab's committment
to protecting our users and customers. It is also an important measurement that
security researchers when choosing to engage with the security team, either
directly or through our HackerOne Bug Bounty Program.
| Severity | Priority | Time to remediate |
|---|---|---|
~S1 |
~P1 |
As soon as possible |
~S2 |
~P2 |
Within 60 days |
~S3 |
~P3 |
Within 90 days |
~security IssuesFor ~S2 and ~S3 ~security issues, the security engineer assigns the Due date,
which is the target date of when fixes should be ready for release.
This due date should account for the Time to remediate times above, as well as
monthly security releases on the 28th of each month. For example, suppose today is October 1st, and
a new S2 ~security issue is opened. It must be addressed in a security release within 60 days,
which is November 30th. So therefore, it must catch the November 28th security release.
Furthermore, the Security Release Process deadlines
say that it should the code fix should be ready by November 23rd. So the due date
in this example should be November 23rd.
Note that some ~security issues may not need to be part of a code release, such as
an infrastructure change. In that case, the due date will not need to account for
monthly security release dates.
On occasion, the due date of such an issue may need to be changed if the security team needs to move up or delay a monthly security release date to accommodate for urgent problems that arise.
~S1 ~security issues do not have a due date since they should be fixed as soon
as possible, and a security release made available as soon as possible to accommodate
it.
Security issues which would be triaged as ~S4, are most likely ~features
that should be triaged and prioritized by a product manager. This
includes suggestions without a well-defined path for implementation or
requiring complex changes to the application or architecture to address.
~S4/~P4 may be used for ~features as assigned by a product
manager and do not need assignment to a release.
The security team may also apply ~internal customer and ~security request to issue as an
indication that the feature is being requested by the security team to meet
additional customer requirements, compliance or operational needs in
support of GitLab.com.
The security engineer must:
~Create, ~Deploy, etc.)~merge request.@pm for scheduling.The product manager will assign a Milestone that has been assigned a due
date to communicate when work will be assigned to engineers. The Due date
field, severity label, and priority label on the issue should not be changed
by PMs, as these labels are intended to provide accurate metrics on
~security issues, and are assigned by the security team. Any blockers,
technical or organizational, that prevents ~security issues from being
addressed as our top priority
should be escalated up the appropriate management chains.
Note that issues are not scheduled for a particular release unless the team leads add them to a release milestone and they are assigned to a developer.
Issues with an S1 or S2 rating should be immediately brought to the
attention of the relevant engineering team leads and product managers by
tagging them in the issue and/or escalating via chat and email if they are
unresponsive.
Issues with an S1 rating have priority over all other issues and should be
considered for a critical security release.
Issues with an S2 rating should be scheduled for the next scheduled
security release, which may be days or weeks ahead depending on severity and
other issues that are waiting for patches. An S2 rating is not a guarantee
that a patch will be ready prior to the next security release, but that
should be the goal.
Issues with an S3 rating have a lower sense of urgency and are assigned a
target of the next minor version. If a low-risk or low-impact vulnerability
is reported that would normally be rated S3 but the reporter has
provided a 30 day time window (or less) for disclosure the issue may be
escalated to ensure that it is patched before disclosure.
It is possible that a ~security issue becomes irrelevant after it was initially triaged, but before a patch was implemented. For example, the vulnerable functionality was removed or significantly changed resulting in the vulnerability not being present anymore.
If an engineer notices that an issue has become irrelevant, he should @-mention the person that triaged the issue to confirm that the vulnerability is not present anymore. Note that it might still be necessary to backport a patch to previous releases according to our maintenance policy. In case no backports are necessary, the issue can be closed.
For information on secure coding initiatives, please see the Secure Coding Training page.
Centralized access management is key to ensuring that the correct GitLab team-members have access to the correct data and systems and at the correct level. GitLab access controls are guided by the principle of least privilege and need-to-know. These controls apply to information and information processing systems at the application and operating system layers, including networks and network services.
The access request project is used to request and track the following access-related activities:
Usage guidelines for each of the access templates is outlined in the project's README file
These templates should be used during the onboarding process and throughout the employment tenure of a GitLabber. Access required as part of the team member's onboarding should be requested using the New Access Requests or if applicable, one of the available Baseline Role-based Entitlements templates.
All new access or permissioning change requests require a New Access Request.
All access requests must be approved by the team member's manager with the exception of:
Please note that ARs for access to internal systems for "external to GitLab individuals" (eg. customers, prospects) require managerial approval. This includes access to G-Suite security groups also require managerial approval.
Access requests are required when requesting a role above developer (i.e. maintainer, owner) on the following GitLab repositiories and Groups:
Requests for access to Infrastructure assets (servers and databases) require a second layer of approval from Infrastructure Management.
Administrative permissions should be considered operational in nature. This means that they are granted for the sole purpose of system management, configuration, and support. They should be recognized as privileged accounts and as such, activities must be logged and the logs protected and regularly reviewed.
Time-based access may be provided if administrative action is required for a set period of time. This should be documented as part of the Access Request SLAs.
All requests for new service accounts require a New Service Account Request
All requests for new service accounts must be approved by a member of Infrastructure Management.
Bulk access requests are those that are for multiple GitLab team-members. Bulk requests can be submitted for the following three types of requests:
Please note that the above use cases do not apply to ADMIN-level access, which needs to be submitted using the one issue per GitLab team-member rule.
If admin-level access is being requested, the request must be approved by the team member's manager and Infrastructure Management if applicable.
During the onboarding process, the manager should determine which email and slack groups the new team member should be added to. Also determine if new team member will need access to the dev server, which is used by engineers to prepare fixes for security issues and also allows for access to version.gitlab.com and license.gitlab.com. If so, request the creation of a new dev.GitLab.org account with the same username the team member has on gitlab.com and an invitation to the gitlab group as a Developer. Fill out one access request for both the groups and Dev account if needed.
GitLab operates its access management under the https://csrc.nist.gov/glossary/term/least-privilege. Under least privilege, a GitLabber should only be granted the minimum necessary access to perform their function. An access is considered necessary only when a GitLabber cannot perform a function without that access. If an action can be performed without the requested access, it's not considered necessary. Least privilege is important because it protects GitLab and its customers from unauthorized access and configuration changes and in the event of an account compromise by limiting access.
A least privilege review should be performed by a system's administrator and the manager of the GitLabber for whom access is being requested. System administrators should be provided security training that includes specific training on least privilege and its application.
To perform a least privilege review, compare the rationale provided for the service(s) to which access is being requested with the level of access being requested.
rationale section of the access request.If the access requested provides the GitLabber only the access they require to perform what's in the rationale section of the access request, the access request should be approved. In this case, simply proceed with approving the access request. An access request approval is considered confirmation the request has been reviewed for least privilege. Once your approval has been submitted, there's no more action for you to take for the least privilege review.
If the access requested provides the GitLabber access beyond what is required in the information provided in the rationale section of the access request, the request doesn't align with the principle of least privilege and the request should be temporarily rejected until the appropriate access can be defined. To reject an access request on the basis of least privilege, respond to the issue with the following information:
Should there be disagreement on an access request rejection on the basis of least privilege, an exception request should be submitted. An exception request is important because it provides a clearly defined escalation process, promotes transparency, and allows us to appropriately track any deviations from policy.
In the case of a separation from the company, all access will be deprovisioned within 3 business days from the date on which the offboarding request is submitted unless otherwise specified.
All attempts will be made for individual access removal requests to be processed within the SLA requested. If no SLA is noted, access will be deprovisioned within 3 business days of the submission of the issue.
If access removal needs to occur immediately, please follow the panic email procedures, which will alert the Security Team on-call.
Access reviews will be formally documented using the Access Reviews template.
As part of an access review, existing access may be modified or revoked. New access (not modification of existing access) requires the submission of a New Access Request.
If you are performing an access review, you must review the Access Review Guidelines, including Access List Generation procedures prior to starting the review process, which includes the user list generation. It is important to understand the population generation requirements so completeness and accuracy of the listing and the review performed can be evidenced.
Reviewers must never recertify their own access; this must be reviewed and recertified by an alternate system administrator, system owner, or the primary reviewer's manager (or someone above them in their reporting hierarchy).
An access request is not required for Google Drive folders or files.
Managerial approval is not required when requesting access to:
Bulk requests can be submitted for the following three types of requests:
The goal of baseline and role-based entitlements is to increase security while reducing access management complexity by moving towards role-based access control. The basic idea is that if we configure all of our systems for access based on the specific job families that require access to each system, then as we scale we can simply add new GitLab team-members to these pre-defined groups and system-level access will be granted automatically. The difficult part in this implementation is accurately defining the access each role should have and collecting/maintining all related approvals. The GitLab solution to this challenge is to use baseline and role-based entitlements. These entitlements define what systems each role should have access to and to pre-approve access to those systems so provisioning can be sped up. Okta will be a huge help in this process as we continue to build out that tool, but these baseline entitlements can still define pre-approved access to systems not managed by Okta. Baseline and role-based entitlements can also help automate access reviews since we will have a solid source of truth for what access should exist for each role and which GitLab team-members should be a part of each role.
The basic workflow for using a baseline or role-based entitlement is:
The hope with the above workflow is that everyone will contribute to the creation of the baseline and role-based entitlements and they will be prioritized based on how frequently the roles have access provisioned for them. The other benefit of this approach to access is that each access request template for the specific baseline or role-based entitlement role can have very specific instructions and links.
For certain roles, baseline and role-based entitlement access runbooks & templates that outline the baseline access configurations for the role have been established.
The Baseline and Role-based Entitlements directory contains all the approved role-based entitlement runbooks.
The runbook is used to document the configuration and approvals for the baseline and role-based entitlements. Any changes to these approved configurations require the approval of the management groups outlined in each of the runbooks.
Updates to the baseline and role-based entitlements should be reflected in both the runbook and the template. Approvals for the change(s) should be documented in the runbook.
| System Name | Business Purpose | System Role (What level of access) | Data Classification |
|---|---|---|---|
| 1Password | User Password Management | Team Member | RED |
| BambooHR | Human Resource Platform | Employee | RED |
| Calendly | Add-in for meeting Scheduling | Employee | YELLOW |
| Carta | Shares Management | Employee | RED |
| CultureAmp | 360 Feedback Management | User | YELLOW |
| Expensify | Expense Claims and Management | Employee | ORANGE |
| GitLab.com | Gitlab Application for Staff | Employee | RED |
| Greenhouse | Recruiting Portal | Interviewer | RED |
| Gsuite | Email, Calendar, and Document sharing/collaboration | GitLab.com Org Unit | RED |
| Moo | Business Cards | User | YELLOW |
| NexTravel | Travel booking | Employee | ORANGE |
| Sertifi | Digital signatures, payments, and authorizations | User | YELLOW |
| Slack | GitLab async communications | Member | RED |
| Periscope Data | Data Analysis and Visualisation | User | RED |
| Will Learning | Staff Training and Awareness Portal | User | YELLOW |
| ZenDesk (non US Federal instance | Customer Support - Incident Management | Light Agent | RED |
| Zoom | For video conferencing / meetings | User | RED |
| System Asset | User Role | Expected Role |
|---|---|---|
| AWS - Gitter | SRE | Administrator |
| AWS - Staging | SRE | Administrator |
| AWS- Gitlab.com | SRE | Administrator |
| Azure | SRE | Global Administrator |
| dev.gitlab.org | SRE | add Admin role to regular account |
| Digital Ocean | SRE | Member |
| gitlab.com | SRE | Admin - admin account-username |
| ops.gitlab.net | SRE | added w/ production group from chef users databag |
| staging.gitlab.com | SRE | add Admin role to regular account |
| GCP | SRE | Folder Admin/Infra. |
| Chef | SRE | Admin |
| Pager Duty | SRE | Admin |
| Status.io | SRE | Admin |
| 1Password Vaults | SRE | Vaults: Team, DevOps, Gitter, Production |
| Rackspace | SRE | Admin for Tickets, Observer for Billing |
| System Asset | User Role | Expected Role |
|---|---|---|
| AWS - Security | SecOps | Administrator |
| AWS - gitlab.com | SecOps | ReadOnly |
| GCP | SecOps | gcp-ops-sg@gitlab.com; gcp-owners-sg@gitlab.com; security-gl-team@gitlab.com |
| Digital Ocean | SecOps | Member |
| gitlab.com | SecOps | Admin - admin-username |
| ops.gitlab.net | SecOps | added w/ production group from chef users databag |
| dev.gitlab.org | SecOps | Admin - username (one account) |
| staging.gitlab.com | SecOps | Admin - username (one account) |
| Slack | SecOps | Workspace Admin |
| G Suite | SecOps | Super Admin |
| 1Password | SecOps | Administrator |
| Snowflake | SecOps | securityadmin, sysadmin |
| HackerOne | SecOps | Report |
| PagerDuty | SecOps | Admin |
| misp.sec.gitlab.net | SecOps | Organization Admin for GitLab Security Department |
| Tenable.io | SecOps | Scan Manager role and Scan Viewers group |
| The Hive | SecOps | Admin |
| System Asset | User Role | Expected Role |
|---|---|---|
| AWS - Security | SecAuto | Administrator |
| AWS - gitlab.com | SecAuto | ReadOnly |
| GCP | SecAuto | gcp-owners-sg@gitlab.com; security-gl-team@gitlab.com |
| Digital Ocean | SecAuto | Member |
| gitlab.com | SecAuto | Admin - admin-username |
| ops.gitlab.net | SecAuto | added w/ production group from chef users databag |
| dev.gitlab.org | SecAuto | Admin - username (one account) |
| staging.gitlab.com | SecAuto | Admin - username (one account) |
| Slack | SecAuto | Workspace Admin |
| G Suite | SecAuto | Super Admin |
| 1Password | SecAuto | Administrator |
| Periscope | SecAuto | Default |
| Snowflake | SecAuto | securityadmin, sysadmin |
| HackerOne | SecAuto | Report |
| PagerDuty | SecAuto | Admin |
| Okta | SecAuto | Read-Only Admin |
| misp.sec.gitlab.net | SecAuto | Organization Admin for GitLab Security Department |
| Tenable.io | SecAuto | Scan Operator role and Scan Viewers group |
| The Hive | SecAuto | Admin |
| System Asset | User Role | Expected Role |
|---|---|---|
| AWS - Security | RedTeam | Administrator |
| AWS - gitlab.com | RedTeam | ReadOnly |
| GCP | RedTeam | gcp-ops-sg@gitlab.com; gcp-owners-sg@gitlab.com; security-gl-team@gitlab.com |
| Digital Ocean | RedTeam | Member |
| gitlab.com | RedTeam | Admin - admin-username |
| ops.gitlab.net | RedTeam | added w/ production group from chef users databag |
| dev.gitlab.org | RedTeam | Admin - username (one account) |
| staging.gitlab.com | RedTeam | Admin - username (one account) |
| Slack | RedTeam | Workspace Admin |
| G Suite | RedTeam | Super Admin |
| 1Password | RedTeam | Administrator |
| Snowflake | RedTeam | securityadmin, sysadmin |
| HackerOne | RedTeam | Report |
| PagerDuty | RedTeam | Admin |
| misp.sec.gitlab.net | RedTeam | Organization Admin for GitLab Security Department |
| Tenable.io | RedTeam | Basic role and Scan Viewers group |
| The Hive | RedTeam | Admin |
| System Asset | User Role | Expected Role |
|---|---|---|
| GitLab HQ | FrontendEng | Developer |
| staging.gitlab.com | FrontendEng | User |
| Email Groups | FrontendEng | frontendteam@gitlab.com |
| gitlab.com Groups | FrontendEng | [at]gl-frontend |
| GCP | FrontendEng | gitlab-internal (Kubernetes User) |
| Slack | FrontendEng | User (@frontend-group) |
| dev.gitlab.org | FrontendEng | User |
| license.gitlab.com | FrontendEng | User |
| System Asset | User Role | Expected Role |
|---|---|---|
| GitHub.com/GitLabHQ | BackendEng | Developers |
| staging.gitlab.com | BackendEng | User |
| gitlab.com Groups | BackendEng | Developer |
| GCP | BackendEng | roles/container.admin role for gitlab-internal-153318 project |
| Slack | BackendEng | User (member of @developers) |
| dev.gitlab.org | BackendEng | Developer in the gitlab group |
| server access | BackendEng | ability to SSH into qa-tunnel.gitlab.info |
| System Asset | User Role | Expected Role |
|---|---|---|
| 1Password | EngProdEng | User |
| GitLab HQ | EngProdEng | Developers |
| staging.gitlab.com | EngProdEng | Developer |
| dev.gitlab.org | EngProdEng | Developer in the gitlab group |
| ops.gitlab.net | EngProdEng | Developer |
| gitlab.com | EngProdEng | Developer in gitlab-org, Developer in gitlab-com, Owner in @gl-quality, Owner in gitlab-org/quality |
| GCP | EngProdEng | roles/container.admin role for gitlab-internal-153318 project |
| GCP | EngProdEng | roles/container.admin role for gitlab-review-apps project, (member of gcp-quality-sg@gitlab.com) |
| GCP | EngProdEng | roles/container.admin role for gitlab-qa-resources project |
| Slack | EngProdEng | User (member of @qualityteam) |
| server access | EngProdEng | ability to SSH into qa-tunnel.gitlab.info |
| EngProdEng | Member of quality@gitlab.com |
|
| Periscope | EngProdEng | Editor |
| System Asset | User Role | Expected Role |
|---|---|---|
| 1Password | TestAutoEng | User |
| GitLab HQ | TestAutoEng | Developers |
| staging.gitlab.com | TestAutoEng | Developer |
| dev.gitlab.org | TestAutoEng | Developer in the gitlab group |
| ops.gitlab.net | TestAutoEng | Developer |
| gitlab.com Groups | TestAutoEng | Developer |
| GCP | TestAutoEng | roles/container.admin role for gitlab-internal-153318 project |
| GCP | TestAutoEng | roles/container.admin role for gitlab-review-apps project, (member of gcp-quality-sg@gitlab.com) |
| GCP | TestAutoEng | roles/container.admin role for gitlab-qa-resources project |
| Slack | TestAutoEng | User (member of @qualityteam) |
| dev.gitlab.org | TestAutoEng | Developer in the gitlab group |
| server access | TestAutoEng | ability to SSH into qa-tunnel.gitlab.info |
| TestAutoEng | Member of quality@gitlab.com |
| System Asset | User Role | Expected Role |
|---|---|---|
| GitLab HQ | BackendEng / FrontendEng | Developers |
| staging.gitlab.com | BackendEng / FrontendEng | User |
| Email Groups | FrontendEng | frontendteam@gitlab.com |
| gitlab.com Groups | BackendEng / FrontendEng | Developer, gl-frontend |
| GCP | BackendEng / FrontendEng | gitlab-internal (Kubernetes User) |
| Slack | BackendEng / FrontendEng | User (member of @developers and @javascripters) |
| dev.gitlab.org | BackendEng / FrontendEng | Developer in the gitlab group |
| server access | BackendEng / FrontendEng | ability to SSH into qa-tunnel.gitlab.info |
When submitting a new access-request issue for any of these roles, please choose the template corresponding with the role of the person for which you are submitting the access request.
GitLab's access controls include the following control activities:
+admin@gitlab.com as the email address: username+ADMIN@gitlab.com-admin appended: username-adminThe admin account "Full name" should include text to indicate it is an admin account: First Last (Admin)
If you would like to check whether or not a team-member is a member of a Slack or a G-Suite group, you can view the following automated group membership reports:
G-Suite Group Membership Reports
Slack Group Membership Reports
For systems built (or significantly modified) by functional groups that house customer and other sensitive data, the Security Team should perform applicable application security reviews to ensure the systems are hardened. Security reviews aim to help reduce vulnerabilities and to create a more secure product.
There are two ways to request a security review depending on how significant the changes are. It is divided between individual merge requests and larger scale initiatives.
Loop in the application security team by /cc @gitlab\-com/gl\-security/appsec in your merge request.
These reviews are intended to be faster, more lightweight, and have a lower barrier of entry.
To get started, create an issue in the security tracker, add the app sec review label, and submit a triage questionnaire form. The complete process can be found at here.
Some use cases of this are for epics, milestones, reviewing for a common security weakness in the entire codebase, or larger features.
No, code changes do not require security approval to progress. Non-blocking reviews enables the freedom for our code to keep shipping fast, and it closer aligns with our values of iteration and efficiency. They operate more as guardrails instead of a gate.
To help speed up a review, it's recommended to provide any or all of the following:
The current process for larger scale internal application security reviews be found here
Security reviews are not proof or certification that the code changes are secure. They are best effort, and additional vulnerabilities may exist after a review.
It's important to note here that application security reviews are not a one-and-done, but can be ongoing as the application under review evolves.
The security team plays a large role in defining procedures for defending against and dealing with spam. Common targets for spam are public snippets, projects, issues, merge requests, and comments. Advanced techniques for dealing with these types of spam are detailed in the Spam Fighting runbook.
For any actions taken on an account:
The purpose of adding Admin Notes allow us to better assist the Support Team and Production if there are any questions around changes made to an account by the Security Team.
The Security Team plays a big role in defining the procedures and reviewing Digital Millennium Copyright Act (DMCA) requests. All DMCA requests need to be vetted by Legal first before any further steps are taken to proceed with the take down of reported content. Reported content that has been successfully vetted by Legal must be referred to the Abuse Team before any action is taken.
Abuse works in conjunction with Legal referencing the DMCA Removal Workflow
GitLab receives vulnerability reports by various pathways, including:
security@gitlab.com~security and @-mention @gitlab-com/gl-security/appsec on issues.For any reported vulnerability:
dev or in other non-public ways even if there is a reason to believe that the vulnerability is already out in the public domain (e.g. the original report was made in a public issue that was later made confidential).GitLab utilizes HackerOne for its bug bounty program. Security researchers can report vulnerabilities in GitLab applications or the GitLab infrastructure via the HackerOne website. Team members authorized to respond to HackerOne reports use procedures outlined here.
The #hackerone-feed Slack channel receives notifications of report status changes and comments via HackerOne's Slack integration.
Application Security team members may assign themselves as the directly responsible individual (DRI) for incoming requests to the Application Security team for a given calendar week in the Triage Rotation Google Sheet in the Security Team Drive.
The following rotations are defined:
security@gitlab.com, which creates tickets in ZenDesk,
following the AppSec ZenDesk processTeam members should not assign themselves on weeks they are responsible for the scheduled security release.
Team members not assigned as the DRI for the week should continue to triage reports when possible, especially to close duplicates or handle related reports to those they have already triaged.
Team members remain responsible for their own assigned reports.
06 - Duplicates/Invalid Reports Triaged First
common response may be used.~feature as defined above and would not need to be
made confidential or scheduled for remediation. An issue can be created, or
requested that the reporter creates one if desired, but the report can be
closed as "Informative".01 - Duplicate common response. Include the link to the GitLab issue.05 - Duplicate Follow Up, No Adding Contributors/Future Public Release common response
can be used when denying the request to add as a contributor./h1import *report_id* [ce/ee] [Sx] [Px] in Slack
00 - Triaged Common
response as a template.04 - Bounty Award / Reviewed and Awarded Prior to Fix can be used
as the template for the bounty award if approved.When critical vulnerabilities are identified, it is necessary to quickly get the attention of the appropriate engineering team and the security operations team
in order to fully determine impact to gitlab.com and to self-managed customers. When a vulnerability is determined to be P1/S1, do the following after following
the steps above:
If a report is unclear, or the reviewer has any questions about the validity of the finding or how it can be exploited, now is the time to ask. Move the report to the "Needs More Info" state until the researcher has provided all the information necessary to determine the validity and impact of the finding. Use your best judgement to determine whether it makes sense to open a confidential issue anyway, noting in it that you are seeking more information from the reporter. When in doubt, err on the side of opening the issue.
One the report has been clarified, follow the "regular flow" described above.
If a report violates the rules of GitLab's bug bounty program use good judgement in deciding how to proceed. For instance, if a researcher has tested a vulnerability against GitLab production systems (a violation), but the vulnerability has not placed GitLab user data at risk, notify them that they have violated the terms of the bounty program but you are still taking the report seriously and will treat it normally. If the researcher has acted in a dangerous or malicious way, inform them that they have violated the terms of the bug bounty program and will not receive credit. Then continue with the "regular flow" as you normally would.
If the report does not pose a security risk to GitLab or GitLab users it can be closed without opening an issue on GitLab.com.
When this happens inform the researcher why it is not a vulnerability. It is up to the discretion of the Security Engineer whether to to close the report as "Informative", "Not Applicable", or "Spam".
When a patch has been developed, tested, approved, merged into the security branch, and a new security release is being prepared it is time to inform the researcher via HackerOne. Post a comment on the HackerOne issue to all parties informing them that a patch is ready and will be included with the next security release. Provide release dates, if available, but try not to promise a release on a specific date if you are unsure.
This is also a good time to ask if they would like public credit in our release blog post and on our vulnerability acknowledgements page for the finding. We will link their name or alias to their HackerOne profile, Twitter handle, Facebook profile, company website, or URL of their choosing. Also ask if they would like the HackerOne report to be made public upon release. It is always preferable to publicly disclose reports unless the researcher has an objection.
We use CVE IDs to uniquely identify and publicly define vulnerabilities in our products. Since we publicly disclose all security vulnerabilities 30 days after a patch is released, CVE IDs must be obtained for each vulnerability to be fixed. The earlier obtained the better, and it should be requested either during or immediately after a fix is prepared.
We currently request CVEs either through the HackerOne team or directly through MITRE's webform. Keep in mind that some of our security releases contain security related enhancements which may not have an associated CWE or vulnerability. These particular issues are not required to obtain a CVE since there's no associated vulnerability.
On the day of the security release several things happen in order:
Once all of these things have happened notify the HackerOne researcher that the vulnerability and patch are now public. The GitLab issue should be closed and the HackerOne report should be closed as "Resolved". Public disclosure should be requested if they have not objected to doing so. Any sensitive information contained in the HackerOne report should be sanitized before disclosure.
GitLab awards swag codes for free GitLab swag to any reports that result in a security patch. Limit: 1 per reporter. When a report is closed, ask the reporter if they would like a swag code for free GitLab clothing or accessories. Swag codes are available by request from the marketing team.
Even though many of our 3rd-party dependencies, hosted services, and the static
about.gitlab.com site are listed explicitly as out of scope, they are sometimes
targeted by researchers. This results in disruption to normal GitLab operations.
In these cases, if a valid email can be associated with the activity, a warning
such as the following should be sent to the researcher using an official channel
of communication such as ZenDesk.
Dear Security Researcher,
The system that you are accessing is currently out-of-scope for our bounty
program or has resulted in activity that is disruptive to normal GitLab
operations. Reports resulting from this activity may be disqualified from
receiving a paid bounty. Continued access to this system causing disruption to
GitLab operations, as described in policy under "Rules of Engagement,
Testing, and Proof-of-concepts", may result in additional restrictions on
participation in our program:
Activity that is disruptive to GitLab operations will result in account bans and disqualification of the report.
Further details and some examples are available in the full policy available at:
https://hackerone.com/gitlab
Please contact us at security@gitlab.com with any questions.
Best Regards,
Security Department | GitLab
security@gitlab.com
https://about.gitlab.com/handbook/engineering/security/
We have a process in place to conduct security reviews for externally contributed code, especially if the code functionality includes any of the following:
The Security Team works with our Community Outreach Team to ensure that security reviews are conducted where relevant. For more information about contributing, please reference the Contribute to GitLab page.
Some customers, to keep up with regulations that impact their business, need to understand the security implications of installing any software - including software like GitLab.
The current process for responding to customer requests is:
Security Audit and for the completion of that documentGitLab maintains a custom vulnerability scanner that is used to regularly scan all GitLab assets for common vulnerabilities as well as previously patched GitLab vulnerabilities and to ensure that no GitLab security-sensitive services are accidentally exposed.
Details on this scanner and how it is configured are available to all team members in a Google Doc entitled "Vulnerability Scanner Config".
The packages we ship are signed with GPG keys, as described in the omnibus documentation. The process around how to make and store the key pair in a secure manner is described in the runbooks. Those runbooks also point out that the management of the keys is handled by the Security team and not the Build team. For more details that are specific to key locations and access at GitLab, find the internal google doc titled "Package Signing Keys at GitLab" on Google Drive.
Risk assessments help GitLab identify, prioritize, and manage security risks. They're important to help protect customer data and meet GitLab security compliance controls, which are important for compliance standards such as SOC2 and PCI-DSS. A risk assessment should ideally be completed for every service in the Tech Stack Applications table and reviewed either quarterly or as substantial changes are made, whichever is most feasible. Additionally, risk assessments are used as part of Data Protection Impact Asessments (DPIAs).
At GitLab, our risk assessment framework is based on a combination of NIST SP 800-30 Rev. 1 and the Mozilla Rapid Risk Assessment (RRA), but customized to be collaborative, asynchronous, and done within GitLab itself. All risk assessment work is done within the Risk Assessment repository.
[Service Name]-risk-assessment in the assessments/ directory.assessments/ directory. To contribute to a risk assessment, please create an MR to propose the change or start a discussion.Risk assessments should be continually reviewed and revised to keep the information in risk assessments current and relevant. At a minimum, every risk assessment should be reviewed once per year or as significant changes are made to the system, whichever comes first. To conduct a risk assessment review:
