The Field Security team serves as the public representation of GitLab’s internal Security function. Our vision is to be the leading example in collaborative and transparent Customer Assurance Programs. Our mission is to empower the GitLab community with confidence and trust that their data is protected with high levels of security assurance to drive revenue growth. We partner with our fellow GitLab team members and customers to provide a pathway to yes!
Core Competencies
The Field Security team is tasked with providing high levels of security assurance to internal and external customers. We work with all GitLab departments to document requests, analyze the risks associated with those requests, and provide value-added remediation recommendations. We do this in four main ways:
Conducting Customer Assurance Activities such as completing Security, Privacy, and Risk Management Questionnaires, assisting in Contract Reviews, participating in Customer Pre-Sales Meetings, and making available our Security Documents (such as GitLab’s SOC2 or Penetration Test reports). These activities are managed through the Customer Assurance Activities Service Desk.
Providing recommendations based on customer security concerns in support of revenue growth through the annual Field Security Study and participation in the Quarterly Business Review Process.
Building the GitLab Security brand by improving internal and external awareness of GitLab’s security practices and the security of our platform. Engaging with customers and prospects through Evangelism Activities and with internal stakeholders via the Field Security Sales Training Program.
Trust Center administration and development (Knowledge Base, content, documents, integrations and metrics)
Note: The areas above related to each team members primary responsibility. However, each team member is cross trained in all processes and provide back up to each other if applicable.
Do you have an idea, feedback, or recommendation for how Field Security can better support you? Please open a General Request issue in the Field Security Project.
GitLab conducts an annual Field Security Study to document areas of concern or improvement identified with GitLab’s enterprise security, market competitiveness, and ability to support its customers’ needs. By assessing the perceived impact rating and providing clear and centralized insight on customer feedback to GitLab’s leadership, we can drive cross-organizational alignment on a strategy to iterate on GitLab’s product and security programs.
The purpose of this guide is to establish quality expectations for AnswerBase.
Quality Expectations
Answers
Answers in AnswerBase should have the following characteristics:
More than just a yes or no answer
Answers should contain a supporting narrative.
The supporting narrative should accurately explain why we are answering yes or no to a question.
The supporting narrative should refer back to a control, product feature, policy/procedure, etc. that justifies our yes or no answer.
We are not obligated to provide the supporting narratives to customers in questionnaires.
The supporting narratives will enhance all team members’ understanding of the topics covered by the answers.
The supporting narratives will help establish AnswerBase as a true knowledgebase for all team members.
Answers will be reviewed for accuracy on at least an annual basis.
Tags
Answers should have tags assigned to them.
Tags will support quicker and smoother searching for team members.
Tags will be reviewed for accuracy on at least an annual basis.
Libraries
Libraries should have appropriate names and descriptions assigned to them.
The names should describe the nature of the answers contained within each library.
The descriptions should further describe the nature of the answers contained within each library so every team member accurately understands what they are viewing when they enter a library.
Libraries that are not populated with content should have (COMING SOON) appended to the library name.
Library owners should represent the SME responsible for maintaining the library.
The justification for a library’s existence should be evaluated on an annual basis.
Libraries should be decomissioned when their existence is no longer justified.
Libraries should have a decomissioned date, which should be communicated through the library description. Example:
***This library is set for decommissioning on YYYY/MM/DD*** Description of Library
The decomissioned date should be 30 days after a library is determined to be unjustified.
GitLab conducts Quarterly Business Reviews during the first month of every quarter to review performance and lessons learned from the prior quarter, review forecasting, and prioritize requests that will help in future sales activity. In the spirit of Transparency and Collaboration, the Field Security participates in the QBR process to gather information and recommendations for future security related concerns.
Process
As part of the Field Manager QBR Roll Out schedule, Field EBAs will send a calendar invitation to the Field Security Team. Based on availability, members of the team will sign up for various QBR sessions.
Field Security team members will intake any security-related concerns or issues.
A summary issue is shared to relevant stakeholders for consideration. As applicable, security concerns may be added to the Annual Field Security Study.
Field Security observations and OFIs should have the following characteristics:
Contain enough detail for any team member to gain a fundamental understanding of what is being reported
What was identified?
Who was the prospect, customer, competitor, etc. that lead to the identification?
When was this identified?
How does this currently impact GitLab, or how could this impact GitLab in the future?
Why is this important, and why should we allocate resources towards it?
What can we do to remediate the problem, improve the solution, or position ourselves to take advantage of the identified situation?
Be assigned to the appropriate team member for triage
Have a proposed due date
This can be based on a clear deadline (e.g. the date a new regulation goes into effect), or it can be an estimate based on the perceived level of effort required to implement a solution.
Be material in nature. For example, these identifications may:
Result in a financial impact for GitLab
Be the result of a new or updated compliance obligation for GitLab
Result in a competitive advantage for GitLab
Help us better support customer requests and expectations
One of Field Security’s critical missions is to impact the broader security industry through thought leadership. As the leader in DevSecOps and a key player in the security industry, GitLab is working on ensuring its internal security expertise is leveraged to improve security standards.
How ?
Field Security’s goal is to take a holistic approach to security outreach. We want to be dynamic and transcend traditional methods of gathering and sharing information.
One of Field Security’s critical missions is to improve internal and external awareness of GitLab’s security practices and the security of our platform. As we continue to iterate and grow, we must improve our ability to engage and impact prospects and customers in a meaningful way.
The Sales organization is a central part of this initiative. They have the critical role of selling GitLab and being trusted advisors to customers and prospects alike. From a security perspective, this role is critical from two angles:
If you would like to request security collateral which are under NDA, (such as SOC 2 Type 2, Pentest executive summary, etc.) please visit the Trust Center and click on the request access button at the top right-hand corner.
The above are for GitLab Team Members only. Customers should contact their GitLab Account Owner to initiate their requests. If a customer doesn’t know their Account Owner or does not yet have an assigned Account Owner, they can contact the sales team. Once you have submitted the issue, it is now in our queue and will be assigned to one of our Field Security Engineers when it is next up (please see SLA’s listed below).
GitLab contracts with third parties to conduct annual network and application penetration testing and perform continuous public security scanning (BitSight). Evidence of these are shared via our Customer Assurance Package.
Third Party Security Ratings
BitSight is a third party security rating platform that utilizes public information collected across multiple domains to provide a numeric score from 250-900 (similar to a credit rating, but security focused). GitLab publishes three reports using BitSight:
The knowledge base is a library of question and answer pairs related to GitLab, Inc. and the GitLab solutions. The knowledge base is a living library that is updated and expanded by questionnaires from our prospects and customers. These questionnaires are related to efforts such as RFx requests, third party risk assessments, and supplier due diligence requests. The knowledge base is designed to serve both Field Security and all other team members.
If a customer, or potential customer, has questions related to Product, Marketing, Legal and/or Environmental, Social and Governance (ESG)–including for renewals or during an active term–please follow the Request for Proposal (RFP) Process below.
Request for Proposal (RFP) Process
The Field Security Team, Legal & Corporate Affairs, Field Ops and Sales have created a process to assist and simplify the Request for Proposal or Information process for the Field Team. With regards to RFP’s, the Field Team should follow the below steps:
One of Field Security’s critical missions is to improve internal and external awareness of GitLab’s security practices and the security of our platform. As we continue to iterate and grow, we must improve our ability to engage and impact prospects and customers in a meaningful way.
Security evangelism allows us to develop a better understanding of our prospects’ and customers’ “needs” and “wants”, and it allows us to better position ourselves to provide them with a valuable product and service.
Do you have 120 seconds to learn more about the Trust Center?
GitLab offers Trust Centers tailored to customer needs
GitLab.com page:
This page provides detailed security information to prospective and existing GitLab.com SaaS and self-managed customers for completing vendor security assessments.
