GitLab Professional Services
Accelerate your software lifecycle with help from GitLab experts
Popular GitLab use cases
Enterprise Small Business Continuous Integration (CI/CD) Source Code Management (SCM) Out-of-the-box Pipelines (Auto DevOps) Security (DevSecOps) Agile Development Value Stream Management GitOpsGitLab Professional Services
Accelerate your software lifecycle with help from GitLab experts
Popular GitLab use cases
Enterprise Small Business Continuous Integration (CI/CD) Source Code Management (SCM) Out-of-the-box Pipelines (Auto DevOps) Security (DevSecOps) Agile Development Value Stream Management GitOpsThe Threat Management engineering sub-department contributes to development in the Sec section.
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.
Protect our users' applications, services, and infrastructure from the ever-evolving threat landscape.
By the end of FY21:
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.
Person | Role |
---|
Person | Role |
---|
Person | Role |
---|
Person | Role |
---|
The Threat Management team makes use of a number of open source projects including:
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.
We use the following Workflow Boards to track issue progress throughout a milestone cycle:
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.
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 |
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.
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:
~Documentation
label and outline in the description of the issue what documentation is needed.Further information on the documentation process.
@threat management engineering
@threat management frontend
@threat management backend
Community Contributions are welcome! Please follow these general GitLab intructions but also note the following items specific to the Threat Management sub-department:
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.
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.