Continuous Hacking to our technology | Fluid Attacks Help

Continuous Hacking to our technology

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 is 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.
  2. Fluid Attacks' CI Agent breaks the build due to vulnerabilities with any CVSS score.
  3. Fluid Attacks' engineering team may accept vulnerabilities temporarily while they work on a patch. Each vulnerability can be accepted only one time and for up to 60 days.
  4. 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. Researcher submits a report through help@fluidattacks.com.

  2. A Response Team is assigned, based on availability and the knowledge-set.

  3. 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.

  4. A 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. Vulnerability announcement is drafted and a release date if discussed.

  9. At the release date: the fix is deployed, and the vulnerability is announced at Fluid Attacks News, and through e-mail 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:

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%.
  2. 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

Other transparency measures

  1. Complaint management
  2. Data leakage policy
  3. Ethics hotline
  4. Help channel
  5. Incident management and resolution process
  6. Information security responsibility
  7. Open source
  8. Quality policy
  9. Status page
  10. Vulnerability releasing process