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.
|Marco Lancini||Staff Security Engineer, Infrastructure Security|
|Paulo Pontes Martins||Senior Security Engineer, Infrastructure Security|
To engage with the team:
@mentionanyone. In case you want to mention the whole team, use the
@gitlab-com/gl-security/security-operations/infrastructure-securityhandle on GitLab.com.
#security-infrasecchannel or by tagging us
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:
InfraSec team sync - weekly- Weekly call 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.
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:
We 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:
|~"☁️ 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: