@@ -36,6 +36,10 @@ Our mission is to enable everyone to innovate and succeed on a safe, secure, and
- Simplifying language for everyone to understand
- Avoiding security jargon
- Seek opportunities to help others succeed
1. Scaling through enablement and usage of AI:
- Enable safe AI adoption at speed for the enterprise and platform
- Deploy AI to detect and prevent threats faster and automate workflows and processes
- Embrace and incorporate AI productivity tooling to work smarter each day
### Division Structure
@@ -113,10 +117,6 @@ The term "Product" is interpreted broadly and includes the GitLab application it
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](/handbook/security/threat-management/) 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](/handbook/security/security-assurance/) 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
@@ -129,14 +129,6 @@ We have a 24x5 [technical support helpdesk](/handbook/security/corporate/support
We invest heavily in [device trust, identity management, and infrastructure governance](/handbook/security/corporate/team/#functional-org-chart) to provide the highest level of security assurance for the administrators of our product and ensure all appropriate controls are in place when handling customer data.
#### Other groups and individuals
### Product development
In keeping with our [core values](/handbook/values/) and the belief that [everyone can contribute](/handbook/company/mission/#contribute-with-gitlab), the Security Division is committed to [dogfooding](/handbook/values/#dogfooding) and contributing to the development of the GitLab product.
---
### <i id="biz-tech-icons" class="fas fa-users"></i> Contacting the Team
#### Reporting vulnerabilities and security issues
@@ -158,153 +150,18 @@ This email address is only accessible to GitLab team members and can be reached
Additionally if a GitLab team member experiences a personal emergency the People Group also provides an [emergency contact email](/handbook/people-group/#in-case-of-emergency).
#### 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](https://gitlab.com/gitlab-com/gl-security/) is used for @'mentioning the entire Security Division
-[@gitlab-com/gl-security/security-managers](https://gitlab.com/gitlab-com/gl-security/security-managers) is used for @'mentioning all managers in the Security Division
-[Security Division Meta](https://gitlab.com/gitlab-com/gl-security/security-department-meta/) is for Security Division initiatives, `~meta` and backend tasks, and catch all for anything not covered by other projects
-[Product Security Meta](https://gitlab.com/gitlab-com/gl-security/product-security/product-security-meta) For department wide management and planning issues.
-[@gitlab-com/gl-security/product-security/appsec](https://gitlab.com/gitlab-com/gl-security/product-security/appsec) is the primary group for @'mentioning the Application Security team.
-[@gitlab-com/gl-security/product-security/appsec/psirt-group](https://gitlab.com/gitlab-com/gl-security/product-security/appsec/psirt-group) is the primary group for @'mentioning the Product Security Incident Response Team (PSIRT)
-[Security Operations (@gitlab-com/gl-security/security-operations)](https://gitlab.com/gitlab-com/gl-security/security-operations) Security Operations Department
-[@gitlab-com/gl-security/security-operations/sirt](https://gitlab.com/gitlab-com/gl-security/security-operations/sirt) is the primary group for @'mentioning the Security Incident Response Team (SIRT).
-[SIRT (private)](https://gitlab.com/gitlab-com/gl-security/security-operations/sirt/operations) for SIRT issues.
-[@gitlab-com/gl-security/security-operations/trust-and-safety](https://gitlab.com/gitlab-com/gl-security/security-operations/trust-and-safety) is the primary group for @'mentioning the Trust & Safety team.
-[@gitlab-com/gitlab-com/gl-security/corp/managers](https://gitlab.com/gitlab-com/gl-security/corp/managers) - Management Team
-[@gitlab-com/gitlab-com/gl-security/corp/helpdesk](https://gitlab.com/gitlab-com/gl-security/corp/helpdesk) - End User Services Helpdesk Team (see [Support Handbook Page](/handbook/security/corporate/support))
-[@gitlab-com/gitlab-com/gl-security/corp/logistics](https://gitlab.com/gitlab-com/gl-security/corp/logistics) - Laptop and Phone Logistics
-[@gitlab-com/gitlab-com/gl-security/corp/saas](https://gitlab.com/gitlab-com/gl-security/corp/saas) - SaaS and Tech Stack Engineering (shared responsibility handled by Device Trust and Identity Teams)
-[@gitlab-com/gitlab-com/gl-security/corp/dept](https://gitlab.com/gitlab-com/gl-security/corp) - Entire Department
#### Slack Channels
-[#security_help](https://gitlab.enterprise.slack.com/archives/C094L6F5D2A): The catch-all channel for security questions that are not direct support requests. If you're not sure where to go, start here.
-[#it_help](https://gitlab.enterprise.slack.com/archives/CK4EQH50E): For all your internal end user support needs and CorpSec support needs. All support related questions and requests should be directed here.
-[#security_discuss](https://gitlab.enterprise.slack.com/archives/C248YCNCW): Security discussions, announcements, and regular updates from the security teams. This is a good channel for cross-function collaboration with internal transparency.
-[#abuse](https://gitlab.slack.com/archives/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.
-[#ciso](https://gitlab.enterprise.slack.com/archives/C05C6Q0TLTV): For general communication from our CISO and CISO Directs. Team and division updates and other topics.
The following group tags can help you get the attention of a specific department, team, or specialty:
**Primary Security departments**:
-**@security-assurance**: Contains all members of the Security Assurance department.
-**@security-corpsec**: Contains all members of the Corporate Security department.
-**@security-prodsec**: Contains all members for the Product Security department.
-**@security-operations**: Contains all members of the Security Operations department. If you need to open a security incident, please use the Slack slash command `/security` instead of a tag.
**Leadership and program support**:
-**@security-leadership**: All Security people-managers
-**@security-program-mgmt**: All security program management team members
**Specific teams and specialties**:
-**@fedramp-compliance**: All SecAssurance members that support FedRAMP
-**@security-governance**: All members of the Security Governance team
-**@sirt-members**: All members of the Security Incident Response Team (SIRT)
-**@sec-assurance-team**: All members of the Security Compliance, Risk, and Governance & Field Security teams
-**@field-security**: All members of the Field Security team
-**@appsec-team**: All members of the Application Security team
-**@trust-and-safety**: All members of the Trust & Safety team
-**@security-identity**: All members of the Identity team
-**@red-team**: All members of GitLab's Red Team
-**@threat-intelligence**: All members of GitLab's Threat Intelligence 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_discuss` by each department leader (CorpSec, ProdSec, SecAssurance, SecOps). These threads are pinned for the duration of the month.
-**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_discuss" 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](https://gitlab.com/gitlab-com/gl-security/product-security/product-security-meta/-/issues/72)) in collaboration with their managers and senior ICs.
#### Twice-Monthly Security Leadership Meetings
Security Leadership meets twice a month over Zoom to discuss division-wide topics. Individual contributors from across the security organization are invited to present their work, ideas, or projects to this leadership forum.
If you're interested in presenting:
1. Discuss the topic with your manager first
2. Your manager will help you:
- Add your topic to the agenda with supporting materials
- Request an appropriate time slot (5-25 minutes)
- Coordinate scheduling your presentation
Note that these meetings are not on the general Security calendar. Your manager will ensure you receive the meeting invitation for your scheduled time.
We encourage all team members to take advantage of this opportunity to share your work and insights with security leadership.
#### Ransomware
For an overview of the communication and response process for a suspected ransomware attack, please see our [Responding to Ransomware](/handbook/security/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](/handbook/security/policies_and_standards/token-management-standard/).
1. When creating a [Personal Access Token](https://docs.gitlab.com/user/profile/personal_access_tokens/), be sure to choose the appropriate [scopes](https://docs.gitlab.com/user/profile/personal_access_tokens/#personal-access-token-scopes) that only have the permissions that are absolutely necessary.
1. Oftentimes a [Project Access Token](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html) 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.
1. Always set an expiration for your tokens when creating them. Tokens should preferably expire in a matter of hours or a day.
1. 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.
1. Please consider periodically reviewing your currently active Personal Access Tokens and revoking any that are no longer needed.
1. 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.
1. If you believe a personal access token has been leaked, revoke it immediately (if possible) and [contact the security team](/handbook/security/security-operations/sirt/engaging-security-on-call/) using the `/security` Slack command.
#### Receive notification of security releases
- To receive security release blog notifications delivered to your inbox, visit our [contact us](https://about.gitlab.com/company/contact/) page.
- To receive release notifications via RSS, subscribe to our [security release RSS feed](https://about.gitlab.com/security-releases.xml) or our [RSS feed for all releases](https://about.gitlab.com/all-releases.xml).
- For additional information regarding security releases, please visit the Delivery Team's [security releases](https://gitlab.com/gitlab-com/gl-infra/readiness/-/tree/master/library/security-releases-development) page.
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)](https://gitlab.com/gitlab-com/security-tools/) 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](https://calendar.google.com/calendar?cid=c_iou94moo2dfleqh610khmis27g%40group.calendar.google.com).
#### Other Frequently Used GitLab.com Projects
Security crosses many teams in the company, so you will find `~security` labeled
@@ -316,21 +173,3 @@ issues across all GitLab projects, especially:
When opening issues, please follow the [Creating New Security Issues]({{% ref "engaging-with-security#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
- GitLab Internal Acceptable Use [Policy](/handbook/people-group/acceptable-use-policy/).
- For GitLab.com, we have developed a [Google Cloud Platform (GCP) Security Guidelines Policy](https://docs.google.com/document/d/1BBTWC5OpIqrva7DqH4nkjYUmNZ3UFbc6erqV89P_N-o/edit?usp=sharing) 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:
- and one [exclusively for stickers](https://gitlab.com/gitlab-com/marketing/corporate_marketing/corporate-marketing/-/blob/master/design/_deprecated/gitlab-brand-assets/gitlab-logo-files/gitlab-security-logo/print-cmyk/pdf/sticker/gitlab-security-icon-diecut-sticker-3x2_78in.pdf).
-[Security READMEs](/handbook/security/readmes/)
-[Working in Security](/handbook/security/working-in-security.md)
-[Contributing to GitLab the product as a Security team member](/handbook/security/contributing-to-gitlab-the-product/)
