Platform FAQ

Last updated: Nov 4, 2026

---

This section answers frequently asked questions about the platform of Fluid Attacks.

Groups

What is a group?

A group is an independent management unit of an organization on the platform. It has its own access permissions, reports, and policies. Each group has one or more repositories and environments of the evaluated system, and the platform reports their vulnerabilities in the group. Ideally, a group includes all the repositories of the system, such as backend, frontend, and infrastructure as code.

Inside a group on the platform, you can open different sections. The sections that you see depend on your role and your plan. For more information about groups and sections, read the page Know your group section.

Why create several groups?

Fluid Attacks recommends that you create different groups, each for a specific set of repositories and environments of the evaluated system. This makes vulnerability management easier. These are the benefits:

• Independent access: Each group has its own access permissions. Thus, more than one group gives you better access control. A common practice is to create a different group for each work team. Also, the members of your organization can be in more than one group and have different permissions in each group.
• Independent reports: Each group has its own vulnerability reports. This helps when you share them with auditors or other third parties who need the vulnerability management evidence of specific repositories and environments.
• Independent vulnerability management tracking: The platform generates analytics for each group. With them, you know the security status of specific repositories and environments, and how each work team manages vulnerabilities.
• Independent policies: You can set policies at the group level. Thus, they show the criticality of the assessed application, and the CI/CD process of the application applies them.

What is the process behind group deletion?

Amazon Web Services (AWS) manages the group deletion, because AWS gives the architecture of the platform. When you delete a group, the platform sends the request to AWS, and AWS does the rest. AWS has several international compliance and security certifications. Thus, Fluid Attacks trusts AWS to delete client data securely.

Vulnerabilities

What are vulnerabilities?

Security vulnerabilities are weaknesses in IT systems. They usually come from software bugs, design errors, or misconfigurations that do not comply with the cybersecurity requirements. When attackers exploit vulnerabilities, they can get unauthorized access to the system and control of it. Then they can steal information or other assets, or stop operations, among other things.

What is the difference between Age and Last report in the Vulnerabilities table?

Age is the number of days since the first discovery of that type of vulnerability in your software. Last report is the number of days since the last detection of a vulnerability of that type in your software.

How do I suggest that a reported vulnerability is a false positive?

On the platform, select the "False positive request" option as the treatment of that vulnerability.

How can I see only the findings of the dynamic application security testing (DAST)?

In the Vulnerabilities table of a specific vulnerability type, use the Technique filter and select Web DAST, API DAST, or both.

Why is the severity score in the platform lower than in external sources?

Fluid Attacks adjusts the CVSS scores of the known vulnerabilities that SCA finds in your software. The context of your system can lack the conditions that are necessary to exploit these flaws. Fluid Attacks specifies the Exploit Maturity (E) metric as "Unreported" (U), also when there are public exploits or reports of attacks. Thus, the scores are often lower than the scores of external sources, such as the National Vulnerability Database (NVD). For more information about this metric, read CVSS-BT score. For more details, see CVSS score adjustment.

How can I see vulnerabilities specific to a particular Git repository?

In the search bar of the Vulnerabilities table, enter the nickname of the repository. The table then shows only the vulnerabilities of that repository.

Why does Fluid Attacks find vulnerabilities in very old files?

These are some possible causes:

• The subscription started long after the development of the software product started, and you decided not to do a Health Check. In a Health Check, Fluid Attacks pentesters review the old code manually.
• You added an old repository with existing code, and you did not request the related Health Check.
• You requested a Health Check, and Fluid Attacks did it. But the pentesters who assess your code change over time, and the new team found these vulnerabilities only now.

Does Fluid Attacks report the same vulnerability separately for production and other environments?

No. If Fluid Attacks finds a vulnerability in the development, QA, or UAT environment and in production, it reports one vulnerability.

How does the SLA apply if I find an overlooked vulnerability in a production environment?

The accuracy SLA applies as usual. See the criteria in Report false negatives.

Why did security testing under the Essential plan fail to find vulnerabilities?

Essential is a vulnerability scanning plan. Its security testing uses only automated tools. Automated scanning is fast and very scalable. But it has these main disadvantages:

