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.
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.
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.
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:
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.
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.
| Person | Role |
|---|---|
| Joe Dubail | Manager, Infrastructure Security |
| Marco Lancini | Principal Security Engineer |
| 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 |
To request an infrastructure security review, please create an issue using the security review template
To engage with the team:
@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.#security-infrasec channel or by tagging us @infrasec-team.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:
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:
decision_log templateWe use Epics, Issues, and Issue Boards to organize our work, as they complement each other:
Each project has an owner who is responsible for delivering the project.
The owner needs to:
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 |
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: