It begins immediately after receiving the purchase order.
A project’s progress and current state is determined using the following metrics:
- Source code coverage indicator.
- Percentage of remediated (repaired) security risk vulnerabilities.
are not capable of extracting
sensitive business information,
such as client or employee information.
In our Squad plan service,
we use a series of tools
which are acquired and developed
by us at
as well as a detailed review process
performed by our expert technical staff.
We go the extra mile
because automated tools present
the following problems:
Vulnerability leakages (detection of a minimal percentage of existing security risk vulnerabilities).
Detected vulnerabilities are primarily false positives.
Incapability of combining individual vulnerabilities in order to reveal additional vulnerabilities which may be an even greater security risk than the individual vulnerabilities alone.
The Squad plan hacking
is first performed
on the source code.
This allows for hacking
and development to occur simultaneously,
which in turn minimizes
the dependency on functional environments,
as well as the need for coordination
between hackers and developers.
The decisions regarding
which findings are prioritized
for each sprint rest solely
with the client.
Unless we are dealing
with a company
(Continuous Integration/Continuous Deployment),
not all sprints generate code
eligible for release and deployment,
which improves the remediation (repair) time
for detected vulnerabilities.
Standard Squad plan hacking
95% of all business applications
as the subscription is
based on the number of active developers in the project
and this defines the amount of resources
assigned to the project.
Based on our historical data,
and thanks to our recruitment
and training capabilities,
as well as our ability
to innovate internal processes,
we are fully capable of taking on
10 new applications each month.
The goal is
there will be results
regarding system vulnerabilities
throughout the contract period.
We take into account
all pushes to the tested branch,
which are monitored
using automated scripts (robots)
that extract and analyze
the changes made to the source code
Once the setup has been completed, and everything is ready for the service to begin, the security tests start. The steps are as follows:
Approval request (purchase order confirmed).
Project leader assignment.
The project leader schedules the start meeting (teleconference).
Service condition validation.
Supplies request (access to environments and code).
The project leader receives supplies, and programs the setup of the verification and access robots.
The project leader creates an admin user in
ASMfor the client.
The admin user invites all project stakeholders including the developers. (They must have
Vulnerabilities are reported in
Project stakeholders access vulnerabilities and start remediation.
If any questions or problems arise, they can be addressed through the comments or chat available in
When the client has remediated the reported vulnerabilities, they may request validation of their repairs through
Our hacker performs the closure verification and updates the report.
7are repeated until the subscription ends.
During the execution of a project, the following scenarios can occur:
Application in development without overdue code (
100%coverage): The robot detects the change and generates the updated control files. This means that no specific file or commit is audited, but rather the change analysis performed by the robot is incorporated when the hackers attack the application, thus allowing them to take into account the changes made.
Application in production without overdue code (
100%coverage): Even when there are no changes, the application is attacked. Internally, we have processes that help us identify why we haven’t found vulnerabilities in the application in 7, 14 and 21 days. These processes include such things as hacker rotations or increasing the number of hackers assigned to the project in order to find undiscovered vulnerabilities.
Application in development with overdue code (
<100%coverage): Same as the first scenario, but attacks are only related to the change that was made. The attack surface that existed before the subscription point is not attacked.
Application in production with overdue code (
<100%coverage): Same as the second scenario, but if in a specified month there is no new code, it is hacked only to the extent of the changes made by
oneactive author in