• It finds only 10% to 30% of the total risk exposure of a system. Only manual testing can confirm the rest, for example, business flows that need an environment, authentication, or test data.
• If you configure the scanner to detect more vulnerabilities than that, it reports more false positives than real alerts.

For these reasons, often only the security testing of the Advanced plan can find the vulnerabilities. This plan includes penetration testing as a service, reverse engineering, and secure code review by pentesters that use tools.

What is Fluid Attacks' time to detect?

Fluid Attacks does security testing with its AI-powered automated tools and its team of security experts, because they complement each other:

• Automation is fast but usually detects only a part of the risk exposure. Automated tools cannot identify all vulnerabilities.
• Manual testing takes longer, but it gives more complete detection. It is available only in the Advanced plan. To make this process better, Fluid Attacks uses AI to predict high-risk files and review them first.

Fluid Attacks does not give a formal SLA for detection time, but it gives a 90% accuracy SLA. This SLA covers false positives and false negatives. If you find unreported vulnerabilities, tell Fluid Attacks about them.

The window of exposure is more important than the time to detect. The window of exposure is the time that a vulnerability stays without remediation, and it defines the real risk. To help you make this window smaller, Fluid Attacks gives GenAI-guided remediation and Talk to a Pentester sessions for more complex issues.

What influenced the duration it took to detect the vulnerability?

The Fluid Attacks solution tests in parallel with the development process. But some situations can make the detection time longer:

• There was no Health Check in an application with earlier development.
• The tests ran in the wrong branch or environment. Thus, changes accumulated, and the commits got to Fluid Attacks late.
• Key resources, such as credentials or permissions, were missing, and the tests started late.
• The vulnerabilities are zero days in third-party software that the vendor disclosed only recently. Continuous testing of applications is necessary to identify these threats as soon as they appear.
• Human error can sometimes cause delays. To prevent them, Fluid Attacks uses an AI tool that helps its experts review high-risk files first. Fluid Attacks also rotates its pentester teams for different reviews, and has teams that discard possible false positives and search deeper to reduce false negatives.

How to evaluate the suitability of a security provider?

Measure the performance of a security provider with F-Scores. F-Scores include the legitimate findings (TP), the rework for engineering teams (FP), and the overlooked risk (FN). This illustration shows the definition of these metrics.

Now use the image below as an example to compare the results of three providers. If you compare only the TP, you can correctly say that A has a better performance than B. But it is an error to say that C is better than A. C reports two times the number of TP of A, but it also reports two times more FP.

The F-Score model measures the performance of tools or providers accurately. The F2 Score alone (see the formula in the note below) gives an accuracy percentage (based on vulnerability quantity) of 36% for tool A and 34% for tool C. This shows that a comparison based on the number of FP is misleading and can cause much more rework with no result. The Fluid Attacks Advanced plan gives a 90% accuracy SLA. Fluid Attacks measures it with the F2 score and the F0.5 score, which focuses more on risk than on quantity.

Does Fluid Attacks explain how to remediate a vulnerability?

The IDE extension and the platform of Fluid Attacks give details about vulnerability remediation. They have a feature that uses generative artificial intelligence to create remediation guides. These guides show developers the steps of different remediation options. The guides are not always precise, and a developer who knows the context of the system must validate them. But the guides are an excellent start to fix the issues.

Nobody at Fluid Attacks is authorized to give remediation recommendations. Advanced plan users have an exclusive help option to talk with a Fluid Attacks pentester about the detected vulnerabilities.

Can I talk in detail with someone at Fluid Attacks about the detected vulnerabilities?

Yes, but only with the Advanced plan. Any user on the client side, including vendors, can request a meeting to clarify a vulnerability with the Talk to a Pentester feature. The Fluid Attacks persons who attend these meetings can explain the risks of a vulnerability clearly and help your organization fix it. For complex vulnerabilities, the Talk to a Pentester representative can invite the security analysts who found the vulnerability. But the Talk to a Pentester expert is still the best person to guide these discussions.

How does Fluid Attacks make sure that it checks a vulnerability of version X again in later versions Y?

Successive versions of an application share most of their functions. Thus, when a new version is available, a reported vulnerability stays open in the platform by default. Its status changes only after verification. The verification has two possible paths, which depend on how Fluid Attacks reported the vulnerability.

