Testing our technology

Last updated: Jun 12, 2026

---

We have projects focused on testing our own software. It is essential for us to be an example of secure software. Therefore, our entire technology stack goes through comprehensive Continuous Hacking. All our development projects run continuous integration pipelines, including exploits and strict linters, to ensure that no known vulnerabilities are released to production. Additionally, we run a bug bounty program to ensure the highest security and privacy of our websites. Everyone is eligible to participate in the bug bounty program, and people are encouraged to find and responsibly report vulnerabilities through a monetary award based on the impact of the vulnerability.

Security gates

We test our own projects through automated and manual techniques and configure the following security gates from the platform:

• Our CLI breaks the build due to new vulnerabilities, guaranteeing they are not passed onto the platform.
• Our CI Gate breaks the build due to vulnerabilities with any CVSS score.
• We accept the following weaknesses permanently due to our use of the cloud: Lack of protection against deletion - EC2 and Traceability loss - AWS.
• Our engineering team may temporarily accept vulnerabilities while a remediation patch is being developed. Each vulnerability may be accepted a maximum of two times, with each acceptance period limited to 30 days (up to 60 days in total). All vulnerabilities must be remediated according to the timelines defined in the Time to remediate policy.

Response to external vulnerability reports

1. The researcher submits a report through [email protected].
2. A response team is assigned, based on availability and knowledge set.
3. The response team responds to the researcher and makes inquiries to satisfy any needed information and confirm if the report is indeed a vulnerability. If it is not a vulnerability, the team communicates to the researcher why.
4. The severity of the vulnerability is established based on its CVSS score.
5. An issue is created in Fluid Attacks' GitLab project. and prioritized according to its severity. If appropriate, users are notified of the vulnerability, including any steps for them to take, but without any details that could suggest an exploitation path.
6. Appropriate patches are worked on locally by the response team.
7. Patches are reviewed with the researcher.
8. The vulnerability announcement is drafted and a release date is discussed.
9. At the release date, the fix is deployed, and the vulnerability is announced at Fluid Attacks News and through email to the affected users if appropriate.
10. The researcher is contacted and asked if they wish for credit.
11. Internal Fluid Attacks meetings are held in order to analyze the incident and take any actions that can isolate our code base, prevent similar incidents, reduce future incidents, or improve future responses.

Time to remediate

We have defined the following remediation times based on vulnerability severity as recommended by industry standards and frameworks, such as PCI DSS and NIST:

Monitoring

We monitor that we are effectively remediating vulnerabilities in our products as follows:

• Remediation percentage should be above 99%.
• There should be fewer than ten bugs.

Moreover, our Incident Manager ensures that issues are created and closed.

Requirement

The following Fluid Attacks requirement applies to the controls described on this page:

155. Application free of malicious code

Other transparency measures

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