Vulnerability Management Process
This page describes how Rocket.Chat fixes vulnerability in its products and it is divided as follows:
- Vulnerabilities Data Source shows what are the places we collect vulnerabilities from.
- The process of vulnerability management describes what is the current flow for a given vulnerability.
- Participants in this process shows the schedule we put together to make engineers to fix vulnerabilities.
Today we have 8 vulnerability data sources where we gather the information that we need to manage our vulnerability management process. These sources are tools or manual analysis that can be generated by our internal offensive security team, external researcher or third-parties that we hire on an annual basis to help us identify possible vulnerabilities.
Here are some of our current vulnerabilities data source:
- 1.Tenable.io (Infra)
- 2.Trivy (Container)
- 3.Kube-hunter (K8s clusters)
- 4.Hackerone (External environment)
- 5.Internal Pentesting (Applications + infrastructure)
- 6.Snyk (Applications)
- 7.Third-parties companies (Applications + Infrastructure)
- 8.Prowler (AWS environment)
When we're dealing with manual reporting like hackerone, internal pentesting or third-parties companies our offensive security team takes action to analyze the data that has been generated to triage and check if it makes sense for our current situation and if the vulnerability is confirmed then we add in our internal pipeline to be handled.
If the vulnerabilities come from tools, we have implemented an integration where some of the tools are connected with our internal process management (Jira) platform where the vulnerabilities are automatically added to the list when a scanner finds it. This process is still being improved and our goal is to have every scanner integrated with our vulnerability list to avoid manual process of getting vulnerabilities from the scanner and add to Jira automatically, avoiding the possibility of losing any vulnerability in the process.
Given a vulnerability (regardless if it was found manually or with a tool's support) the first step is to perform the triage of the vulnerability and to decide whether the vulnerability is a code issue or a dependency problem that we have in our project. Being a code issue, the development of the fix starts with one of the developers that is part of the rotation program (detailed later in this page). After the developer fixes the issue, there is a step related to the security team to perform an initial test on that fix. If the issue is fixed, a code review is performed by another developer or by a member of the Architecture group at Rocket.Chat. Only after that the QA team is able to perform a validation of the functionality, also making sure that no other functionality is broken.
Once we make sure the vulnerability is fixed and is release as part of our release process, we also take actions to publicly disclose the vulnerability as well as update our hall of fame with the name of the researcher, if that was the case.
Figure 1 - Vulnerability process at Rocket.Chat
Today we use Jira as our main tool to manage our current vulnerability management process and inside this tool we have a kanban board that contains as columns the steps described above.
Participants in this process
The following are the ones who participated in the whole process of fixing vulnerabilities:
Security team: The offensive team is responsible for managing the sources of vulnerabilities and to perform their triage. They are also responsible for moving the Jira tickets through the majority of the columns of the board.
Architecture Team: Architects are responsible for providing guidance to developers on how to fix a specific vulnerability from a code understanding and perspective.
Engineers: The software engineers are the ones who are going to fix the vulnerabilities with inputs from the architecture and security team members. Engineers also review fixes from each other.
QA: QA Engineers are responsible for testing if the solution has fixed the vulnerability as well as making sure that no other functionality of the product has been affected.
Rotation schedule for fixes
Week | Frontend | Backend |
|---|---|---|
14-Nov-2022 | Tiago Evangelista | Luciano Pierdona |
21-Nov-2022 | Tiago Evangelista | Luciano Pierdona |
28-Nov-2022 | Tiago Evangelista | David Alen |
5-Dec-2022 | Tiago Evangelista | David Alen |
12-Dec-2022 | Yash Rajpal | David Alen |
19-Dec-2022 | Julia Forresti | David Alen |
26-Dec-2022 | Holidays | Holidays |
2-Jan-2023 | Pedro Rorato | Matheus Barbosa |
9-Jan-2023 | Pedro Rorato | Matheus Barbosa |
22-Feb-2023 | Gabriel Henriques | Rafael Tapia |
Rocket.Chat thanks each one who participated in this process of making our products even more secure.
Last modified 30d ago