• Deterministic automated tools (SAST, DAST, SCA, SS, CSPM, MAST, CS). Each time these scanners run, they verify if the reported vulnerabilities still exist. A developer can change part of the file, and the reported line can move. The scanner considers that change, so that it does not close the vulnerability incorrectly and then open it again.
• AI-based automated tools and manual reports (AI SAST, SCR, PTaaS, RE). For these sources, a user on the client side requests a re-attack from the platform, and this starts the internal review. For AI SAST, the scanner does the verification. For manual testing, a pentester does it.

What evidence or metrics show that the security testing process keeps pace with releases with no loss of coverage or quality?

The accuracy SLA is part of the Fluid Attacks contracts. You can see it at any time in the organization-level view of the platform, without a report request.

Fluid Attacks does not use coverage. A method can test every file and still miss a critical vulnerability. Coverage shows what the tests covered, but it does not show the quality of the tests. The accuracy SLA measures what Fluid Attacks missed: the false negatives in your systems and versions, weighted by severity and balanced against the false positives.

The primary result metric is a severity-weighted F2 score. It gives more importance to false negatives in different systems and versions. It does this with more weight for the severity of each missed vulnerability.

Research shows that statistical prioritization of the attack surface is more effective to find critical vulnerabilities. These models identify the areas with the highest risk and put intensive tests on them. You can measure the quality of a security test only after the test. This measurement needs historical results from different systems and versions. A false negative (FN) occurs when an in-scope vulnerability was present during a previous test, but the test did not detect it.

A process that tries to reduce FNs can produce more false positives (FPs). An F-score measures the balance between these results. Fluid Attacks uses the F2 score because it gives more weight to recall and FN reduction. The calculation also considers the severity of each FN, not only the total number of FNs.

A severity-weighted F2 SLA is the main measure of security testing maturity. If the testing process obeys this SLA in successive releases, it keeps pace with them and keeps its quality. Other metrics measure only specific process activities and do not measure the final result.

Security testing

How does Fluid Attacks approach security test coverage?

The Fluid Attacks solution promises a result, not coverage.

Fluid Attacks puts together deterministic automated testing, AI-driven detection, and pentesting teams. It promises the result of that combination: a 90% accuracy SLA on the systems under evaluation (Advanced plan). The design of the process makes that commitment possible. It has three independent sources of vulnerability detection, and algorithms decide where the manual teams test next.

Fluid Attacks uses different approaches for automated and manual techniques. When the required CLI integrations are active, automated techniques scan 100% of the applicable files written in supported languages. Manual techniques and AI-SAST use statistical risk prioritization instead of file coverage as their operating objective. Coverage describes the tested scope. It does not measure how effective the detection is.

Automated tests can run at several points in the software development life cycle (SDLC):

• Developer environment: Developers can install the Fluid Attacks CLIs for SAST, SCA, SS, MAST, DAST, CS and CSPM on their workstations.
• CI/CD pipeline: The same CLIs can run before you merge a change into a long-lived branch and before you promote a build to production.
• Pull request: The PR Assistant runs SAST, SCA, and SS on the code changed by each pull request.
• Platform: When you merge changes into the branch of the registered repository.

The CI/CD integrations provide centralized security controls. They do not depend on each developer to start the tests, and they keep a record of the findings in the CI/CD pipeline. If you configure them to fail the build, they can block a change before it reaches a protected branch or production.

Together, these controls apply automated testing at multiple SDLC stages. They scan all applicable code and help detect and stop vulnerable changes before production.

Manual techniques and AI-SAST run on the platform in parallel with your development, on the latest version. They never stop your development. They use a risk-based approach. Statistical models identify the systems and components that require the most attention. The AI-SAST prioritization model uses the probability that a snippet has a specific vulnerability. The manual prioritization models use factors such as these:

• The number of changes in the system
• The size of each change
• The time of each change
• The files with the most changes
• The number of recent authors
• The system's vulnerability history compared with other systems
• The historical ratio of critical to non-critical vulnerabilities
• Other relevant risk indicators

The models continuously select the systems and areas that independent attack teams must test. These manual teams include Systems, Criticals, Escapers, Deterministic, and Reattack. Based on the assigned risk priority, one or more teams can test the same system at the same time to find new vulnerabilities.

How does security testing align with frequent system releases?

Fluid Attacks monitors the latest commit on the branch that the customer gives. When the latest commit changes, Fluid Attacks rescans the complete repository. Build, packaging, versioning, tagging, and deployment occur later in the customer's Continuous Deployment process. A CI Gate can apply the platform's policies to control which tested commits move to production.

The customer selects the branches included in the testing scope. Fluid Attacks monitors these branches for changes. When it detects a change, it clones the repository and starts the testing.

After the tests, the customer decides if they do these tasks:

• Compile the tested code
• Package the build
• Store the artifact in a binary repository
• Assign a version number
• Promote the artifact to production

These activities occur after the security tests and remain the customer's responsibility.

Fluid Attacks recommends that you install the CI Gate at the release stage of the CI/CD pipeline. The gate checks the remediation policies defined in the ASPM. If the release does not meet these policies, the gate blocks its promotion to production.

The customer is also responsible for release versioning and tagging. Fluid Attacks recommends standard versioning practices and a Git tag for the exact commit that goes to production.

In the recommended process, you build a production release from a tested and tagged commit, and the CI Gate evaluates it. The in-scope branch and tagged commit serve as the source of truth. Each binary artifact has an exact link to that source.

What traceability mechanisms identify the evaluated versions and the versions with vulnerabilities during the development cycle?

Fluid Attacks tests the latest version of every component that you give. Fluid Attacks does not produce a version-by-version assessment. For source code, that means the latest commit on the branch you provide. For web and API environments, the deployed version. For mobile, the binary you upload. For cloud, the live state of your infrastructure through the API.

What evidence you get. The platform connects each vulnerability to the artifact where Fluid Attacks found it. The artifact is different for each asset type:

• Source code repositories: The specific commit.
• Mobile applications: The uploaded binary version.
• Cloud environments, web, and APIs: The evaluated target environment and the timestamp of the review.

For all asset types, each vulnerability in the platform shows these data:

• Its location in the target environment or root directory
• Its report date
• Its current status (open or closed)
• The full history of requested and verified re-attacks, including the rejected ones

With this information, your team can identify where and when Fluid Attacks detected a vulnerability, and close it. This information is not an audit trail of evaluated versions with a rating for each version.

Evidence

How many pieces of evidence (images and videos) do I have access to?

The limit is six files (images or videos). But Fluid Attacks updates these files continuously with the reattacks or the new vulnerabilities that it reports.

Scope

What is a nickname?

A nickname is a term that a team gives to a repository or set of credentials to find or identify it more easily.

Where can I find my repository's nickname?

You can find it in the Git Repositories table in the Scope section.

What does the scope of the solution include, and what does it not include?

The scope of Fluid Attacks includes a vulnerability in one of these two conditions:

• Fluid Attacks has access to the repository and branch of the vulnerability before someone writes the vulnerable code.
• Fluid Attacks has access to the repository and branch of the vulnerability after someone writes the vulnerable code, and you request the solution.

All other scenarios are outside the scope. These are some examples:

• You register an environment, but not its source code.
• You register an environment, but it does not match the registered source code.
• An application uses a vulnerable service insecurely. You register the source code of the application, but not the source code of the service.

How many branches does Fluid Attacks test?

When you use the CLI and the platform, you can test an unlimited number of branches for each repository. But some repository registration rules of the platform apply:

Repository registration rules

The following rules apply to active repositories within an organization. Inactive repositories do not count toward these rules.

1. A repository cannot appear more than once in the same group.
2. A repository can appear in multiple groups, as long as each registration uses a different branch.
3. A repository + branch combination cannot appear more than once in the organization.
4. A repository can have at most one Advanced plan registration in the organization. There is no such limit for Essential plan groups.

Note: An inactive repository still blocks a new registration in one case: an inactive registration in the same group with the same repository + branch. This is intentional. The way to test that combination again is to activate the existing registration, not to create a duplicate.

The platform validates these rules each time that you register a repository, move roots, activate an inactive one, or change the plan of a group. If an action breaks a rule, the platform blocks it and shows an error that describes the conflict. The error shows the name of the conflicting group only if you are a member of that group.

