This page is inspired by GitLab’s own application security review process. The goal of application security reviews is to proactively identify and address vulnerabilities in Rocket.Chat-developed or deployed applications, reducing risk and supporting the company's mission success.

Security reviews shouldn’t be seen as a proof or certification that the code / application being developed is secure. They are a best effort review, and additional vulnerabilities may exist even after the code / application is assessed.

Types of Security Review

At Rocket.Chat, an application security review may include any or all of the following:

• Threat modeling.

• In-depth code review.

• Dynamic testing.

These reviews do not impede the development of the application or feature under evaluation. As a result, the development teams will not be affected and can continue their work without interruption.

After such a review is conducted, the security vulnerabilities found, if any, will be triaged and tracked following our Vulnerability Management process.

Threat Modeling

Threat modeling aims to proactively identify and address potential security threats within an application or system design before they can be exploited. This process involves assessing the architecture, identifying vulnerabilities, and understanding how an attacker might target the system. By anticipating risks and mitigating them early in the development lifecycle, we reduce exposure and strengthen the company's overall security posture.

Architecture diagrams and dataflow diagrams play a crucial role in threat modeling by providing a clear visual representation of system components and data flows, making it easier to identify areas of concern. They are, however, optional and we can still perform threat modeling with non-visual materials such as an Architectural Decision Record (ADR).

Methodologies like STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege) offer a structured approach to analyzing potential threats. Additionally, other frameworks, such as DREAD and PASTA, can be used to further refine the process and ensure comprehensive risk analysis.

Our current threat modeling process can be seen here.

Code Review

Although the security engineer responsible for code review can use automated tools - like SAST -, this review should be mostly manual. When reviewing code, the engineer will look for issues such as:

• Lack of input validation.

• Lack of access control.

• Authentication-related vulnerabilities.

• Possible injection attacks.

• Misconfiguration.

• Vulnerable dependencies.

The review can be conducted either on a specific pull request (PR) or across the entire repository, depending on the objectives. For instance, if the goal is to identify a particular type of vulnerability in the codebase, the reviewer will evaluate the entire repository.

Dynamic Testing

Dynamic testing requires a running environment for the application and/or new feature to be fully operational. During this process, a security engineer interacts with the system while monitoring and analyzing traffic through tools like OWASP ZAP or Burp Suite. These tools help identify potential vulnerabilities by simulating real-world attacks and uncovering security weaknesses. In essence, dynamic testing shares many similarities with traditional web application penetration testing.

Frequently Asked Questions (FAQ)

What should generally be reviewed?

• Major features / major changes.

• Features known to have had vulnerabilities in the past.

• Features that handle sensitive data - e.g., healthcare data.

• Features that relate to cryptography and/or data protection solutions.

• Features related to authentication and/or authorization.

When security reviews should happen?

• When the security team sees an opportunity to improve the security of a feature or application that is either being developed or already deployed. As an example, a vulnerability reported in pentest reports or on HackerOne may trigger a more comprehensive security review.

• When an engineering manager or product manager involved in the development of a new feature or application understands a security review would benefit its development.

• When the developer working on a feature that is under development or has already been deployed is concerned about security issues and vulnerabilities that could arise.

How to request a security review?

• You can approach any of the security engineers on open.rocket.chat - you can check who is part of the security team by clicking here.

• You can send a message on #rocketchat-security on open.rocket.chat.

• You can send an email to security@rocket.chat.

What should be provided?

To help security engineers perform a review faster, it’s recommended to provide any or all of the following:

• Context of the changes being made - e.g. what is the component being developed, why, and so forth.

• Any documentation - including diagrams - that may help provide a clear understanding of the feature and its use cases.

• Information regarding the type of data that is being processed and/or stored, if applicable.

• Your security concerns regarding the given feature or application.

• A test environment, if applicable.