Threat Management sub-department

1. You are here:
2. Handbook
3. Engineering
4. Development Department
5. Threat Management sub-department

Maintained by:

On this page

• Vision
  • FY21 Vision
• Mission
• Sub-department Members
  • Backend
    • Secure Stage: Threat #Insights
    • Protect Stage: Container #Security
  • Frontend
  • Timezones for each team member
• 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 Secure & Protect sections.

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 Members

The following people are permanent members of this sub-department.

Backend

Secure Stage: Threat #Insights

Protect Stage: Container #Security

Frontend

Timezones for each team member

Timezone.io

Performance Indicators

• Threat Management Sub-department performance indicators
• Threat management OKRs

Open-source projects

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

• Kubernetes
• ModSecurity Web Application Firewall
• OWASP ModSecurity Web App Firewall Rule Set
• Cilium Network Policies for Kubernetes
• Falco Cloud-Native runtime security
• AppArmor operating system and application policies

YouTube Playlists

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

• Threat Management Sub-Department
• Threat Management Community Office Hours
• Protect: Container Security
• Secure:Threat Insights Features & Demos

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:

• Threat Insights group
• Container Security group

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:

Skills

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

Engineering Refinement & Planning

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:

1. 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.
2. Assign a Backend Engineer and Technical Writer to the issue. To find the appropriate TW, search the product categories.
3. 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 primarily rely on asynchronous communication. However, we will rely on synchronous communication (such as fast boot or similar) when asynchronous communication is not proving to be effective to make a 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

• Threat Management subdepartment calendar
• Secure stage calendar
• Protect stage calendar
• Secure and Protect Glossary of Terms

Product Documentation Links

• Protect
• Web Application Firewall with ModSecurity
• Network Policies with Cilium
• Install Cilium Network Policies
• Security Dashboard
• Standalone Vulnerabilities
• Securing your deployed applications

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 Jobs page: Select "Threat Management" Under "Engineering", then "Developement".