Field Security Team
Governance and Field Security team charter
Field Security Team
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:
Metrics and Measures of Success
Security Impact on Net ARR
Ayoub Fandi, @ayofan, Senior Security Assurance Engineer, Field Security
Joe Longo, @jlongo_gitlab, Manager, Governance and Field Security
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.
- GitLab Issues
/gitlab-com/gl-security/security-assurance/field-security-team
- Email
security-assurance@gitlab.com
- Slack
- Group Handle
- Primary Slack Channels
#sec-fieldsecurity
#sec-assurance
Feedback and the Future of Field Security
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.
References
Overview 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.
Reports are considered Internal
Frequency Annually during Q4
What is AnswerBase? AnswerBase is an internal only library of question and answer pairs related to GitLab, Inc. and the GitLab solutions. AnswerBase 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. AnswerBase is designed to serve both Field Security and all other team members.
Purpose 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.
Are you looking for GitLab’s Customer Assurance Package?
GitLab Customer Assurance Package (Click Here!) Do you have 180 seconds to learn more about the CAP? GitLab offers Customer Assurance Packages tailored to customer needs Community Package: The first step on the trust journey, this package is a compilation of publicly available documentation designed to introduce GitLab’s approach to security. Directly available from the Customer Assurance Package page. All the documents in the Community Package are included in the Customer Packages.
Overview 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.
Purpose This guide is designed to establish the quality expectations for observatiions and OFIs identified and documented by Field Security.
Scope This quality guide covers observations and OFIs identified by Field Security through customer assurance activities in accordance with GitLab’s observation management program.
Quality expectations 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?
Why a security sales training program? 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.
Submit a Request! Questionnaire or Customer Call Request CAP Request Contract Review Request
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).
Overview 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:
Request for Information / Details If a customer, or potential customer, has questions related to Product, Marketing, Legal and/or 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.
Why do we evangelise? 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.
Vendorpedia Vendorpedia (a OneTrust tool) is an internal only tool that functions as:
An internal knowledge base with a comprehensive list of question and answer pairs in the form of answer libraries. This functionality is used to power AnswerBase A tool for automating aspects of Customer Security Assessments and RFP completion. AnswerBase AnswerBase is an internal only library of question and answer pairs related to GitLab, Inc. and the GitLab solutions.