In every project, there was a tab called Resources, in which you could find the list of Repositories, Environments, Files and a list of tags, called Portfolio, used for analytics purposes.

This tab is now called Settings and was moved to the last position since we are implementing other functionalities that affect the whole project but are not directly related to its resources.

We also moved the Comments tab to the left in order to give more importance to this communicative feature.

Before:

Now:

Now it is possible to assign some data to vulnerabilities in findings:

• Tag: It is an arbitrary string; it can be used to identify a group of vulnerabilities.
• Severity: It can be a number between 0 and 1,000,000,000 (one billion) that represents the severity of the vulnerability for the business. It can be a quantitative or monetary value.
• Treatment manager: Is the person responsible for the treatment given to the finding for a particular vulnerability. Remember that this field depends on the treatment value: If it’s “New”, it will not be available. If it’s “In progress” and the user is a manager, it can be chosen; otherwise, it will be the user himself.

In order to ease the selection of multiple vulnerabilities, a filter is available in the first column, and you can select many vulnerabilities at the same time:

Now it is possible to assign some data to vulnerabilities in findings:

• Tag: It is an arbitrary string; it can be used to identify a group of vulnerabilities.
• Severity: It can be a number between 0 and 1,000,000,000 (one billion) that represents the severity of the vulnerability for the business. It can be a quantitative or monetary value.
• Treatment manager: Is the person responsible for the treatment given to the finding for a particular vulnerability. Remember that this field depends on the treatment value: If it’s “New”, it will not be available. If it’s “In progress” and the user is a manager, it can be chosen; otherwise, it will be the user himself.

In order to ease the selection of multiple vulnerabilities, a filter is available in the first column, and you can select many vulnerabilities at the same time:

What happened

As part of the implementation of a series of new functionalities in which we are working, yesterday morning (9:57-10:50) and afternoon (17:13-18:50) the users of Integrates experimented errors when they tried to access any tab of a project.

Both errors were caused by changes in the structure of directories and files in our repository. With new deployments, a cache was stored from previous deployments and the API endpoint was unable to respond to new requests.

What we have done

Both errors were caused by the same problem but were fixed by different means. The first one was solved with a fresh deployment of the application. The other one was solved with a purge of the server cache.

What was the impact

During approximately two and a half hours, all projects, with their indicators, findings, events, etc., were inaccessible to all Integrates users.

What we are doing to help

• We made some changes to our CI/CD in order to improve the identification of critical files that require cache invalidation during new builds.

In previous days, we released a new feature that will allow analysts to report new events directly on Integrates using the “New Event” button:

When the analyst click the button, a pop-up will emerge, requesting the information about the event:

After the analyst enters the information and presses the “Proceed” button, Integrates will create a new event and send an email to all project managers.

The “Edit” button must be pressed and the affectation value must be edited to solve the event. The affectation is the number of hours that the project was affected by the event:

Finally, the “Update” button must be pressed. After refreshing, the event will appear with a “Solved” status:

To keep track of the different resources a project needs, it is no longer possible to eliminate repositories. Instead, each of them will have a “state”. This * state * can be “Active” or “Inactive” ([optional] as explained below):

• Active: The repository is available and ready for our hackers to access.
• Inactive: The repository does not exist anymore, it was changed, or it was added by mistake.

Every time a repository is changed, a notification will be sent to all the people involved in the project (both Fluid Attacks’s and customer’s users).

Finally, the states can be changed by project users at any moment, and every change will be stored for future needs.

Sometimes, it is necessary that a finding or a vulnerability be removed from Integrates for different reasons. Nevertheless, deleting the information is not a good idea in the security world, and it is always important to keep track of these events.

This is why we don’t delete the findings or the vulnerabilities in Fluid Integrates. Instead, analysts can set any of them to a “Deleted” state.

A justification must be part of the process, and the possible values depend on the entity that the analyst wants to hide. The following options are valid for both findings and vulnerabilities:

• It is a duplicate: The finding or vulnerability had been reported previously.
• It is a false positive: After a review process, it was determined that the finding or vulnerability was not.

There is an option only for findings:

• Finding not required: The report was made for a system that no longer exists or for a finished project.

And there is an option only for vulnerabilities:

• Error when reporting: Given that a vulnerability cannot be edited, this option must be selected if you are going to report another vulnerability that corrects it.

A few days ago, we launched a new feature that allows users to make requests directly to our GraphQL API. You can do this by using one of the following methods:

Browser method

1. Log in to https://integrates.fluidattacks.com

2. Open https://integrates.fluidattacks.com/api

3. Open the Settings using the upper-right button

4. Set a new value: "request.credentials": "include" and save the settings

5. Go to a new tab and make your queries

Note: This method uses the same session as the web application, which lasts for 40 minutes. After that, you need to log in to https://integrates.fluidattacks.com again and refresh the https://integrates.fluidattacks.com/api page.
If you want your session to last more than 40 minutes, you can use an API Token as shown below.

API Token method

1. Generate the API Token from the web application using the API option in the left panel:

2. Select an expiration date up to six months after the creation date:

3. After clicking the “Proceed” button, you will see a string labeled “Access Token”. This will be your API Token:

4. Store this token safely, as it is the only time you will see it. With it, you can do the same things that you usually do on the Integrates web application.

You can also generate the API Token using the next GraphQL mutation on https://integrates.fluidattacks.com/api, where expirationTime is a Unix Timestamp

mutation {
  updateAccessToken(expirationTime:1577854799) {
    sessionJwt
  }
}

You will get the API Token under the sessionJwt value:

Add a new Header in HTTP HEADERS with the name Authorization and the value Bearer , where is the token generated in the previous steps:

Done! Now you can make queries with the same API Token for up to six months (depending on the expirationTime you set earlier):

Resources

• Available queries and mutations are shown in the right panel of the browser:

• GraphQL documentation: https://graphql.org/learn/

What happened

• From 7:38 AM to 2:17 PM most of the findings in the projects were not loading, when they were accesed the screen appeared blank.
• The above happened after enabling the functionality that allows users to add a BTS (Bug Tracking System) URL for any treatment (previously it was only possible for the treatment “In progress”).
• Previously, when a finding treatment was changed, a Null value was stored in the database in the BTS URL attribute. When the previous change was enabled, the frontend tried to convert to string a Null value, resulting in an error.

What we have done

• We implement a workaround to solve the error temporarily, parsing the Null value from the database to an empty string.
• We remove all Null values in the database and improve the source code in order to prevent the insertion of new Null values.

What is the impact

The majority of findings (approximately 80%) in the projects were inaccessible during the period initially described.

What we are doing to help

We are improving the data structure that is stored in the database and preparing the frontend to recover more easily to the errors generated by the data provided by the backend.

What happened

From 6:11AM to 8:05AM users could not log in to the platform due to authentication issues.
A quick fix was implemented, but we experienced issues when trying to deploy it. The issues were related to:

• The cluster losing one of its nodes and thus not having enough compute power to run the deployment pipeline.
• Integrates previous deployment being stuck due to hard limit policies.

What we have done

We have:

• Re-deployed Integrates in our cluster with the proper fix to the specific issue.
• Increased the number of nodes in our Kubernetes cluster to improve performance.
• Improved Integrates’s deploying rules to avoid future deployment errors

What is the impact

Failed login attempts to Integrates from 6:11AM to 8:05AM that resulted in users getting an error message saying that they did not have authorization to access the platform. 38 users were affected by this at the most.

What we are doing to help

We are improving our cluster’s capabilities of recovering from undesired states.