The Squad plan is
a security testing service
that allows the hacking process
to begin at an early stage
in the software development cycle.
Its purpose is to guarantee
100% testing coverage of the application.
Our Squad plan offers Continuous Hacking:
Minimizes the cost of remediation (repair) of a vulnerable security risk while the software is in development rather than when it is in production.
Reduces application certification time to zero because the hacking is done during development.
Provides clear and detailed information about vulnerable security risks and facilitates a coordinated effort between external project personnel (
Fluid Attacksexperts) identifying security risks, and internal project personnel (client company) fixing security issues without delays.
Along our career trajectory we have been working with companies from different sectors, such as financial, transportation, industrial, consumer, communications, technology and utilities.
No. Due to the operational model that supports the Squad plan, it can only be done remotely.
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.
The Sqad plan is contracted
for a minimum of
and is renewed automatically
at the end of the
12-month time period.
the Squad plan ends
when we receive a written request
through previously defined channels
to terminate the contract.
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.
Yes, it is still possible to use the Squad plan. There are two options available:
A Health Check can be performed testing all existing code. Then, the Squad plan is executed as usual within the defined scope (see this question). This option is better suited for applications under development.
Start with the standard limits (see this question), increasing the coverage on a monthly basis until 100% is reached. This option is better suited for applications no longer in development.
that application development
and the hacking process
this is not always possible.
To catch up with developers,
we perform a
(additional fees apply).
This means all versions of the existing code
up to the contracted starting point
in addition to the monthly test limit.
This allows us to catch up
with the development team
within the first
3 contract months.
we continue hacking simultaneously
with the development team
as development continues.
This is a risky choice.
Not performing a Health Check
means there will be code
that is never going to be tested and,
it’s not possible to know
what vulnerabilities may exist in it;
are not going to be identified.
100% of the code change
is going to be tested,
but what cannot be reached,
cannot be tested.
We have improved the Squad plan model
to now include infrastructure
within the Target of Evaluation (
This includes the application’s ports,
and of course
the application itself.
runs in the cloud.
We use federated authentication.
are the entities which validate
your user access credentials.
and we recommend you do so.
Using double authentication
will increase the security level
of your credentials.
This will help prevent unauthorized users
from accessing and compromising your information.
This feature is enabled
- AWS on the cloud (mainly S3 and DynamoDB, all security enabled)
- Hackers' computers with disk encryption in all partitions.
- In this page you can read about how we ensure our clients confidentiality.
It is up to you,
we recommend the use of
for application tests
for source code analysis.
According to the active authors model, it is possible to create a large cell with all the developers or to divide it into applications according to the client’s needs. When managing only one cell, it is important to consider the following:
- All users in the project can see all the vulnerabilities of the application inside the same cell.
- When the same vulnerability appears in several applications, the only way to identify/locate each one in each individual application is by checking the vulnerability report under the heading "location". There, it will specify where each vulnerability can be found.
Yes, you can, under the condition that the new environment be the same branch environment where the source code is reviewed, thus allowing us to test the same version of the change both statically and dynamically.
It is possible to cause an accidental DoS during the hacking service. We recommend including only the staging phase in the scope. However, many clients decide to also include the production stage in the tests. It is unusual for us to take down environments because when we foresee a possible breakpoint, we ask the client for a special environment within which to carry out the test.
The service includes the environment of the reviewed code. It is possible to include different environments for an additional fee.
The analysis grouping the amount of vulnerabilities has the following problems:
- Not all the vulnerabilities have the same severity (CVSS).
- A vulnerabilitiy with severity 10 is not equal to two vulnerabilities with severity 5.
Grouping vulnerabilities by ranges (low, medium, etc) presents the same problems by segmemts as well as additional ones:
- A vulnerabilitiy of 9.9 is not 10% more severe than a 9.0 ("critical").
- Arbitrariness in the segmentation: 8.9 is not critical, but 9.0 is?
- Increases complexity: 4 sets of data non groupable together instead of 1.
For these reasons, the executive analysis based on grouping of vulnerabilities whether grouped without ranges or with them, is not recommended.
To allow grouping of vulnerabilities,
4 ^ (CVSS-4) severity adjustment
is recommended that reflects
the exponential nature
of the severity in each vulnerability:
Reduce the severity of vulnerailities:
a. Little severe
b. Very frequent
Increases the severity of vulnerabilities:
a. Highly severe
a. Analysis aggregated into a single data set.
b. No arbitrary ranges.
c. Reality alined priorization.
- The table shows that vulnerability 10 (row) equals 262,144 vulnerabilities 1 (column).
- A vulnerability 5 (row) equals 16 times the severity of a vulnerability 4 (column).