Testing our technology

Last updated: Nov 4, 2026

---

Fluid Attacks has projects that test its own software. For Fluid Attacks, it is essential to be an example of secure software. Thus, Fluid Attacks applies its full solution to all its technology stack. All the development projects of Fluid Attacks run continuous integration pipelines, including exploits and strict linters. These pipelines help to keep known vulnerabilities out of production. Also, Fluid Attacks runs a bug bounty program to keep the security and privacy of its websites at the highest level. All people can participate in the bug bounty program. A monetary award, based on the impact of the vulnerability, encourages people to find vulnerabilities and report them responsibly.

Security gates

Fluid Attacks tests its own projects with automated and manual techniques. It configures these security gates from the platform:

• The CLI of Fluid Attacks breaks the build because of new vulnerabilities. This guarantees that these vulnerabilities do not get to the platform.
• In the pipeline of Fluid Attacks, the CI Gate runs in each pipeline of a development branch and reports vulnerabilities with any CVSS score. In this pipeline, the CI Gate does not break the build.
• Fluid Attacks accepts these weaknesses permanently because it uses the cloud: Lack of protection against deletion - EC2 and Traceability loss - AWS.
• The engineering team of Fluid Attacks can temporarily accept vulnerabilities while it develops a remediation patch. The team can accept each vulnerability a maximum of two times. Each acceptance period is a maximum of 30 days (a maximum of 60 days in total). The team must remediate all vulnerabilities in the times that the Time to remediate policy defines.

Response to external vulnerability reports

1. The researcher submits a report through [email protected].
2. Fluid Attacks assigns a response team, in accordance with availability and knowledge.
3. The response team answers the researcher and asks for the necessary information to make sure that the report is a vulnerability. If it is not a vulnerability, the team tells the researcher why.
4. The response team uses the CVSS score to set the severity of the vulnerability.
5. The response team creates an issue in the GitLab project of Fluid Attacks. It prioritizes the issue in accordance with its severity. If applicable, users get a notification about the vulnerability with any steps that they must do. The notification does not include details that can show an exploitation path.
6. The response team works on the applicable patches locally.
7. The response team reviews the patches with the researcher.
8. The response team writes the vulnerability announcement and discusses a release date with the researcher.
9. On the release date, the response team deploys the fix. Then, it announces the vulnerability on Fluid Attacks News and, if applicable, by email to the affected users.
10. The response team contacts the researcher and asks if they want credit.
11. Fluid Attacks holds internal meetings to analyze the incident. Then, it takes any actions that can isolate its code base, prevent similar incidents, decrease future incidents, or improve future responses.

Time to remediate

Fluid Attacks defined these remediation times by vulnerability severity, as industry standards and frameworks recommend, for example, PCI DSS and NIST:

Monitoring

Fluid Attacks monitors the remediation of vulnerabilities in its products as follows:

• The target remediation percentage is more than 99%.
• The target is fewer than ten bugs.

Also, the Incident Manager of Fluid Attacks makes sure that the team creates and closes the issues.

Requirement

This Fluid Attacks requirement applies to the controls on this page:

155. Application free of malicious code

Other transparency measures

• Complaint management
• Data leakage policy
• Ethics and compliance hotline
• Help channel
• Incident management
• Information security responsibility
• Quality policy
• Status page
• Vulnerability releasing