Infrastructure Security Overview

Team Identity

Mission

GitLab’s Infrastructure Security team is responsible for the planning, execution, and support of proactive initiatives specific to the security of GitLab.com. Its core mission is to become Infrastructure Department’s stable counterpart in Security. This is achieved by sharing the SRE view of GitLab.com, but with a strong security focus. Infrastructure Security’s engagements take place in the form of infrastructure change reviews, SaaS infrastructure access & permissions models, cloud security best practices, operating system security, security monitoring at the host and container level, vulnerability management, and patching policies.

Further details can be found in the job family description.

Vision

We both drive and support the improvement of the security posture of GitLab.com’s underlying infrastructure. We operate cross-team and cross-department with relevant stakeholders to provide the required support and help them secure infrastructure. We engage in both ongoing and upcoming endeavor, supporting existing business operations as well as business expansion.

Team Scope and Distinction

The team’s mission overlaps with that of several other teams. That being said, it is important to understand how and where these overlaps take place, and how it all fits together.

Infrastructure Security & Infrastructure Department

The Infrastructure Department is focused on availability, reliability, performance, and scalability efforts of GitLab.com. The fast pace that’s intrinsic to running a rapidly growing SaaS can often prove challenging to secure - operational issues, technical & security debt, rapid implementation of new technologies, all present serious security risks that could impact the success of the SaaS in the long run. This is where Infrastructure Security comes into play by serving the Infrastructure Department in 2 specific modes:

• As an internal consultancy to help review and challenge decisions from a security standpoint (i.e. how to improve the security of k8s, what to log, what approach to take to access production environments in a secure and auditable way …)
• As an external enabler to simplify security nuances for all the teams and provide smooth engagement to make it easier for all the teams to be better at Infrastructure Security.
  • By contributing to security improvements and enhancements for the different codebases.
  • By building and maintaining tools to improve the audit, detection and response capabilities.
  • By working with the teams in defining policies and procedures to support decision making from an Infrastructure Security perspective.

The role of the Infrastructure Security team can hereby be compared to the role of the Application Security team - the latter helps with the quality of the code, while the former helps with the quality of the infrastructure.

Infrastructure Security & Security Incident Response Team - SIRT

The Security Incident Response Team - SIRT has historically been the catch-all for most security issues at GitLab. As a result, over the years, SIRT ended up being a temporary owner for many non-SIRT responsibilities. With the introduction of Infrastructure Security, some of these responsibilities have been shifted to this new team. Good examples of some of these responsibilities are vulnerability management and security monitoring.

SIRT’s goal is detection and response of anomalies and security events - on the SaaS and on the corporate side of GitLab. As such, SIRT is a very strong partner to Infrastructure Security.

Team Members

Person	Role
Julie Davila	VP, Product Security (interim InfraSec manager)
Paulo Pontes Martins	Staff Security Engineer, Infrastructure Security
Dhruv Jain	Senior Security Engineer, Infrastructure Security
Matt Morrison	Senior Security Engineer, Infrastructure Security
Uday Govindia	Senior Security Engineer, Infrastructure Security

Working With Us

To request an infrastructure security review, please create an issue using the security review template

To engage with the team:

1. Create an issue in our issue tracker dedicated to Business as Usual (BAU) activities and general inquiries.
   • It is not necessary to @mention anyone. In case you want to mention the whole team, use the @gitlab-com/gl-security/security-operations/infrastructure-security handle on GitLab.com.
   • You can also chat with us on Slack in the dedicated #security-infrasec channel or by tagging us @infrasec-team.
   • You can also refer to the InfraSec Team Wiki (internal only) for general information about the team and current projects.
2. The team will triage (and prioritise accordingly) all incoming request during the weekly team sync (usually happening on Tuesday).

How We Work

Meetings and Scheduled Calls

Our preference is to work asynchronously, within our project issue tracker as described in the project management section below.

The team does have set of regular synchronous calls:

• A weekly team sync to discuss progress, blockers, and anything related to the InfraSec team.
  • Everyone in the company is welcome to join.
  • The agenda is public within GitLab as well.
• A quarterly team retrospective to reflect on what went well in the previous quarter, and discuss what can be improved going forward.
• 1-1s between Individual Contributors and the Engineering Manager.

Team Pages

• This Handbook Page, which contains general information about the team
• The Internal Handbook, which is the operational source of truth for the team. Everyone is encouraged to check it out for team’s information
• The Infrastructure Security GitLab Sub-Group, which contains EPICs and repositories
• The Infrastructure Security Public Sub-Group, which contains publicly facing resources (e.g., Docker images, etc.)

Decision Log

Decisions worthy of deliberate discussion (to evaluate pros and cons with actual data) are tracked in our Decision Log.

To start discussing a new decision:

1. Create a new issue in the InfraSec Team Charter repo
2. Select the decision_log template
3. Fill the data as requested

Project Management

We use Epics, Issues, and Issue Boards to organize our work, as they complement each other:

• The single source of truth for engineering work is the InfraSec Sub-Group in GitLab. All Epics will be collected at this level.
• Having all projects at this level allows us to use a single list for prioritization and enables us to prioritize work for different services alongside each other.
• Projects are prioritized in line with the Roadmap and with the 🎯 InfraSec OKRs.
• The 🎯 InfraSec Milestones provide a snapshot of the current progress against each quarter.

Team Planning

• For the long term strategy of the InfraSec Team, you can refer to:
  • 📊 InfraSec Roadmap
  • 🎯 InfraSec OKRs
• From a tactical point of view, you can refer to:
  • 🎯 InfraSec Milestones (quarterly)
  • 🗓 InfraSec Epics for this quarter
  • 🎛 InfraSec Initiatives Board (for the tasks we are currently working on)

Project Ownership

Each project has an owner who is responsible for delivering the project.

The owner needs to:

1. Regularly update the status in the Epic description and milestones.
2. Work with others to move project issues through the boards.

Labels

Please use the following labels for project work only:

Label	Use Case
~"☁️ InfraSec"	Team Label (to be included in every project-related issue)
~"InfraSec::triage"	For new issues which need to be triaged
~"InfraSec::this-quarter"	For EPICs committed to the current quarter
~"InfraSec::decision"	For issues to be included in the Decision Log

Design Documents

Before starting a new project, the team is encouraged to define software designs through design docs. These design doc documents the high level implementation strategy and key design decisions with emphasis on the trade-offs that were considered during those decisions.

To start discussing a new design:

1. Create a new MR in the InfraSec Team Charter repo with the Design proposal. You can use this template as a reference for the structure of the Design doc.
2. Fill the data as requested
3. Mark other elements of the team as reviewers

Additional Resources

Onboarding

• Infrastructure Security Team Onboarding Template
• InfraSec Entitlements template