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.

Know your Git Roots table

Role required: User, Vulnerability Manager or User Manager

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.

Note: 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 required: User or User Manager

Add Git Roots using OAuth

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

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. Upon clicking the provider, a pop-up window prompts you to choose the user credentials corresponding to the OAuth connection for that provider.
   




3. 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.
   


4. You are presented with a three-step form. First, choose the repository or repositories you wish to add and click on Next step.
   




5. Select a specific branch of each repository to test. Confirm your choice by clicking Next step.
   




6. 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.)



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.




If you choose No, you are asked to acknowledge the risks.




7. Click the Add root button to add the Git repository or repositories.

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. 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)



3. 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.

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.

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.

Note: 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.

Note: 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.

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.

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

Exclude subpaths in Git Roots

Role required: User Manager

Note: There is no restriction on the number of exclusions you can define. Tailor the exclusions to your specific requirements.

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. 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?".
   




4. 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.
   




It 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.

Use the wildcard (*) carefully and always try to be as specific as possible.
5. Click on Confirm to apply the exclusions.
   

Note: 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: 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 adding NOFLUID 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 required: User or User Manager

Prepare the CSV file

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

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
  
• connection (optional): The type of connection to your assets (you can set it to egress or connector or leave it blank for no special connection; get more information in "Access to your assets")
  
• priority (optional): The priority (aka criticality) of your root (you can set it to low, medium or high or leave it blank (low would be set as default); it is relevant for the priority scores of your roots' vulnerabilities)
• nickname (optional): The custom nickname for your root (you can define it using alphanumeric and some special characters (:, _, .) but not exceeding 128 characters, or leave it blank for automatic generation (it would be the repository name); the nickname must be unique in your organization)



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

            type
           }
          }
         }

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





Make sure to match the selected credentials type with the URL protocol. For instance, if the URL employs SSH, opt for SSH credentials.

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.

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 required: User, Vulnerability Manager or User Manager

Show or hide columns of the Git Roots table

Role required: User, Vulnerability Manager or User Manager

Filter the Git Roots table

Role required: User, Vulnerability Manager or User Manager

Edit a Git Root

Role required: User or User Manager

1. In the Scope section, locate the active Git root you wish to edit and click on its URL.
   




2. The pop-up window presents three tabs for navigation: Git repository, Environments, and Secrets. Adjust the details as necessary in the Git repository tab.
   




3. Click on Confirm to apply the changes.

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.

Manage Docker images

A Fluid Attacks staff role is required.

Create credentials to access Docker images

1. Access Container registries from the Azure services list.
   



2. Access the desired container registry by clicking on its name.
   




3. Locate Tokens under Repository permissions in the menu on the left and click on it.
   




4. Click on Add.
   




5. Enter a name in the Token field; this is this credentials' username element.
   




6. Indicate the token's permissions in the Scope map field; for Fluid Attacks' security testing, the '_repositories_pull_metadata_read' configuration suffices.
   




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


8. Click on the token in the list to access its Token details page.
   



9. To generate a password to be able to use the token, click the corresponding button in the Actions column.
   




10. 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.



Do not forget to store your password, as Azure shows it to you just this once.

Add container registry credentials on the platform

1. Access your organization's Credentials section from the collapsible menu on the left side of the screen.
   




2. Click on Add credential and choose the Add manually option.
   




3. In the pop-up window, name the credentials.
   




4. Choose User and password as the credentials type.
   




5. Provide the credentials.
   



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.
6. Click on Add.
   

Add Docker image

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. Click on Add Docker image.
   




4. Provide the required information, including the existing credentials to authenticate with the registry.
   


Note that the existing credentials chosen in this example screenshot are those created in the above example of saving credentials to the platform.


5. When you are done, click Confirm.

Note: For the image to be analyzed, it is necessary that it includes a Dockerfile document.

Deactivate a Git Root

Role required: User Manager

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.

1. Go to the group's Scope section to locate the root you wish to deactivate.
   




2. 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.)
   




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




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.
4. Click on Confirm to apply the deactivation.
   

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 required: User, Vulnerability Manager or User Manager

• URL: The URL address of the environment
• Has Secrets?: Indicates whether secrets (credentials) are required to access the environment

Add or remove Environments

Role required: User or User Manager

1. Access the group's Scope section and click the URL of the Git repository whose environment you wish to add.
   




2. In the pop-up window, choose the Environments tab.
   




3. Click on Add environment.
   


4. Select the environment type and provide the required information in each case.
   




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: AWS, Azure, GCP.
• 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.
5. 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






6. Click on Confirm to add the environment.

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
   

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. Confirm removal.
   

Exclude Environments

Role required: User or User Manager

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.
   

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. Click Confirm.
   


4. In the table, locate the added subpath and switch the corresponding toggle in the Exclusion status column to off.
   




5. Click on Confirm to apply the exclusion.
   

Note: 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 required: User, Vulnerability Manager or User Manager

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 required: User or User Manager

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. Click on Confirm.

Edit an IP Root

Role required: User or User Manager

1. Go to your group's Scope section.
   


2. Click on the IP root you wish to edit.
   




3. In the pop-up window, change the nickname as desired.
   



Note: Each IP root must have a unique nickname.
4. Click Confirm.
   

Deactivate an IP Root

Role required: User Manager

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 required: User, Vulnerability Manager or User Manager

• 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 required: User or User Manager

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. Click on Confirm.

Edit a URL Root

Role required: User or User Manager

1. Go to your group's Scope section.
   


2. Click on the URL root you wish to edit.
   




3. In the pop-up window, change the nickname as desired.
   



Note: Each URL root must have a unique nickname.
4. Click Confirm.

Deactivate a URL Root

Role required: User Manager

Exclude subpaths in URL Roots

Role required: User Manager

Please note that excluding subpaths means they are not considered in vulnerability analysis.

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. In the pop-up window, switch to the Excluded sub paths tab.
   




4. Click the Add sub path button.
   


5. Enter the subpath you wish to exclude.
   




6. 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.

Manage secrets

Role required: User or User Manager

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. Click the Add secret  button.
   


4. 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.
   




5. 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.

Note: 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

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.