For more information, see Branch testing coverage.

How many environments does Fluid Attacks test?

Fluid Attacks tests two environments for each repository, if one of them is the production environment. Fluid Attacks needs the credentials for both environments.

What are the risks of testing production environments, and how does Fluid Attacks manage them?

Production tests carry some risk. Fluid Attacks manages each of these risks with specific controls:

• Service interruption: Fluid Attacks controls the intensity and pace of every test and does not use unauthorized brute-force or high-load techniques. The risk to the availability of your application is minimal. If a test could affect availability, Fluid Attacks first runs it in a non-production environment. Fluid Attacks also notifies you through an event and asks for a suitable time slot before any test that could affect availability. If a test needs evidence from the production environment, Fluid Attacks requests your authorization first.
• Data loss or corruption: The Fluid Attacks methodology prefers non-destructive techniques and runs these tests in pre-production environments first. Fluid Attacks agrees with you in advance on any test that could alter important production data and that needs evidence.
• Exposure of confidential information: Fluid Attacks handles credentials, production test data, and findings under strict confidentiality controls. These controls include encryption and access limited to the assigned team. Fluid Attacks shares all information through the platform, under the confidentiality agreement already in place between the parties.
• Performance degradation: Fluid Attacks monitors the behavior of your system during the full test and adjusts or pauses the test immediately if it observes any impact.
• False security alerts: Fluid Attacks always tests from its own IP addresses. If a test generates a false alert on your WAF or SOC, Fluid Attacks is available to help you resolve it.
• Damage to code or configurations: Fluid Attacks does not change your production configurations. Fluid Attacks excludes any action that could have that effect from the test scope, unless you and Fluid Attacks agree on it in advance. If a pentester has any doubt during a test, the pentester stops the test.

Does Fluid Attacks test production environments only to verify vulnerabilities in pre-production ones?

No. Fluid Attacks tests production environments completely.

Why test production environments if you can test QA instead?

QA usually cannot reproduce the production environment exactly. If Fluid Attacks cannot analyze production, this can be a problem. For example, the tests can miss a vulnerability. Then it is not clear if the tests had a fault, or if the analyzed environment was different from production. Most importantly, when you test software in production, you secure its functions in the state that malicious attackers probably target. Fluid Attacks tests this environment at no more cost.

Can I remove a repository from the platform?

Yes. Use the deactivation option in the Scope section. After the deactivation, Fluid Attacks no longer has the repository clone. But for security and compliance reasons, the platform keeps a full audit trail. This audit trail is a record of all the activities, including scan results and detected vulnerabilities.

Nobody can remove the history of the repository, its tests, and its vulnerabilities. That would be the same as erasing an event from an official log, which goes against standards and best practices.

With the deactivation function, you remove the repository clone and stop the Fluid Attacks tests in that repository. The function also marks its 'Open' vulnerabilities as 'Closed'. Thus, you can manage vulnerabilities with Fluid Attacks only in the repositories that you select, and the platform keeps a complete and secure history.

Does Fluid Attacks test the security of email servers?

Not at this time. But Fluid Attacks plans to add a full vulnerability analysis of email servers with a multilayered approach, as described in the corresponding GitLab issue.

Does Fluid Attacks test low-code applications?

No. The methodology requires source code in a Git version control system, and low-code platforms do not give this capability.

Reattacks

How many hours do I have to wait for a response to a reattack request?

According to the service-level agreement, 90% or more of reattack requests get a first response in a median time of less than 8 office hours.

How do I request a reattack?

You can request a reattack from the Vulnerabilities and To-do sections. Select the vulnerability that you want to verify again. Then click the Reattack button. The selected vulnerability shows the "Requested" status in the Reattack column for up to 8 office hours. Examine the Comments section for any new comments on the reattack.

How do I know that a requested reattack is in progress?

Make sure that the Reattack column in the Vulnerabilities section shows the "Requested" status for the vulnerability that you want to verify again. You can also look in the Comments section for comments about the request.

Why can I not request a reattack?

The platform blocks a reattack only when both of these are true:

• The current commit of the registered branch is the same as the commit that the platform tracks for that vulnerability.
• That commit is 1 day old or more.

The platform never blocks a new commit on the registered branch, however recent it is.

