Threat Management sub-department

Maintained by:

Vision
- FY21 Vision
Mission
Sub-department development people leaders
Performance Indicators
Open-source projects
YouTube Playlists
Issue Boards
Delineate Secure and Threat Management
Label Usage
Skills
Engineering Refinement & Planning
Product Documentation Process
Highlights on how we operate
Common Links
- Product Documentation Links
- Slack
How to work with us

The Threat Management engineering sub-department contributes to development in the Sec section.

erDiagram Secure-Stage ||--|{ Static-Dynamic-Composition-Fuzz-And-Vuln-Research-Groups : contains Static-Dynamic-Composition-Fuzz-And-Vuln-Research-Groups }|--|| Secure-Department : reports-to Protect-Stage ||--|| Container-Security-Group : contains Threat-Insights-Group ||--|| Threat-Management-Department: reports-to Container-Security-Group ||--|| Threat-Management-Department : reports-to Secure-Stage ||--|| Threat-Insights-Group : contains

We are responsible for protecting applications, networks and infrastructure from security intrusions via giving users insights into threats at the vulnerability, network, container, operating system, and application layers. Our sub-department consists of all groups in the Protect Stage and the Threat Insights Group in the Secure Stage.

You can learn more about our approach on the direction pages for Secure and Protect.

Vision

Protect our users' applications, services, and infrastructure from the ever-evolving threat landscape.

FY21 Vision

By the end of FY21:

