Manage Roots | Fluid Attacks Help

Manage Roots

In Fluid Attacks' platform, roots are the top-level entry points for security testing. If your group's subscription includes white-box testing, you can add Git roots and Environments to the scope. If it includes black-box testing, you can add IP roots and URL roots.

Manage Git Roots

The list and details of Git repositories that are cloned and subsequently analyzed for vulnerabilities is in the Scope section under the title Git Roots. Within this section, you can add new roots and perform various actions in relation to listed roots, including editing, enabling or disabling them, exporting root data, and excluding subpaths from security testing.

Fluid Attacks assesses only one active repository branch per group, looking for vulnerabilities in one single version of the system. Testing only one branch allows for coherent assessments and makes it easier to keep track of findings and fixes. As a result, your development team can efficiently address reported vulnerabilities, while Fluid Attacks' team can effectively verify the successful implementation of your fixes.  In conjunction with code branch analysis, Fluid Attacks also tests the equivalent environment associated with the provided code branch, ensuring comprehensive security coverage.

Know your Git Roots table

Role requirement info
Role required: User, Vulnerability Manager or User Manager

The table in Git Roots shows the Git repositories included in the scope of security testing.

View Git repositories under testing on the Fluid Attacks platform

Here is a description of the columns of this table:

  • URL: The URL of the repository containing the code that is cloned and tested
  • Branch: The specific branch that is tested (Fluid Attacks assesses only one active repository branch per group)
  • State: Whether the root is in the scope of security testing, where Active means it is undergoing testing, and Inactive means it is not being tested
  • Status: The code repository cloning status, which can be one of the following:
    • Cloning: Repository is being cloned
    • Ok: Repository successfully cloned
    • Failed: Cloning encountered an error
    • N/A: Root is inactive
    • Unknown: Initial status before cloning
    • Queued: A tool run to check this root is queued
  • HCK: Whether Health Check is included for the repository (only groups in the Advanced plan have this field enabled, as Health Check involves manual security testing)
  • Nickname: A name derived from the URL for easy identification of the repository
  • Sync: Initiates a request to reclone the repository when changes have been made and, therefore, an updated version is required

A downward-facing arrow is present to the left of the URL column. Clicking this arrow expands the row to reveal a description for each repository. You can also use the arrows in rows to expand them individually.

Reveal details of the Git root on the Fluid Attacks platform

Note on Root nicknameNote: The root nickname is automatically derived from the URL associated with the added root. Duplicate nicknames are not permitted. If a new root is being added, and its nickname would be one that already exists, four random characters are appended to the URL-associated nickname.

Add a new Git Root

Role requirement info
Role required: User or User Manager

Click the Add new root button to include a code repository to the security testing scope. You can add a new repository using Open Authorization (OAuth) or manually inputting the repository details.

Add a new Git repository on the Fluid Attacks platform

Add Git Roots using OAuth

OAuth enables a streamlined method for adding repositories from popular providers: Azure, Bitbucket, GitHub, and GitLab.

Before adding a Git root in Scope with this method, you must first authorize the connection between the Fluid Attacks platform and the account on the supported provider.

Once you have created the OAuth credentials on the platform, follow these steps to add a Git root in the Scope section:

  1. Click on Add new root and select the code repository hosting provider where you have your repository. For this example, GitLab is used as the provider.
  2. Add new GitLab repository on the Fluid Attacks platform

  3. Upon clicking the provider, a pop-up window prompts you to choose the user credentials corresponding to the OAuth connection for that provider.
  4. Select the Git root credentials on the Fluid Attacks platform

  5. After selecting the credentials, the platform retrieves all relevant data from the associated repositories and their branches. Please note that the loading time may vary depending on the volume of data. Once the data is loaded, the Continue button becomes active. Click it to proceed.

  6. You are presented with a three-step form. First, choose the repository or repositories you wish to add and click on Next step.
  7. Select repos to add via OAuth on the Fluid Attacks platform

  8. Select a specific branch of each repository to test. Confirm your choice by clicking Next step.
  9. Choose branch to test on the Fluid Attacks platform

  10. Specify whether you wish to exclude files from security testing. If you choose Yes, you are asked to provide the paths of specific files or folders to exclude. (You may also exclude files elsewhere, using exclusions as code.)
  11. Exclude files from repos on the Fluid Attacks platform

    Then, specify whether you wish Health Check be performed. That is, whether you wish for code already in the repository to be subjected to manual testing by the hacking team. If you choose Yes, you are asked to accept the additional cost it entails.
    Request Health Check on the Fluid Attacks platform

    If you choose No, you are asked to acknowledge the risks.
    Decline Health Check on the Fluid Attacks platform

  12. Click the Add root button to add the Git repository or repositories.
  13. Add Git root on the Fluid Attacks platform

