Testing our technology

Last updated: Mar 5, 2026

We have projects focused on hacking our software. It is essential for us to be an example of secure software. That’s why our entire technology stack goes through a process of 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

Fluid Attacks tests its own projects through automated and manual techniques and configures the following security gates from the platform:

• Fluid Attacks’ CLI breaks the build due to new vulnerabilities, guaranteeing they are not passed onto the platform.
• Fluid Attacks’ CI Gate breaks the build due to vulnerabilities with any CVSS score.
• Fluid Attacks’ engineering team may accept vulnerabilities temporarily while they work on a patch. Each vulnerability can be accepted only once and for up to 60 days.
• Fluid Attacks accepts the following vulnerability types permanently due to its use of the cloud: Lack of protection against deletion - EC2  and Traceability loss - AWS .

Response to external vulnerability reports

1. The researcher submits a report through help@fluidattacks.com.
2. A response team is assigned, based on availability and the 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’ bug tracker  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

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

Monitoring

Fluid Attacks monitors that it is remediating vulnerabilities found in its products as follows:

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

Moreover, Fluid Attacks’ incident manager ensures that issues are created and closed.

Requirement

155. Application free of malicious code 

Other transparency measures

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