Young hacker smiling

We hack your software

zero false positives

Attacking Applications, APIs, Mobile Apps Servers, Networks, IoT Devices
ICS: Industrial Control System
SOC: Security Operations Center

Frequently asked questions

Frequently asked questions about Continuous Hacking.

  1. What is Continuous Hacking?

    Continuous Hacking is a security testing service that allows hacking process to begin at an early stage in the software development cycle. Its purpose is to guarantee 100% testing coverage of the application.

  2. What are the benefits of Continuous Hacking?

    Continuous Hacking:

    1. Minimizes the cost of remediation (repair) of a vulnerable security risk while the software is in development rather than when it is in production.

    2. Reduces application certification time to zero because the hacking is done during development.

    3. Provides clear and detailed information about vulnerable security risks and facilitates a coordinated effort between external project personnel (Fluid Attacks experts) identifying security risks, and internal project personnel (client company) fixing security issues without delays.

  3. What are the necessary inputs and requirements for Continuous Hacking?

    The necessary inputs and requirements are

    1. Phase 1: Access to the integration branch of the repository for the, not-yet deployed, application’s source code. Ethical Hacking focuses on the source code.

    2. Phase 2: When the project has a deployed application (Integration Environment) the hacking coverage expands to include application security testing.

    3. Phase 3: This phase applies only if the infrastructure supporting the application is defined as code and kept in the integration branch of the repository referred to in Phase 1. This phase includes infrastructure hacking.

  4. What type of hacking is included in Continuous Hacking?

    Continuous Hacking includes source code analysis, application hacking (see question 3), and infrastructure hacking (see question 3).

  5. What is a vulnerability?

    A vulnerability is anything that represents a security risk (Integrity, Availability, Confidentiality, Non-repudiation) to the application.

  6. If I expect or want to exceed the monthly limit can I increase it?

    Yes, the limit can be increased for any particular month or, in general, for the duration of the project.

  7. Does Continuous Hacking use a series of automated tools

    or is it the result of a manual (by hand) process?

    Automated tools, by themselves, are not capable of extracting sensitive business information, such as client or employee information. Continuous Hacking uses a series of tools acquired and developed by Fluid Attacks and a detailed review process performed by our expert technical staff. We go the extra mile because automated tools present the following problems:

    1. Detection of a minimal percentage of existing security risk vulnerabilities.

    2. Detected vulnerabilities are primarily false positives.

    3. Incapable of combining individual vulnerabilities in order to reveal additional vulnerabilities which may be an even greater security risk than the individual vulnerabilities alone.

  8. If Continuous Hacking includes a manual review how does Fluid Attacks

    ensure that development cycles are not slowed down?

    Continuous Hacking is first performed on the source code. This allows for parallel hacking and development simultaneously. This minimizes the dependency on functional environments and the need for coordination between hackers and developers. The client prioritizes detected vulnerabilities. The decisions regarding what findings are prioritized for each sprint rest solely with the client. Unless we are dealing with a company with daily CI/CD (Continuous Integration/Continuous Deployment) not all sprints generate code eligible for release and deployment, which improves the remediation (repair) time for detected vulnerabilities.

  9. If Continuous Hacking is done manually how can a big project move rapidly

    and expand as more developers join the team?

    Standard Continuous Hacking (at 10,000 deltas per month) covers 95% of all business applications being developed. If a big project expands, the standard limit of 10,000 deltas per month can be revised upward as needed. (see question 7).

  10. If Continuous Hacking is done manually how does it move rapidly

    when a client has a big application portfolio that is constantly increasing?

    According to Fluid Attacks historical data, recruitment and training capabilities, and our ability to innovate internal processes, Fluid Attacks is fully capable of taking on between 5 and 10 new applications each month.

  11. Does the cost of Continuous Hacking vary according to the scope

    or development phases?

    No, there is a fixed cost for Continuous Hacking during the contract period. However, if during your contract period the calendar year changes from one year to the next there will be an increase in cost to reflect rising business costs. This increase will be stated in your contract and agreed upon before you sign it; there will be no hidden costs.

  12. Why is it necessary for Continuous Hacking to have access

    to the source code stored in the repository?

    Continuous Hacking needs access to the source code because it is based on continuous attacks on the latest version available.

  13. When does Continuous Hacking begin?

    Continuous Hacking begins immediately when Fluid Attacks has access to the source code and repository.

  14. Is it possible to hire On-the-Premises Continuous Hacking?

    No. Due to the operational model that supports Continuous Hacking it can only be done remotely.

  15. Is it possible to schedule follow-up meetings?

    Yes. All applications covered by the contract for Continuous Hacking are assigned to a specific project leader who is available to attend all necessary meetings. We simply require sufficient notice of an impending meeting in order to schedule availability.

  16. How is a project’s progress determined?

    A project’s progress and current state is determined using the following metrics:

    1. Source code coverage indicator.

    2. Percentage of remediated (repaired) security risk vulnerabilities.

  17. When does Continuous Hacking end?

    Continuous Hacking is contracted for a minimum of 12 months and is renewed automatically at the end of the 12 month time period. Continuous Hacking ends when we receive a written request through previously defined channels to terminate the contract.

  18. Can the contract be canceled at any point in time?

    You can cancel your contract at any time after the fourth month. Cancellation can be requested through any communication channel previously defined in the contract.

  19. When the coverage of my application reaches 100% is Continuous Hacking

    suspended until new code is added to the repository?

    No. Even if 100% of coverage is reached, we continue checking already attacked source code to identify any possible false negatives, including components developed by third parties in our hacking process.

  20. How is the severity and criticality of the vulnerability calculated?

    Fluid Attacks uses the CVSS (Common Vulnerability Scoring System), an international standard using a “standardized framework used to rate the severity of security vulnerabilities in software.” It gives us a quantitative measure ranging from 0 to 10, 0 being the lowest level of risk and 10 the highest and most critical level of risk based on the qualitative characteristics of a vulnerability.

  21. How do I get information about the vulnerabilities found in my application?

    Continuous Hacking has an interactive reporting platform called Integrates. Integrates gives all project stakeholders access to details concerning vulnerabilities reported by Fluid Attacks.

  22. What types of reports does Continuous Hacking generate?

    Continuous Hacking generates and delivers, through Integrates, a technical report available in Excel and/or PDF format during the execution of the project contract. Once the project ends, Integrates delivers a presentation and an executive report also in PDF format.

  23. What happens after Fluid Attacks reports a vulnerability?

    Once Fluid Attacks reports a vulnerability, the main objective, for developers, is to eliminate it. Through Integrates a client company’s developers can also access first-hand detailed information regarding a vulnerability in order to plan and execute corrective measures to remove it from the application.

  24. How does Fluid Attacks know a vulnerability

    has been eliminated or remediated?

    Through Integrates any user with access to the project can request verification of a remediated vulnerability. A request for verification that a remediated vulnerability no longer poses a risk must be accompanied by notification from you that the planned remediation has been executed. Then Fluid Attacks performs a closing verification to confirm the effectiveness of the remediation. Results of the closing verification are then forwarded to the project team by email.

  25. How many closing verifications are included in Continuous Hacking?

    Continuous Hacking offers unlimited closing verifications.

  26. Why do I need to notify Fluid Attacks that a remediation has been executed

    if you already have access to the source code repositories?

    One of Continuous Hacking’s objectives is to maintain clear and effortless communication between all project members. This is accomplished when you notify Fluid Attacks because the message goes through Integrates and by doing so, the entire project team is notified.

  27. What happens if I do not consider something a vulnerability?

    Within Integrates there is a comment section. A client company can post its reasons for believing a vulnerability finding is not valid. Then, Fluid Attacks experts and all other project members can interface and discuss the relative merits of the vulnerability finding and the validity of it as a security risk, and a final determination can be made.

  28. Do all reported vulnerabilities have to be remediated?

    No. However, this decision is made entirely by the client, not by Fluid Attacks, and the client assumes all responsibility for possible negative impacts of non-remediation. In Integrates, under the treatment option, a client company indicates whether it will remediate or assume responsibility for an identified vulnerability.

  29. If a client decides not to remediate a vulnerability, thus assuming

    responsibility for it, is it excluded from the reports and Integrates?

    No. Reports and Integrates include information regarding all vulnerabilities, along with whether vulnerabilities were remediated or not. Your report and Integrates will include all the information with nothing excluded.

  30. If the application is stored along multiple repositories,

    can they all be attacked?

    Yes, with one condition. The code must be stored on the same branch in each repository. For example: If it is agreed that all attacks will be performed on the QA branch, then this same branch must be present in all of the repositories included for Continuous Hacking.

  31. If I have code that was developed a long time ago,

    is it possible to still hire Continuous Hacking?

    Yes, it is still possible to use Continuous Hacking. There are two possible options available:

    1. A Health Check can be performed testing all existing code. Then, Continuous Hacking is executed as usual within the defined scope (see question 11). This option is better suited for applications under development.

    2. Start with the standard limits (see question 10) increasing the coverage on a monthly basis until 100% is reached. This option is better suited for applications no longer in development.

  32. Do the repositories need to be in a specific version control system?

    Continuous Hacking is based on using GIT for version control. Therefore, GIT is necessary for Continuous Hacking.

  33. Does Fluid Attacks keep or store information

    regarding the vulnerabilities found?

    Information is only kept for the duration of the Continuous Hacking contract. Once the contract has ended, information is kept for 7 business days and then deleted from all Fluid Attacks information systems.

  34. Does Continuous Hacking require any development methodology?

    No. Continuous Hacking is independent of the client’s development methodology. Continuous Hacking test results become a planning tool in future development cycles. They do not prevent the continuation of development.

  35. Will Fluid Attacks periodically do presentations via teleconferencing?

    How do I set one up?

    Yes. Fluid Attacks can schedule periodic presentations via teleconferencing. To set up a teleconference presentation you will need to provide us with the emails of attendees, and 3 optional time periods of 1 hour duration for the teleconference. We will then notify you of the best time for the teleconference based on your availability and ours. And, we will send emails to your list of attendees inviting their participation.

  36. Does the development of the test in the continuous model

    depends on the type of repository where the code is stored?

    No, the client can use the repository he deems appropriate. Fluid Attacks only requires the access to the integration branch and its respective environment.

  37. Are property rights lost if Fluid Attacks reviews the source code?

    No, allowing to review a creation or work as it is a code to a third party does not grant any rights over it.

  38. Does Fluid Attacks have a tool that allows automation

    over the closing tests in the found vulnerabilities?

    Yes, Fluid Attacks has Asserts, an engine that allows to automate security checks once they have been found in an exploratory phase. Asserts operates directly in the JOB of continuous integration and has the ability to break the build sent by the programmer in case of breach of security requirements. Asserts runs on any continuous integration platforms that support dockers like JOB, for example: VSTS, GitLab, Jenkins.

  39. Is Continuous Hacking focused only over source code?

    It is possible to include the infrastructure associated with the app?

    Fluid Attacks has evolved the Continuous Hacking model and infrastructure now can be included within the Target of Evaluation (TOE). This include the ports and the inputs of the application. In fact, in this evolution, you can subscribe a technological infrastructure (ports) or an application under the Continuous Hacking model.

  40. Where does Integrates run?

    The platform Integrates runs in the cloud.

  41. Does Fluid Attacks manages the access credentials to Integrates?

    No, we use the concept of federated authentication, that is, both Google and Azure (Microsoft 360) are the ones who actually validate your credentials.

  42. Is it possible to activate double authentication token?

    Yes, it is possible. In fact we recommend to activate double token authentication to increase the security level of your credentials in order to avoid unauthorised access by third parties over your information. This feature is enabled from Gmail or Azure depending on your case.

  43. What procedure has Fluid Attacks to catch up with the revision

    of the existing code before starting the hacking process?

    Fluid Attacks recommends that both the development of the application and the hacking process start at the same time. However, this does not always happen. To do this, we have an activity called HealthCheck that allows to catch up the security inspections when the development has begun earlier.


Service status - Terms of Use