Add a new Git Root manually

To add a new Git root manually inputting the repository details, follow these steps:

  1. Click Add new root and choose Add manually.
  2. Add Git root manually on the Fluid Attacks platform

  3. You are presented with a form where you need to provide the following information for the repository:
    • URL: The URL where the repository is located
    • Branch: The specific branch within the repository to be tested
    • Connector: Whether the repository is behind a private network and Cloudflare Tunnel is configured
    • Egress: Whether the repository is behind a private network and specific IPs need to be whitelisted on your firewall
    • Existing credentials: If applicable, choose the previously created credentials to access the repository
    • Credential type: The authentication method to be used, identified automatically from the URL:
      • User and password: The traditional login method using your username and password combination
      • SSH: A secure key-based authentication method for accessing remote systems, offering enhanced security compared to passwords
      • Access token: A Personal Access Token for authorizing Fluid Attacks with Azure DevOps.
      • AWSROLE: Allows Fluid Attacks to assume an Identity and Access Management (IAM) role in your AWS account
      • OAUTH: Allows Fluid Attacks to access your repositories on supported platforms (Azure, Bitbucket, GitHub, and GitLab)
    • Name your credential: A name to easily identify the credentials
    • Priority: How importan this root is for your organization; each vulnerability detected in the root is to be assigned priority units accordingly:
      • Low: 25 units
      • Medium: 50 units
      • High: 75 units
      • Critical: 100 units
    • Exclusions: Whether some files or folders should be excluded from security testing, and, if so, their paths (exclusions can also be indicated with code)
    • Health check: Whether you wish Health Check to be performed (i.e., having Fluid Attacks' hacking team manually test existing code)
    Fill out Git root form on the Fluid Attacks platform

  4. Click on Confirm to add the repository.

Existing credentials

Fluid Attacks needs credentials to access the repositories to test. During the process of adding or editing a root, you encounter the field Select an existing repository credential. Clicking on the dropdown menu reveals a list of credentials that have been either used for adding Git roots in the past or previously added on their own in the Credentials section. In any case, they are stored for use across the groups within the organization.

Use existing credentials on the Fluid Attacks platfom

If any of the listed credentials are suitable for the root you are adding or editing, select it. This automatically fills out the Credential type and Name your credential fields.

Choose existing credentials on the Fluid Attacks platform

Credential Type

To add a Git repository within the Scope section, you can provide any of the following authentication methods: user and password, SSH key, Azure Personal Access Token, and cross-account AWS IAM role. The platform identifies the credentials type based on the repository URL you provide.

Add a root with user and password

HTTPS authentication allows you to access the repository by supplying a username and password pair. When you fill out all the fields related to credentials, a button saying Check access appears. Clicking it tells the platform to validate the correctness of the provided access credentials for successful repository cloning. It is advisable to check access and proceed with adding the root only if the message "Success - Access checked!" appears.

Use HTTPS authentication on the Fluid Attacks platform

Note on adding RootsNote: When providing the username and password for a GitHub repository, you must replace the password with a personal token. Refer to the official GitHub documentation for guidance on generating this token.

Add a root with an SSH key

SSH keys establish a connection to your repository server without the need for a username and password. When you choose this credential type when adding or editing a Git root, you are required to provide a private key.

Use SSH key as credentials on the Fluid Attacks platform

Note on SSH keysNote: For instructions on how to set up SSH keys, refer to your code repository hosting provider's official documentation. See, for instance, GitHub's and GitLab's pages.

Add a root with an Azure DevOps PAT

To securely connect Fluid Attacks to your Azure DevOps repositories, you'll need to use a Personal Access Token (PAT). This acts as a unique password, granting specific access rights without sharing your primary account credentials. After generating a PAT with the necessary permissions within Azure DevOps, you can enter it here to enable Fluid Attacks to clone and evaluate your repository.

Use Personal Access Token on the Fluid Attacks platform

Note on Personal Access Tokens
Note: For information on managing your Personal Access Tokens, read the official Azure DevOps documentation.

Add a root with a cross-account IAM role

To seamlessly integrate Fluid Attacks with your AWS environment across multiple accounts, you can leverage a cross-account  Identity and Access Management ( IAM) role. This allows you to establish a role in one AWS account that securely delegates specific permissions to another AWS account, enabling Fluid Attacks to access and assess your resources without requiring direct credentials. Fluid Attacks has published the instructions to create an IAM role in Set up an AWS integration.

Use AWS IAM role on the Fluid Attacks platform

Note on credentialsNote: For information on cross-account resource access, read the official AWS documentation.

Exclude subpaths in Git Roots

Role requirement info
Role required: User Manager

You may decide to exclude specific files or entire folders from the scope of Fluid Attacks' security testing. This could be due to various reasons, such as excluding functional tests or dummy files within your repository. Fluid Attacks' platform provides a mechanism to achieve this. However, it's crucial to note that you may have vulnerabilities in the excluded files or folders excluded and may never find out.
Note on exclusionsNote: There is no restriction on the number of exclusions you can define. Tailor the exclusions to your specific requirements.

To make exclusions, follow these steps:
  1. Access the Scope section of your group.

  2. If your intention is to add a Git repository and define the files or entire folders to exclude, click on Add new root. But if you wish to define exclusions from a previously added repository, click on its URL.
  3. Click on Git repository URL on the Fluid Attacks platform

  4. Identify the following question among the prompts in the pop-up window: "Are there files in your selection that you want the scans to ignore?".
  5. Locate question about exclusions on the Fluid Attacks platform

  6. Choose Yes. A field then appears where you can enter the pattern for the file or folder you wish to exclude. You can keep adding exclusions using the Add another option, or delete them clicking on the corresponding trash can icon.
  7. Exclude subpaths from testing on the Fluid Attacks platform

    Advice on exclusionsIt is advisable to know about pattern usage and exclusion best practices beforehand. Click the question mark icon next to "Specify the folders, files or paths to be excluded" to access reference documentation.
    Caution on exclusions
    Use the wildcard (*) carefully and always try to be as specific as possible.
  8. Click on Confirm to apply the exclusions.
  9. Confirm subpath exclusion on the Fluid
Note on excluding files with open issuesNote: If you exclude files or folders with unmanaged vulnerabilities, please be aware that the Status of those findings does not appear as Safe immediately. You must wait for the next scheduled tool run or request a manual reattack in which Fluid Attacks' tool or hacking team update the Status.

Exclusion examples

  • node_modules/
  • build/tmp/
  • test/*.js (exercise caution when using wildcards) 
  • repo-root/dummy/excludeme.js
Note on exclusions being a case sensitive feature
Note: Keep in mind that exclusion is a case-sensitive feature, which means it distinguishes between uppercase and lowercase letters in the path you provide.

Set exclusions as code

Fluid Attacks' scanner recognizes exclusions specified directly within your application's source code. One way is addinNOFLUID and an explanation as comment before insecure code. Another way is having exclusions specified in a .fluidattacks.yaml file at the root of the project. Read the details in Exclude findings from scan reports.

Import repositories through a CSV file

Role requirement infoRole required: User or User Manager

Prepare the CSV file

You can import multiple repositories for testing via a comma-separated values (CSV) file. This method allows adding up to 1,000 roots.

Ensure your CSV file adheres to the following header format with six columns.

Create CSV file to import repositories to the Fluid Attacks platform

Here is a short description of the information this file must contain:

  • environment: The type of environment corresponding to this root
  • url: The URL of the repository containing the code to be cloned (include the protocol prefix, i.e., https:// or ssh://)
  • branch: The specific branch to be cloned (only one repository branch is assessed per group)
  • includes_health_check: Indicates whether Health Check is requested for the repository (Boolean value, can be left blank if not required)
  • git_ignore: The paths within the repository that you want to exclude from testing (comma-separated list, do not use double quotes, can be left blank)
  • credential_id: The unique identifier for the credentials used to access the repository, which you can obtain by querying the Fluid Attacks API as follows after registering your credentials

  •   query MyQuery {
    organizationId(organizationName: "org_name") {
    credentials {
    id
    name
                type
    }
    }
    }

    Below is an example where you can see the ID within the result.

    Query organization credentials on the Fluid Attacks API
    Note credential type
    Make sure to match the selected credentials type with the URL protocol. For instance, if the URL employs SSH, opt for SSH credentials.

Import the CSV file

Once your CSV file is prepared, follow these steps to import the repositories on the Fluid Attacks platform:
  1. Go to the Scope section and click on the Import button.
  2. Import repositories with a CSV file on the Fluid Attacks platform

  3. In the pop-up window, click on Add file.
  4. Upload CSV file to the Fluid Attacks platform

  5. Select the CSV file and click on Upload.


After clicking on Upload, you receive a confirmation message, and the added Git Roots are visible on the table and start being cloned on the platform.

Advice on import error
If an error occurs during import, it's likely due to your file not adhering to the required format. Carefully review the error message for specific details on the issue and its location within the file. See below the kinds of checks to which the CSV file is subjected.

CSV file checks

When you upload a CSV file to import multiple repositories, it goes through the following checks:

  • Invalid URL or branch: Ensures the provided URL and branch are valid and correctly formatted
  • Prevention of CSV injection: Safeguards against malicious code injection attempts through the CSV file
  • Incorrect characters: Verifies that fields do not contain invalid characters
  • Credentials ID validation: Confirms the validity of the specified credentials ID
  • Avoiding duplicates: Prevents duplicate entries within the CSV file (same URL and branch)
  • Avoiding Root Duplicates: Prevents the import of roots that already exist on the platform

Export Git Roots table

Role requirement info
Role required: User, Vulnerability Manager or User Manager

Click the Export button to download a comma-separated values (CSV) file containing the information displayed in the Git Roots table.

Export CSV with Git repositories on the Fluid Attacks platform

Show or hide columns of the Git Roots table

Role requirement info
Role required: User, Vulnerability Manager or User Manager

The Columns button allows you to show or hide columns in the Git Roots table. Click it, then click on the on/off toggle in front of the column name, and close the window.

Show or hide Git Roots table columns on the Fluid Attacks platform

Filter the Git Roots table

Role requirement info
Role required: User, Vulnerability Manager or User Manager

You can filter the Git Roots table using the options presented after clicking the Filters button.

Filter the Git Roots table on the Fluid Attacks platform

Edit a Git Root

Role requirement info
Role required: User or User Manager

You can modify the specifics of an active Git root (i.e., any one that is inside the scope of evaluation) following these steps:
  1. In the Scope section, locate the active Git root you wish to edit and click on its URL.
  2. Click on Git repository URL to edit on the Fluid Attacks platform

  3. The pop-up window presents three tabs for navigation: Git repository, Environments, and Secrets. Adjust the details as necessary in the Git repository tab.
  4. Edit Git root on the Fluid Attacks platform

  5. Click on Confirm to apply the changes.
  6. Caution when editing URLs and branches
    When altering the repository's URL and branch, a warning message will be displayed, highlighting the potential risks tied to such modifications. Proceed with these changes only after careful consideration.
    Edit URL or branch on the Fluid Attacks platform

Manage Docker images

Role requirement infoA Fluid Attacks staff role is required.

You can add Docker images for Fluid Attacks analyze their software supply chains and find security issues within them.

Create credentials to access Docker images

To allow Fluid Attacks access to Docker images, you need to create username-and-password credentials to allow authentication with the container registry. You may then save these credentials on Fluid Attacks' platform and provide them when adding the Docker images to test. The following steps describe the creation of credentials on Azure Container Registry, but every container registry that allows username-and-password authentication is supported:
  1. Access Container registries from the Azure services list.
  2. Access Container registries on Azure

  3. Access the desired container registry by clicking on its name.
  4. Select container registry on Azure

  5. Locate Tokens under Repository permissions in the menu on the left and click on it.
  6. Find Tokens option on Azure container registry

  7. Click on Add.
  8. Add a token to Azure container registry

  9. Enter a name in the Token field; this is this credentials' username element.
  10. Create token for Azure container registry

  11. Indicate the token's permissions in the Scope map field; for Fluid Attacks' security testing, the '_repositories_pull_metadata_read' configuration suffices.
  12. Set Azure container registry token permissions

  13. Click the Create button at the bottom of the page.

  14. Click on the token in the list to access its Token details page.
  15. Edit Azure container registry token details

  16. To generate a password to be able to use the token, click the corresponding button in the Actions column.
  17. View Azure container registry token details

  18. You can optionally set an expiration date. Then click on Generate and confirm password creation clicking Yes in the pop-up window. Copy the generated password for later use.
  19. Generate token password for Azure container registry
    Warning on password creation
    Do not forget to store your password, as Azure shows it to you just this once.

Add container registry credentials on the platform

After creating the username-and-password credentials in your container registry, you need to save them on Fluid Attacks' platform. Follow these steps:
  1. Access your organization's Credentials section from the collapsible menu on the left side of the screen.
  2. Access the Credentials section on the Fluid Attacks platform

  3. Click on Add credential and choose the Add manually option.
  4. Add credentials manually on the Fluid Attacks platform

  5. In the pop-up window, name the credentials.
  6. Name credentials on the Fluid Attacks platform

  7. Choose User and password as the credentials type.
  8. Use user and password on the Fluid Attacks platform

  9. Provide the credentials.
  10. Create user and password credentials on the Fluid Attacks platform
    Advice on Repository user field
    Note that the Repository user field in this example screenshot is filled with the token shown in the images above in the example with Azure.
  11. Click on Add.

Add Docker image

To add a Docker image for software supply chain security management, you need to do so associating it with an active Git root. Follow these steps:
  1. In the group's Scope section, locate the Git root of your interest and click on its URL.

  2. In the pop-up window, switch to the Docker Images tab.
  3. Find the Docker Images tab on the Fluid Attacks platform

  4. Click on Add Docker image.
  5. Find Add Docker image option on the Fluid Attacks platform

  6. Provide the required information, including the existing credentials to authenticate with the registry.
  7. Add Docker image on the Fluid Attacks platform
    Advice on existing credentials
    Note that the existing credentials chosen in this example screenshot are those created in the above example of saving credentials to the platform.

  8. When you are done, click Confirm.
Note on Dockerfile document
Note: For the image to be analyzed, it is necessary that it includes a Dockerfile document.

Deactivate a Git Root

Role requirement infoRole required: User Manager
Warning on scope changes
Scope changes may lead to reporting new vulnerabilities or changing the State of reported vulnerabilities to Safe.

Deleting a root is not possible on Fluid Attacks' platform because keeping record of a root may prove more beneficial than otherwise for your risk management. What you are allowed to do to keep a root within the scope of security testing or leave it out is changing its State. The later, shown in the Scope section, can be set to Active or Inactive:

  • Active: The repository is accessible for analysis by Fluid Attacks' AppSec testing tool and hacking team
  • Inactive: The repository was added to the scope by mistake, does not exist anymore, or its location was changed 

You have the flexibility to modify the state at any time. A detailed change history is maintained for traceability. Moreover, State changes trigger email notifications to all project stakeholders subscribed to them, both within Fluid Attacks and the customer's organization.

These are the steps to deactivate a root:
  1. Go to the group's Scope section to locate the root you wish to deactivate.
  2. Locate repository to deactivate on the Fluid Attacks platform

  3. In the State column, switch the toggle to off. (If this column is not showing, try seeing whether it is hidden using the Columns option.)
  4. Deactivate a repository on the Fluid Attacks platform

  5. A pop-up window prompts you to specify the reason for deactivation.


  6. You can choose one of the following reasons:
    • Registered by mistake:  You or your team had mistakenly added this root or made mistakes filling out its details (if you simply need to update the URL, branch, or other attributes of a Git root, consider editing instead of deactivating it).
    • Moved to another group:  You wish to transfer the root, along with its associated vulnerability report, to a different group. After choosing this option, use the search bar to find the target group within your organization, which must be under the same subscription as the currently opened.
    • Other: If neither of the above reasons applies, use this option to provide your explanation for deactivation.
  7. Click on Confirm to apply the deactivation.
  8. Remove repository added by mistake on the Fluid Attacks platform

Manage Environments

Fluid Attacks evaluates environments you have appropriately matched with source code repositories. Security testing of environments is done through dynamic application security testing (DAST) and, exclusively in the Advanced plan, penetration testing as a service (PTaaS) and software reverse engineering.

Know your Environments table

Role requirement info
Role required: User, Vulnerability Manager or User Manager

The table listing the environments under evaluation is found in your group's Scope section. Its columns show the following information:
  • URL: The URL address of the environment
  • Has Secrets?: Indicates whether secrets (credentials) are required to access the environment

Environments Table

The Excluded label is shown to indicate what URLs have been excluded from vulnerability analysis.
Know excluded environments on the Fluid Attacks platform

Clicking the downward-facing arrow reveals more information about the environment. Namely, the date it was added, the email address of the group member who added it, and the Git root(s) to which it is associated.

Know environment details on the Fluid Attacks platform

Add or remove Environments

Role requirement info
Role required: User or User Manager

To add environments to the security testing scope, follow these steps:
  1. Access the group's Scope section and click the URL of the Git repository whose environment you wish to add.
  2. Choose repository to add environment on the Fluid Attacks platform

  3. In the pop-up window, choose the Environments tab.
  4. View linked environments on the Fluid Attacks platform

  5. Click on Add environment.

  6. Select the environment type and provide the required information in each case.
  7. Add environment to test on the Fluid Attacks platform

    Here is a short definition of each of the options:
    • CSPM:  The environment to test is located in an AWS or Azure cloud, or GCP. This type requires you to provide the necessary credentials.
    • The descriptions of the further fields to fill out when choosing one of the supported cloud services, as well as the instructions to get the required information (e.g., secrets), are in dedicated pages: AWSAzureGCP.
    • Mobile: The environment to test corresponds to a mobile application. This type requires you to choose the previously added mobile app file.
    • URL: The environment to test is at a URL where the application is deployed. This type requires you to provide the URL.
  8. If access is behind a private network, check the condition accordingly. If it is not, leave the Connector and Egress options unchecked.
    • Connector: Cloudflare Tunnel is configured
    • Egress: Specific IPs need to be whitelisted on your firewall

    Specify connection to environment on the Fluid Attacks platform

  9. Click on Confirm to add the environment.
Caution on adding environments

When checking an environment, an HTTP response code 200 usually means that the request was processed correctly. If this code is not received, there may be several reasons why the environment could have problems, which include:

  1. Authentication or authorization errors
  2. Data validation errors
  3. Connection or infrastructure problems
  4. Internal server errors
In order to remove an environment, follow these steps:
  1. Click on the Git repository to which the environment is linked.

  2. Switch to the Environments tab.

  3. Click the trash can icon corresponding to the environment you wish to delete.
  4. Remove environment on the Fluid Attacks platform

  5. Confirm removal.
  6. Confirm environment removal on the Fluid Attacks platform

Exclude Environments

Role requirement info
Role required: User or User Manager
Warning on environment exclusions
Warnings:
  1. Excluding a subpath implies it is not considered in vulnerability analysis.
  2. Excluding a main path automatically excludes all of its subpaths.
  3. You cannot activate a subpath if its main environment is inactive.

If you want to exclude from security testing  a subpath of a specific environment, follow the steps below:
  1. Go to your group's Scope section.

  2. Add the subpath you wish to exclude as you would add an environment to test. To learn how to do the latter, read Add or remove Environments.
  3. Add environment to exclude on the Fluid Attacks platform

  4. Click Confirm.

  5. In the table, locate the added subpath and switch the corresponding toggle in the Exclusion status column to off.
  6. Exclude environment from tests on the Fluid Attacks platform

  7. Click on Confirm to apply the exclusion.
  8. Confirm environment exclusion on the Fluid Attacks platform
Note on path existenceNote: Make sure the main path exists before excluding a specific path.


Manage IP Roots

An IP address serves as a unique identifier for a device connected to the Internet or a local network. If your group is subscribed to black-box testing, i.e., security testing without access to source code, you can manage IP roots in the Scope section. By providing Fluid Attacks with an IP address, you enable Continuous Hacking to evaluate the security posture of all web applications reachable through that specific target.

Know your IP roots table

Role requirement info
Role required: User, Vulnerability Manager or User Manager

The table under IP Roots in the Scope section offers information of the IP addresses you have designated for Fluid Attacks' analysis.

View IP addresses on evaluation in the Fluid Attacks platform

These are the descriptions of each column:

  • Address: The specific IP address under evaluation
  • Nickname:  A user-defined name for easy identification of the IP root
  • State: Whether the root is in the scope of security testing, where Active means it is undergoing testing, and Inactive means it is not being tested

Add an IP root

Role requirement info
Role required: User or User Manager

To add a new IP root, follow these steps:
  1. Go to the Scope section of the group where you wish to add an IP address to test.

  2. Click on Add new root under IP Roots.

  3. Provide the address and define its nickname.
  4. Add IP root to test on the Fluid Attacks platform

  5. Click on Confirm.


Edit an IP Root

Role requirement info
Role required: User or User Manager

You can modify the nickname of an existing IP root following these steps:
  1. Go to your group's Scope section.

  2. Click on the IP root you wish to edit.
  3. Select the IP root to edit on the Fluid Attacks platform

  4. In the pop-up window, change the nickname as desired.
  5. Change IP root nickname on the Fluid Attacks platform
    Note on nicknames
    Note: Each IP root must have a unique nickname.
  6. Click Confirm.
  7. Confirm IP root edit on the Fluid Attacks platform

Deactivate an IP Root

Role requirement info
Role required: User Manager

The steps and considerations for deactivating an IP root are the same as for deactivating a Git root.

Manage URL Roots

URL roots represent dynamic environments already deployed on a web server. Adding them to Fluid Attacks' scope allows for direct assessment of your live web applications without access to source code. This is available to groups subscribed to black-box testing.

Know your URL Roots table

Role requirement info
Role required: User, Vulnerability Manager or User Manager

The Scope section has a table that shows the URL roots.

View tested URLs on the Fluid Attacks platform

The table shows the following information:
  • Host: The domain name or IP address of the web server
  • Path: The specific path within the URL to be assessed
  • Port: The port number used to access the URL
  • Protocol: The protocol used by the browser (e.g., HTTP or HTTPS)
  • Query: Any query parameters included in the URL
  • Nickname: A user-defined name for easy identification
  • State:  Whether the root is in the scope of security testing, where Active means it is undergoing testing, and Inactive means it is not being tested

Add a URL root

Role requirement info
Role required: User or User Manager

Here are the instructions to add a new URL root to subject it to security testing:
  1. Go to the Scope section of the group where you wish to add the URL root.

  2. Click on the Add new root button.

  3. Provide the complete URL of the deployed environment you want to assess and a nickname for it.
  4. Add URL to test on the Fluid Attacks platform

  5. Click on Confirm.


Edit a URL Root

Role requirement info
Role required: User or User Manager

By clicking on the URL of your interest, you can access the options to change its nickname, any secrets needed for access, and any subpaths excluded from testing.

To change the nickname of an existing URL root, follow these steps:
  1. Go to your group's Scope section.

  2. Click on the URL root you wish to edit.
  3. Select URL root to edit on the Fluid Attacks platform

  4. In the pop-up window, change the nickname as desired.
  5. Edit URL to test on the Fluid Attacks platform
    Note on nicknames
    Note: Each URL root must have a unique nickname.
  6. Click Confirm.

Deactivate a URL Root

Role requirement info
Role required: User Manager

The steps and considerations for deactivating a URL root are the same as for deactivating a Git root.

Exclude subpaths in URL Roots

Role requirement info
Role required: User Manager
Warning on excluding subpathsPlease note that excluding subpaths means they are not considered in vulnerability analysis.

To exclude a subpath of an active URL root from security testing, proceed as follows:
  1. Go to the group's Scope section.

  2. Click on the host of the URL root containing the subpath you want to exclude.
  3. Select URL to exclude on the Fluid Attacks platform

  4. In the pop-up window, switch to the Excluded sub paths tab.
  5. View excluded URL paths on the Fluid Attacks platform

  6. Click the Add sub path button.

  7. Enter the subpath you wish to exclude.
  8. Exclude URL path from testing on the Fluid Attacks platform

  9. Click Confirm

To reinclude the subpath to the testing scope, follow these steps:

  1. Click on the host of the URL root.

  2. Go to the Excluded sub paths tab.

  3. Click on the trash can icon corresponding to the subpath you want to reinclude.
  4. Reinclude URL path for testing on the Fluid Attacks platform

Manage secrets

Role requirement info
Role required: User or User Manager

On the platform, you can securely manage secrets (credentials) that grant Fluid Attacks access to private repositories and environments in order to test them. Secrets include usernames, passwords, email addresses, tokens, etc.

To view, add, edit, and delete the secrets go to the Scope section and then proceed accordingly:
  1. For Git roots, click on the URL and, in the pop-up window, switch to the Secrets tab
  2. For environments, click on the URL
  3. For URL roots, click on the host and, in the pop-up window, switch to the Secrets tab


Follow these steps to add secrets:

  1. Click on the desired URL (Git roots or environments) or host (URL roots).

  2. If editing a Git or URL root, switch to the Secrets tab. The screenshots below show as example the addition of Git root secrets.
  3. View secrets on the Fluid Attacks platform

  4. Click the Add secret  button.

  5. Add as Key the kind of secret it is (e.g., token) and as Value the actual secret. Optionally, provide a description that can help its use.
  6. Manage secrets on the Fluid Attacks platform

  7. Click Confirm.

Once you confirm a secret, it becomes available to Fluid Attacks'  security analysts on the platform. Always handle secrets with care and ensure they are kept up-to-date.

Visualize secrets on the Fluid Attacks platform

Note on adding CSPM environmentsNote: You can provide credentials for your environments in supported clouds when adding those environments. The instructions are in the dedicated pages: AWS, Azure, GCP.
Free trial message
Free trial
Search for vulnerabilities in your apps for free with Fluid Attacks' automated security testing! Start your 21-day free trial and discover the benefits of the Continuous Hacking Essential plan. If you prefer the Advanced plan, which includes the expertise of Fluid Attacks' hacking team, fill out this contact form.