Examine these reasons, in this order:

1. Wrong branch. Compare the branch where you pushed your fix with the branch registered for that repository in the Scope section. If they are different, the platform cannot see your fix yet.
2. Repository not synchronized. In the Scope section, look for errors in the last clone of the repository.
3. No new changes. Make sure that the current commit of the repository is different from the last commit that the platform analyzed. If it is the same commit and less than 1 day old, wait until it reaches 1 day. Or push a new change to that branch.

If you still have problems with the reattack request after you examine these reasons, contact [email protected].

Security testing certificates

How do I generate a service certificate?

In the Vulnerabilities section, click the Generate report button and select the Certificate option. This option is not available if the Business Registration Number and Business Name fields are empty in the Information section. These roles can download certificates: Group Manager and Vulnerability Manager.

Reports

How do I generate the vulnerability report?

In the Vulnerability section, click the Generate report button and select the type of report that you want to download: technical or executive. These roles can download reports: Group Manager and Vulnerability Manager.

What is the difference between executive and technical reports?

The executive report is a summary report in PDF format, usually for persons in management roles. It has short and clear information about the vulnerabilities of the group. The technical report is an XLSX file with all the vulnerabilities of the group and their technical details.

What security requirements does Fluid Attacks verify?

Fluid Attacks verifies compliance with many security requirements. It classifies them in these categories:

• Architecture
• Authentication
• Authorization
• Certificates
• Credentials
• Cryptography
• Data
• Devices
• Emails
• Files
• Legal
• Logs
• Networks
• Privacy
• Services
• Session
• Social
• Source
• System
• Virtualization

Members

What is the difference between members and authors?

Members are all the users who can access your group to see information or manage vulnerabilities, scope, and tags, among other things. Authors are all the developers, professionals, or bots who contribute to the repositories under evaluation.

Comments

What is the difference between the two comment alternatives?

Comments is one of the channels that Fluid Attacks uses to communicate with users. It is in the Vulnerabilities and Events sections. Use the Vulnerabilities comments when you have questions about a specific vulnerability. Use the Events comments to ask about the status or details of situations that stop the security testing.

Treatments

Why does a vulnerability status still show "Vulnerable" when I accepted it permanently?

When you accept a vulnerability permanently, your organization accepts the risk of not fixing it. But the vulnerability still exists, and your software still has it.

What happens when a temporary acceptance treatment expires?

In this case, the treatment of the security issue becomes "Untreated" again. The platform assigns the remediation to the user who requested the temporary acceptance.

Policies

If I apply policies to a group, will these apply to all its repos?

Yes. Group policies apply to all the repositories of that group.

What is the difference between policy at the organization level and the group level?

Organization policies are the policies that you set globally. All the groups of the organization inherit them. Group-level policies, let you change these policies for specific groups.

CI Gate

Must I only install Docker to run the CI Gate from my local machine?

Yes. For more information, read Install CI Gate to break the build.

Does Fluid Attacks' CI Gate run locally or on the development infrastructure?

You can run it both ways.

Does the CI Gate work without an Internet connection?

No. CI Gate must connect with the Fluid Attacks API.

How many arguments can I use to run the CI Gate of Fluid Attacks?

You can use more than one argument.

How often is it advisable to do "docker pull" to update the image?

You select the frequency. Do it each week or each month.

In what mode does the CI Gate of Fluid Attacks not break the build?

In "lax mode," the opposite of "strict mode."

Must all team members use the same token to run the CI Gate in a group?

Yes. To get the token, go to the DevSecOps section in Scope.

Do CI Gate executions fail in the case of service unavailability?

CI Gate executions fail only if the service is totally unavailable. CI Gate can operate when the API availability is intermittent, because it tries the executions again. The 99.95% availability SLA of Fluid Attacks guarantees the service availability.

Platform problems

What can I do if I do not see information when I enter the groups?

Do these steps:

1. Log out of the platform.
2. Delete the cache and cookies of your browser.
3. Log in again.
4. Enter the groups that have the problem.

What can I do if I cannot access the platform?

Open the platform in incognito mode or in another browser, and see if the problem continues. Look at the status page for known outages that affect other users. If only you have the problem, send an email to [email protected].