--- description: "Fluid Attacks tests its own technology to ensure the security of its Continuous Hacking solution." keywords: "continuous hacking, Fluid Attacks documentation" other: private: false title: Continuous Hacking to our technology --- # Continuous Hacking to our technology import { Table } from "nextra/components"; 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](https://help.fluidattacks.com/portal/en/kb/articles/continuous-hacking-methodology). All our development projects run [Continuous Integration](https://help.fluidattacks.com/portal/en/kb/articles/developing-for-integrity#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](https://www.openbugbounty.org/bugbounty/fluidattacks/) 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: 1. Fluid Attacks' CLI breaks the build due to new vulnerabilities, guaranteeing they are not passed onto the platform. 1. Fluid Attacks' CI Gate breaks the build due to vulnerabilities with any CVSS score. 1. 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. 1. Fluid Attacks accepts the following vulnerability types permanently due to its use of the cloud: [Lack of protection against deletion - EC2](https://db.fluidattacks.com/wek/257/) and [Traceability loss - AWS](https://db.fluidattacks.com/wek/400/). ## Response to external vulnerability reports 1. Researcher submits a report through [help@fluidattacks.com](mailto:help@fluidattacks.com). 1. A Response Team is assigned, based on availability and the knowledge-set. 1. Response Team responds to 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 Response Team communicates to Researcher why. 1. A severity of the vulnerability is established based on its [CVSS](https://www.first.org/cvss/) score. 1. An issue is created in [Fluid Attacks' bug tracker](https://gitlab.com/fluidattacks/universe/-/issues) 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. 1. Appropriate patches are worked on locally by the Response Team. 1. Patches are reviewed with the researcher. 1. Vulnerability announcement is drafted and a release date if discussed. 1. At the release date: the fix is deployed, and the vulnerability is announced at [Fluid Attacks News](https://news.fluidattacks.tech/), and through e-mail to the affected users if appropriate. 1. The researcher is contacted and asked if they wish for credit. 1. 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: **CVSS v4.0 score** **Time to remediate** Critical (9.0 - 10.0) ≤ 7 days High (7.0 - 8.9) ≤ 15 days Medium (4.0 - 6.9) ≤ 30 days Low (0.1 - 3.9) ≤ 60 days or according to priority

## Monitoring Fluid Attacks monitors that it is remediating vulnerabilities found in its products as follows: 1. Remediation percentage should be above 99%. 1. There should be fewer than ten bugs. Moreover, Fluid Attacks' incident manager ensures that issues are created and closed. ## Requirements 1. [155. Application free of malicious code](https://db.fluidattacks.com/req/155/) ## Other transparency measures 1. [Complaint management ](https://help.fluidattacks.com/portal/en/kb/articles/complaint-management) 1. [Data leakage policy](https://help.fluidattacks.com/portal/en/kb/articles/data-leakage-policy) 1. [Ethics hotline](https://help.fluidattacks.com/portal/en/kb/articles/ethics-hotline) 1. [Help channel ](https://help.fluidattacks.com/portal/en/kb/articles/help-channel) 1. [Incident management and resolution process ](https://help.fluidattacks.com/portal/en/kb/articles/incidents) 1. [Information security responsibility](https://help.fluidattacks.com/portal/en/kb/articles/information-security-responsibility) 1. [Open source](http://Open source) 1. [Quality policy](https://help.fluidattacks.com/portal/en/kb/articles/quality-policy) 1. [Status page ](https://help.fluidattacks.com/portal/en/kb/articles/status-page) 1. [Vulnerability releasing process](https://help.fluidattacks.com/portal/en/kb/articles/vulnerability-releasing-process)