To give our customers increasingly better controls to protect themselves against attacks (and to help drive more revenue from more customers wanting these categories), we should successfully deliver on the maturity roadmap.
All categories have customer use tracking enabled so we can accurately gauge customer acceptance.
The (relatively new) Protect development team is achieving all metrics that all development teams track (MR's per month per engineer, developer to maintainer ratio, etc.)
The sub-department has implemented one significant idea to improve the GitLab architecture overall (such as perhaps a framework and guideline for implementation of services).
The sub-department publishes >=2 blog entries on security trends to inform our customers, prospects, and the security industry as a whole.

Mission

Launch GitLab developed security technologies and integrate open-source projects to provide security controls for customers.

Employ security controls for our customers at the container, network, host, and application layers.

Provide features to allow customers to manage their security risks effectively and efficiently.

For more details, see the Secure stage and Protect stage.

Sub-department development people leaders

Person	Role
Wayne Haber	Director of Engineering, Threat Management and Growth
Lindsay Kerr	Frontend Engineering Manager, Threat Management
Thiago Figueiró	Backend Engineering Manager, Threat Management

Backend

Secure Stage: Threat #Insights

Person	Role
Thiago Figueiró	Backend Engineering Manager, Threat Management
Jonathan Schafer	Backend Engineer, Threat Management, Threat Insights
Mehmet Emin Inac	Backend Engineer, Threat Management, Threat Insights
Michał Zając	Backend Engineer, Threat Management, Threat Insights
Subashis Chakraborty	Backend Engineer, Threat Management, Threat Insights

Protect Stage: Container #Security

Person	Role
Thiago Figueiró	Backend Engineering Manager, Threat Management
Can Eldem	Backend Engineer, Threat Management, Container Security
Zamir Martins Filho	Fullstack Engineer, Threat Management, Container Security
Alan (Maciej) Paruszewski	Backend Engineer, Threat Management, Container Security

Frontend

Person	Role
Lindsay Kerr	Frontend Engineering Manager, Threat Management
Dave Pisek	Senior Frontend Engineer, Threat Management
Daniel Tian	Senior Frontend Engineer, Threat Management
Savas Vedova	Senior Frontend Engineer, Threat Management
Alexander Turinske	Frontend Engineer, Threat Management

Timezones for each team member

Timezone.io

Performance Indicators

Open-source projects

The Threat Management team makes use of a number of open source projects including:

YouTube Playlists

You can find demos of features, recorded synchronous meetings, release kick-offs, public group sessions, and more in the Threat Management playlist:

You can watch the Threat Management Sub-Department playlist below.

Issue Boards

We use the following Workflow Boards to track issue progress throughout a milestone cycle:

Delineate Secure and Threat Management

It is important to delineate who the EM and PM DRIs are for every functionality, especially where this may not be obvious. It is documented on a dedicated delineation page.

Label Usage

In addition to the Workflow Labels Documentation, the labels below are of particular interest to us:

Label	Use
`devops::protect`	All issues related to the Protect Stage
`devops::secure`	All issues related to the Secure Stage
`group::threat insights`	Vulnerability Management, Responsible Disclosure
`group::container security`	WAF, Container Network Security, Container Behavior Analytics
`Category:Vulnerability Management`	subset of `group::threat insights` issues related to Vulnerability Management
`Category:Responsible Disclosure`	subset of `group::threat insights` issues related to Responsible Disclosure
`Category:WAF`	subset of `group::container security` issues related to WAF
`Category:Container Network Security`	subset of `group::container security` issues related to Container Network Security
`Category:Container Host Security`	subset of `group::container security` issues related to Container Host Security

Skills

Because we have a wide range of domains to cover, it requires a lot of different expertises and skills:

Technology skills	Areas of interest
Ruby on Rails	Backend development
Go	Backend development
Vue, Vuex	Frontend development
GraphQL	Various
SQL (PostgreSQL)	Various
Docker/Kubernetes	Threat Detection
Network Security	Container network security
Host Security	Various

We are constantly iterating on our planning process as a team. To maximize our velocity and meet our deliverables, we follow a refinement process for all issues.

Product Documentation Process

As the product evolves, it is important to maintain accurate and up to date documentation for our users. If it is not documented, customers may not know a feature exists.

To update the documentation, follow this process:

When an issue has been identified as needing documentation, add the ~Documentation label and outline in the description of the issue what documentation is needed.
Assign a Backend Engineer and Technical Writer to the issue. To find the appropriate TW, search the product categories.
For documentation around features or bugs, a Backend Engineer should write the documentation and work with the technical writer for editing. If the documentation only needs styling cleanup, clarification, or reorganization, the Technical Writer should lead the work, with support from a Backend Engineer as necessary. The availability of a technical writer should in no way hold up work on the documentation.

Further information on the documentation process.

Highlights on how we operate

We disagree and commit when necessary.
We decide on a Directly Responsible Individual for a project or decision.
We document how decisions are made on which features will be in the secure stage and which will be in the protect stage in order to avoid confusion. (Documentation WIP by product management)
We prefer asynchronous communication (merge request/issue threads) over synchronous communication (meetings). In fact, when we cancel a meeting because everything that would have been discussed in the agenda was handled asynchronously, we cancel the meeting and celebrate by posting "Another One Bites The Dust" in the team's slack channel .

Common Links

Product Documentation Links

Slack

Stage #s_secure
Stage #s_protect
Subdepartment #sd_threat_mgmt and @threat management engineering
Subdepartment #sd_threat_mgmt_leadership
Subdepartment #threat_mgmt_standup
Group #g_protect_container_security
Group #g_secure_threat_insights
#sd_threat_mgmt_frontend and @threat management frontend
#sd_threat_mgmt_backend and @threat management backend
#sd_threat_mgmt_social

How to work with us

Community Contributions are welcome! Please follow these general GitLab intructions but also note the following items specific to the Threat Management sub-department:

We've created this Vulnerability Management: Community Contributor FAQs snippet to answer common questions. This is a living document and we encourage suggestions or additions.
Upcoming Threat Management Community Office hours can be found on GitLab's Community Office Hours shared calendar.
Recordings of previous office hours can be found on our Threat Management Community Office Hours YouTube playlist.

While we love to get contributions from our users in the community, we also strive to attract talents in the Engineer teams of this stage to bring our product to the next level.

Our open positions are listed on the GitLab Careers page.

Threat Management sub-department Office Hours are scheduled fortnightly. Details can be found on the GitLab Team Meetings, Threat Mgmt Sub-Department, and Community Office Hours shared calendars. This is a chance for internal and exteral GitLab contributors to ask questions about topics related to the any of the groups or categories listed above.