You can now choose whom in your team to assign a vulnerability we have reported in any of your groups.

Thanks to this feature, the first in a series of related innovations, you can easily keep track of the vulnerability management of each member of your team.

We invite you to follow our news channel to be updated on all our improvements.

You, dear Fluid Attacks' client, who may have recently become aware of the risk posed by the Log4j zero-day vulnerability worldwide, can immediately find out if it is present in your software for prompt remediation.

In the ARM, in any of your groups, you can look for the vulnerability type "011. Use of software with known vulnerabilities," in which this critical severity flaw should appear as CVE-2021-44228. Remember that you can break the build in case that problem is present. If you have any doubts about this, don't hesitate to contact us!

Hi there,

Until today, tracking was only available for a group of vulnerabilities. Now, we have released a new feature to track reported vulnerabilities one by one:

Thanks to this feature, you can know what happened with every vulnerability, obtaining dates, managers, and justifications for each change in its history.

We hope this feature will help you in vulnerability management and keep you on the remediation path.

Fulfilling top industry privacy standards, we added to our ARM the option to delete your account:

With this option (User menu -> Delete account), in case you don't need to use our platform anymore, you can delete your account and relinquish all your currently available permissions.

Additionally, you can unsubscribe (Group -> Scope -> Unsubscribe) from any group.

Keep in mind that we do not retain for you any information about your deleted account or the groups from which you unsubscribed. Therefore, if you delete your account by mistake, you will then log in to the ARM as a new user. On the other hand, if you unsubscribe from a group by mistake, you must request a new invitation to the group.

Every day we are working to improve our users' experience in the ARM.

After a recent migration in our database, we were able to speed up the browsing on the platform, especially for groups with a large number of vulnerabilities, reducing their loading time.

In the coming weeks, we will make optimizations on other views, aiming to achieve a significant improvement in the browsing speed across the entire platform.

All features are the product of a team effort. You can be part of it and contribute by leaving your comments here in this post or sending them to help@fluidattacks.com.

Recently, our agent got a beautiful update (among other things).

We implemented a new clear and friendly interface to bring you more information when running our DevSecOps Agent.

The new table design, in which we added the severity values, provides our users with the complete status of each vulnerability in their systems.

Remember to check our installation guide (https://docs.fluidattacks.com/machine/agent/installation) to begin using our agent, and, if you have any questions, don't hesitate to contact us at help@fluidattacks.com.

All features are the product of a team effort. You can be part of it and contribute by leaving your comments here in this post or sending them to the email mentioned above.

Our purpose as Fluid Attacks is to provide value through the vulnerabilities we report. Therefore, we are continuously working on improving our processes to generate more accurate reports.

After an exhaustive review, we decided to remove all vulnerability reports of the following typologies:

• 060. Insecure exceptions
• 061. Errors without traceability
• 070. Inappropriate coding practices - Wildcard import
• 073. Conditional statement without a default option

We did this because we consider these typologies as recommendations of programming practices and not vulnerabilities per se. Following this decision, we have been removing these recommendations from the ARM so that development teams can focus on remediation of the reported vulnerabilities.

A few months ago, we created the Daily Digest. An email with a summary of all the groups to which you are subscribed.

As you know, we are fond of continuous evolution, and today we bring you some improvements to this email.

From now on, you will be able to find the oldest and the newest group you are subscribed to.

We also separated the sections of oldest vulnerabilities and most critical vulnerabilities.

We hope that these improvements will be useful for your management.

Correct management of the Attack Resistance Management is critical in a successful security testing process. This is why in recent months, we have been implementing a series of improvements in the management of the roots (GIT repositories, environments). We seek to facilitate administration, ensuring the integrity and traceability of the information recorded.

Therefore, from the Scope section of our ARM, you can activate, deactivate, move or edit the roots associated with the group.

In order to maintain the integrity of the information, we must take into account that for the Roots edition

• the URL is allowed to be edited if it doesn't have reported vulnerabilities, and
• the Branch can be edited in all cases. 

There are two possible reasons for deactivating a root:

• It is out of scope
• It has been registered by mistake

In either case, the associated vulnerabilities are closed, and it is made clear that this is due to a change in the scope of testing.

In addition to the above, you can also move roots to other groups of the same organization, taking into account that

• the root doesn't exist in the destination group, and
• all vulnerabilities associated with this root will be migrated to the new group.

It is important to remember that the success of the testing depends on the proper management of its scope, so we are attentive to answer any questions you may have.

What happened

• Due to a testing strategy implementation to reproduce production tests in local environments, a conflict in service ports unleash in a service outage.

What we’ve done

• Revert commit that were causing the conflict.

What’s the impact

• ARM was unavailable  from 2021-10-22 16:11PM until 2021-10-22 16:30 (19 min).

What we are doing to help

• Pin production to a specific commit, not to master branch. Preventing rollout issues.