As a member of the security team at GitLab, you will be working towards raising the bar on security. We will achieve that by working and collaborating with cross-functional teams to provide guidance on security best practices.
The Security Team is responsible for leading and implementing the various initiatives that relate to improving GitLab's security.
The Security Engineer is a grade 6.
The Senior Security Engineer role extends the Intermediate Security Engineer role.
A Senior Security Engineer may decide to pursue the security engineering management track at this point, should they wish to. See Engineering Career Development for more detail on the tracks available for Senior Engineers.
The Senior Security Engineer is a grade 7.
The Staff Security Engineer role extends the Senior Security Engineer role.
The Staff Security Engineer is a grade 8.
The Principal Security Engineer role extends the Staff Security Engineer role.
The Principal Security Engineer is a grade 9.
The Distinguished Security Engineer role extends the Principal Security Engineer role.
The Distinguished Security Engineer is a grade 10.
At GitLab, Staff+ individual contributors take on a larger role by driving initiatives that are larger in scope, impact, and value than their current day-to-day responsibilities call for. In order to achieve this, Staff+ engineers are encouraged to choose 1 project, mutually agreed upon with their manager, for which they act as DRI until completion or mutually agreed upon priorities change. The goal is to provide our staff+ team members the following benefits:
Initiatives are selected with the following criteria:
All staff+ initiatives are tracked as epics with the ~"Staff+ Initiative" label in both of our top-level namespaces with corresponding epic boards for global transparency and tracking:
Once an initiative is mutually agreed upon, the team member will be wholly responsible for driving the project. The following project elements should be addressed as applicable:
Time Considerations
The manager and team member should work to define how much time should be allocated towards this initiative. The time allocated should fall within 20 to 40% of the team member's time but will need to take into consideration the impact to the team's day-to-day obligations that may be of higher priority.
Define Objective and Scope of Work
Scope should include systems, services, and tools. The objective should provide a clear description of outlining the problem to be addressed, why this is a problem, what impact or value solving this problem will have, and the cost of not addressing this issue. Note: The more data you can provide in proving value, the more likely you are to succeed. For example, it is better to say “fixing this will result in a reduction of $74,000 in bug bounty spend” vs “fixing this will make us more secure”.
Timebound
The initiative will list a projected start and end date. Ideally, projects would range anywhere from 6 weeks to 6 months. The end date is your educated guess and may change, but leverage the due date to your advantage with your dependencies and stakeholders. Further, this does not need to follow a quarterly cycle meaning it does not need to start at the beginning of a quarter and end on the last day of the quarter. The intent is to start an initiative and carry it to 100% completion. The work is not required to be tracked as an OKR but the team member may choose to create OKR’s if they feel more comfortable with that tracking and reporting style.
Milestones
Project milestones should be well defined. If this is not possible, seek the guidance of your manager to establish proposed milestones they may evolve once the project is underway. This will help team members stay on track and account for progress.
Success Criteria
The project needs to have a well defined exit criteria. This should match with the expected outcome and intent of the project definition. It is ok to recommended further actions to be taken in the future given those are based on insights gained during execution of the initiative and were not part of the original goal.
Stakeholders
The team member should ensure stakeholders are identified, notified, and kept informed throughout the duration of the project. It is the team member’s responsibility to negotiate time and resources with their stakeholders and understand the nuances of stakeholder and team priorities.
Dependencies & Risks
The team member should carefully consider project dependencies and risks ahead of time and how they might impact the project to reduce the likelihood of them and their stakeholders being surprised by significant factors that can derail a project.
Reporting
Tracking and reporting is a necessary component to ensuring visibility and transparency to your stakeholders and other interested parties. This reporting also helps provide guidance for other IC's that want to work towards a Staff+ position within GitLab. Further, this allows for quicker intervention when a project is at risk. The team member should determine the proper cadence and method of communication for their project. Reporting should include project metrics to make it easy to understand status.
Close-out
At the close of the project, the team member should document what goals were met, what was not met, and recommendations for future iterations (if applicable).
Security research specialists are subject matter experts (SME) that conduct research in their area of expertise to protect GitLab the product and GitLab company assets. They are also encouraged to participate in the larger security community through blog posts and participation in industry conferences. Responsibilities for this specialty include:
Application Security specialists work closely with development teams, product managers (PM), and third-party groups (including the paid bug bounty program) to ensure that GitLab products are secure.
Application Security Responsibilities
Application Security Requirements
By leveraging diverse technologies and an automation first approach, the Security Automation team strives towards improving the efficiency, effectiveness, and accuracy within GitLab's Information Security program with a focus on cost savings. Examples include the creation of automated security issue triage and management solutions, automating handling of repetitive tasks, and defining re-usable security automation architectures. Additionally, the Security Automation team will assist other security specialty teams with automation efforts they are leading and developing through the assessment of automation tools, and integration tools and technologies to support automation efforts as needed.
Security Automation Responsibilities
Security Automation Requirements
SIRT Engineers are the firefighters of the GitLab Security Team. As a Security Engineer in SIRT your daily duties will include incident response, log analysis, forensics, tooling and automation development, as well as contributing to strategic improvements to the GitLab products and GitLab.com services. Successful Security Engineers thrive in high-stress environments and can think like both an attacker and defender, have the ability to engage with and mentor more junior Security Engineers, and can help come up with proactive and preventative security measures to keep GitLab and its user’s data safe.
More information about the SIRT role is described in the persona of Alex, SIRT Engineer
SIRT Responsibilities
SIRT Requirements
Trust & Safety Engineers are the builders of the anti-abuse world. They develop the tools needed to monitor, mitigate and report on abusive behavior and are an essential part of our goal to be good internet citizens.
A successful candidate is someone who wants to make the internet a safer place and do the right thing because it’s right.
Your daily duties will include building tooling and automation for curbing abuse, assist with incident response, as well as contributing to strategic improvements to the GitLab products and GitLab.com services.
Trust & Safety Responsibilities
Trust & Safety Requirements
Security Assurance Engineers enable Sales by achieving standards as required by our customers and helping to secure the organization. This includes SaaS, self-managed, and open source instances.
Red Team specialists emulate adversary activity to better GitLab’s enterprise and product security. The role requires the ability to think like an advanced persistent threat. Creativity is key. For example, develop attack plans and stealthily execute them to compromise sensitive information on GitLab.com such as private repos, or develop and distribute malware to GitLab team-members to demonstrate how the corporate enterprise could be compromised.
This role reports directly to the VP of Security. Generally we would see this specialty to be filled at the Distinguished level. Distinguished engineers and Fellows have the widest sphere of influence and responsibility at the individual contributor level and as such may be asked to focus on high impacting focus areas. The security architect is a highly technical role responsible for planning, designing, testing, implementing and maintaining security strategy and solutions across the entire GitLab ecosystem. More specifically the responsibilities of this role include:
All interviews are conducted using Zoom video conferencing software. Candidates for Security Engineer roles can expect the hiring process to follow the order below, with modifications to the process as required, based on specific situations. Please keep in mind that candidates can be declined from the position at any stage of the process. To learn more about someone who may be conducting the interview, find their job title on our team page.
As always, the interviews and screening call will be conducted via a video call. See more details about our hiring process on the hiring handbook.
For more details on the engineering career ladders, please review the engineering career development handbook page.
GitLab Inc. is a company based on the GitLab open-source project. GitLab is a community project to which over 2,200 people worldwide have contributed. We are an active participant in this community, trying to serve its needs and lead by example. We have one vision: everyone can contribute to all digital content, and our mission is to change all creative work from read-only to read-write so that everyone can contribute.
We value results, transparency, sharing, freedom, efficiency, self-learning, frugality, collaboration, directness, kindness, diversity, inclusion and belonging, boring solutions, and quirkiness. If these values match your personality, work ethic, and personal goals, we encourage you to visit our primer to learn more. Open source is our culture, our way of life, our story, and what makes us truly unique.
Top 10 Reasons to Work for GitLab:
See our culture page for more!
Work remotely from anywhere in the world. Curious to see what that looks like? Check out our remote manifesto and guides.