What happened

• On February 20th and 24th we deployed a couple of changes to our backend with the aim of improving Integrates’s performance on the database side.
• Since we have infrastructure as code, we use the Terraform language to make changes to the database. Unfortunately, this tool has a bug related to the database attributes that we added in the changes mentioned above.
• Due to that bug, some database keys were re-created after every deployment, and that ended up causing some delays in the responses to our backend.

What we’ve done

• We detected some delay issues on February 24th and began to investigate the causes. We found the problem on February 25th and finally applied the recommended fix 1 on February 26th.

What’s the impact

• Approximately 36 errors were generated due to this issue from February 24th to 26th, causing delays in the responses and, in some cases, unavailability in the content of users’ and findings’ tabs.

What we are doing to help

• We are now aware of the presence of this bug and will remain vigilant so that we can avoid these issues whenever we make any changes to table keys.

What happened

• Last week’s Monday and Tuesday (February 17th and 18th) and this week’s Monday (February 24th) in the afternoon we released new versions of Integrates that caused a failure in the continuous deployment of Integrates.
• We have a daily deployment that rotates some security keys that last only for 24 hours to preserve the security of our customers.
• In those previously mentioned days, the rotation jobs failed, so the keys used by the app were invalid, thus the access to all the projects was forbidden.

What we’ve done

• On all three days we manually triggered the rotation job early in the morning and, after that, we fixed the code that caused the failure on the pipelines.

What’s the impact

• The issue lasted approximately 5 hours (4:10-9:21) on February 18th, 3 hours (4:10-7:04) on February 19th and 3 hours (4:10-7:02) on February 25th. However, access attempts only occurred from 6:50 to 9:20 on the first day, from 6:44 to 7:02 on the second one and 6:26 to 6:58 on the third one, resulting in a total real affectation of around 3.5 hours.
• Approximately 45 of our users were unable to access their projects on February 18th, 19th and 25th in the morning.

What we are doing to help

• We are developing an automatic test that checks the access to the projects and that notifies us by SMS and mail whenever it fails.
• We are increasing the availability window of the old keys to two days, in this way, if a nightly pipeline fails, we have 24 hours to fix the errors without causing availability affectation to our customers.
• With this announcement, customers are being notified that this was an internal error caused by two failures on deployment pipelines and of what we did to fix it.

This post will help you use Integrates API, which is built as a GraphQL service where you can consume data using a common query language. If you know how GraphQL works, you can skip ahead to Integrates API Token post:

• The first step is to get some GraphQL knowledge, how it works, and how to make queries to a GraphQL endpoint. You can do it in this Introduction on the official GraphQL site.
• Before you face the Integrates API, it is recommended to learn how to make Queries and Mutations since these are the basic operations over any GraphQL endpoint.

• Once you get the basic knowledge about the main GraphQL concepts such as Queries, Mutations, Fields, and Arguments, you are ready to explore Integrates API:

  • Go to Integrates API Token post and use Browser method to see info about you (in this case, your role in the application; remember that you have to log in to Integrates previously):

    query {
     me {
      role
     }
    }
    

  • If you want to get info about your projects, you can enhance the previous query. Remember that, since Projects is a list of Project entities, which are GraphQL entities, you must specify the items that you want from them, in this case, its names:

    query {
     me {
      projects {
       name
      }
     }
    }

In the last months, we implemented a feature that forces the users to choose a deadline when they accept findings. But sometimes, accepting a finding for an indefinite time is needed because the organization has evaluated all the consequences it may have and decided they will assume the risks forever.

Considering that, Integrates now allows accepting a finding without setting a deadline at the cost of requiring an additional reviewing cycle.

If you want to request the indefinite acceptance of a finding, you must do the following:

1. Go to the finding that you want to Accept indefinitely and press the “Edit” button
2. Go to the end of the page and, from the list of treatments, select “Indefinitely accepted”
3. Enter a justification for the treatment
4. Go back to the start of the page and press the “Update” button
5. A dialog warning about the approval of the finding will pop up, and you will have to press “Proceed” to agree and set the treatment for the finding
6. A mail will be sent to all project interested users

If you are a manager, you can review the indefinite acceptance of a finding and decide whether you approve or reject the treatment:

1. In the finding, you will see a pair of new buttons to approve or reject the treatment
2. When you press any of these buttons, you will be requested for an observation about the decision
3. After you enter the observation, you can proceed, and now the finding will have one of the following treatments:
   • Indefinitely accepted if the treatment change is approved
   • New if the treatment change is rejected
     

Note:

• The finding will have the New treatment if the treatment change approval is not resolved after five days.

What happened

• Last Thursday (January 30th) at 19:44 we released a version of Integrates that caused a malfunction in authorization roles, in which “Manager” users were affected. The details of this commit can be found at https://gitlab.com/fluidattacks/integrates/commit/d1814d
• We are updating our authorization model, to give more flexibility to our current roles and create more of them in the future. This issue was a product of one of those migrations.
• No migration-related error, including this one, has jeopardized the confidentiality of our users’ information.

What we’ve done

• On January 31st at 11:29, the issue was fixed by correctly assigning the permissions to the affected role.

What’s the impact

• The issue lasted approximately 16 hours. However, access attempts only occurred from 7:50 to 11:12 on January 31st.
• Approximately 6 of our users with manager roles were unable to see the “Users” tab and to manage the information of the findings on January 31st until 11:29.

What we are doing to help

• To avoid future similar issues we are strengthening the peer review process in our development team, assuring that the changes in the authorization model are not affecting the previous ones.
• With this announcement, customers are being notified that this was an internal error caused by a set of changes we had made to the authorization model and of what we did to fix it.

Fluid Attacks main responsibility is to find vulnerabilities. Our customer's main responsibility is solving them.

Through ARM, customers can request a Reattack when a vulnerability is solved, and source code is available in the defined branch in the GIT repository.

You can select one or multiple vulnerabilities to be reattacked, and our team will do their job confirming the solution to the vulnerability.

You will get informed in the consulting tab about the reattack outcome.

Also, you can check pending to reattack vulnerabilities in locations table filtering by reattack requested vulnerabilities

What happened

• Last Tuesday (January 7th) at 12:03 PM there was an incident in which two of our customers using the Breaks service got their pipelines broken due to findings with ‘Accepted’ treatment.
• The commit with the changes that affected the pipelines was merged at 09:43 AM and its details can be found at https://gitlab.com/fluidattacks/integrates/commit/7913964
• We implemented a new functionality which restructures finding attributes so that now information concerning treatment data is stored inside a historical register. This feature allows to store and keep constancy of all treatment changes with its concrete data.
• This is a very sensible change given the number of parts of Integrates that we had to modify in order to make this new feature effective. Specifically, the change modified the API signature. The Breaks service uses the API and the signature was not updated, breaking the expected behavior.

What we’ve done

• January 7th at 4:41 PM, the issue was fixed. The affected customers confirmed that the issue was solved at 5:57PM of the same day.
• The way we solved the problem was updating Breaks service, due to the finding treatment change mentioned above, to retrieve the treatment correctly.

What’s the impact

• Two of our customers got their pipelines broken because of those findings whose treatment were ‘Accepted’. The problem lasted 4 hours and 38 minutes.

What we are doing to help

• In order to avoid future similar issues we are going to implement ‘versioning’ for our API. This way, future incoming changes affecting the API will automatically activate the corresponding changes in breaks.
• With this announcement, customers are being notified that this was an internal error due to a set of changes we made in the data structure and what we did to fix it.

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: