Implemented

✅ Adequate inherited vulnerability categorization: Until recently, vulnerabilities in your third-party components or dependencies were grouped into categories of “use of software with known vulnerabilities” (011 and 393). Now, for the sake of analysis, prioritization, and management, these vulnerabilities are reported to you within their specific categories. So, for example, if a library in your software has an SQL injection vulnerability, it will not be reported as 011 or 393 but as SQL injection within the main list of vulnerability types in our platform.

💉 Vulnerabilities separated according to their origin: As part of the previous change, we want to make it easier for you to filter vulnerabilities. Therefore, in the Locations table of each type of vulnerability, you have the Origin column with two options: “Injected” for vulnerabilities generated in your code by your developers and “Inherited” for those in third-party components on which your application depends.

🌳 CI Agent for inherited vulnerabilities: In relation to the above, considering that previously you could accept vulnerabilities of types 011 and 393 into production, now, accordingly, you can configure our CI Agent to ignore inherited vulnerabilities, whether they are present in development, production, or both stages.

🚛 Specifications for testing in production: We have recently started providing production-phase security testing. To ensure the necessary precautions, whenever you register an environment for this type of assessment, you must specify it through the new corresponding tag in our platform. This information is reflected in the Environments table in the Scope section.

🆎 New languages and frameworks supported: As part of its constant improvement, we have started including several analysis methods for these languages and frameworks in the Fluid Attacks tool:

Languages

• Ruby
• Scala
• ARM
• Helm

Frameworks

• NextJS
• Next.js
• React Native
• Vue
• Ruby on Rails
• Starlette

For reachability analysis on SCA

• Kotlin
• Scala
• PHP
• DART

✅ Improved acceptance flow: We enhanced the flow of requesting, approving and rejecting temporary or permanent acceptance treatments for vulnerabilities for easier utilization of this functionality.

Squashed bugs

✔️ Discrepancies between graphs and report tables: In one of our charts in the Analytics section, the number of vulnerabilities shown did not match those reported overall and for specific periods.

✔️ Wrong organizational MTTR: The mean time to remediate (MTTR) for organizations in general, not groups, was incorrectly calculated because it didn't consider the number of vulnerabilities within each group.

Upcoming

🗓️ CVSS v4.0 complete transition: As previously announced, On April 4, 2025, our platform will ultimately transition to CVSS v4.0, deprecating support for CVSS v3.1. All reports and resources will be automatically updated, requiring no action from users. API users can still access CVSS v3.1 data until October 4, 2025.

🔁 Improved reattack flow: We are enhancing the reattack execution request flow by returning to a state where only two clicks are needed for such a request.

✨Have 10-15 minutes to spare?✨

Share your opinions on our AppSec solution on Gartner Peer Insights and earn a $25 gift card! Your feedback helps others make informed decisions and shapes the future of application security. Just follow this link!

Dear users,

As previously announced, we will fully transition to CVSS v4.0 and deprecate support for CVSS v3.1 next week.

Key points:

• Platform transition: April 4, 2025 - CVSS v4.0 will be the standard.
• Action required: No direct action is needed from users, as resources and reports will update automatically.
• API users: API access to CVSS v3.1 data will remain available until October 4, 2025.

Please ensure you have reviewed the CVSS v4.0 documentation and are prepared for this update.

We appreciate your cooperation.

We recently enhanced our platform's vulnerability categorization for third-party components and dependencies, improving reporting granularity and accuracy. This allows for more precise risk analysis and management.

Previously, inherited vulnerabilities were grouped under the categories of "use of software with known vulnerabilities" (011 and 393). Now, they're reported by specific vulnerability type (e.g., "SQL injection").

Furthermore, we make it easier for you to recognize them with the new Origin column in the Locations table. There, you see “Injected” for vulnerabilities generated in your code by your developers and “Inherited” for those in third-party components on which your application depends.

This change may have affected your remediation rates ⚠️

Formerly, a single affected location reported on our platform with the "vulnerability type" 011 or 393 represented an entire third-party component. But this component could, in reality, contain multiple vulnerabilities of different types (e.g., SQL injection, XSS, RCE), which are now listed individually.

This increased number of vulnerabilities could positively or negatively impact your remediation rates on our platform, depending on whether or not your inherited security issues had been previously addressed.

For questions, contact support at help@fluidattacks.com.

Thank you for your continued trust in our ASPM platform.

🎉 We're thrilled to announce that Fluid Attacks is now an AWS partner and is officially listed on FIRST's website as one of the vendors using EPSS in their products! 🎉

Upcoming

✅ Adequate inherited vulnerability categorization: So far, vulnerabilities in your third-party components or dependencies are grouped into generic categories of “use of software with known vulnerabilities” (011 and 393). Very soon, for the sake of analysis, prioritization, and management, these vulnerabilities will be reported to you within their specific categories. So, for example, if a library in your software has an SQL injection vulnerability, it will not be reported as 011 or 393 but as SQL injection within the main list of vulnerability types in our platform. (Coming up on March 10.)

🗓️ CVSS v4.0 transition is one month away: Mark your calendars! On April 4, 2025, our platform will ultimately transition to CVSS v4.0, deprecating support for CVSS v3.1. All reports and resources will be automatically updated, requiring no action from users. API users can still access CVSS v3.1 data until October 4, 2025.

Implemented

✂️ Dissolve the Vuln. Management menu: Some users had trouble finding the Locations tables' treatment acceptance/rejection and vulnerability reattack buttons. Therefore, we made them instantly visible in that section, discarding the previously implemented Vuln. Management menu.

Squashed bug

✔️ Inconsistency in severity reporting: Discrepancies were observed between the CVSS scores assigned to certain vulnerabilities within our VS Code extension and those reported on our platform.

✨Have 10-15 minutes to spare?✨

Share your opinions on our AppSec solution on Gartner Peer Insights and earn a $25 gift card! Your feedback helps others make informed decisions and shapes the future of application security. Just follow this link!

🎉 We're thrilled to announce that Fluid Attacks is now an AWS partner and is officially listed on FIRST's website as one of the vendors using EPSS in their products! 🎉

Implemented

🔤 Renaming roles: The name "User Manager" was used both at the group and organization levels within the platform when, in fact, it referred to two different roles. Hence, to avoid confusion, mainly regarding permissions, the name was changed to "Group Manager" for the former and "Organization Manager" for the latter.

🏛️ Enhanced access and control: Contrary to what happened a short time ago, when an Organization Manager is invited from within the organization, they automatically gain access to all existing and future groups. In addition, they are assigned Group Manager privileges in each group, ensuring consistency and complete control.

Squashed bug

✔️ Incomplete customized reports: When exporting a customized technical report, some vulnerability records that met the filters selected by the user were not displayed in the report, thus affecting the reliability of this platform function.

✔️ Failure to register URL environments: The platform could not register URL environments accessed through ZTNA or Egress due to an error in the validation of variables.

Upcoming

✂️ Dissolve the Vuln. Management menu: Some users had trouble finding the Locations tables' treatment acceptance/rejection and vulnerability reattack buttons. Therefore, we will make them instantly visible in that section, discarding the previously implemented Vuln. Management menu. (Coming up on February 28.)

✅ Adequate inherited vulnerability categorization: So far, vulnerabilities in your third-party components or dependencies are grouped into generic categories of “use of software with known vulnerabilities” (011 and 393). Very soon, for the sake of analysis, prioritization and management, these vulnerabilities will be reported to you within their specific categories. So, for example, if a library in your software has an SQL injection vulnerability, it will not be reported as 011 or 393 but as SQL injection within the main list of vulnerability types in our platform. (Coming up on February 28.)

✨Have 10-15 minutes to spare?✨

Share your opinions on our AppSec solution on Gartner Peer Insights and earn a $25 gift card! Your feedback helps others make informed decisions and shapes the future of application security. Just follow this link!

We are pleased to announce a significant improvement to our platform, which will empower Organization Managers with greater access and control.

Previously, Organization Managers could only access the groups they were specifically invited to. This restricted their power to make strategic, high-impact decisions across the organization. Additionally, as new groups were created, they did not automatically gain access, creating friction in administration.

Now, when an Organization Manager is invited from within the organization, they automatically gain access to all existing and future groups. In addition, they are assigned Group Manager privileges in each group, ensuring consistency and complete control.

This enhancement streamlines the management process and ensures that Organization Managers have the necessary visibility and authority to effectively oversee all aspects of their organization and groups within our platform.

🎉 We're thrilled to announce that Fluid Attacks is now an AWS partner and is officially listed on FIRST's website as one of the vendors using EPSS in their products! 🎉

Implemented

👩‍⚖️ Improved Policies section: In the Policies section, you can now centrally manage both your organization's policies and those of each of your groups. Only members with the role of User Manager at the organizational level (soon to be known as Organization Manager; see upcoming feature) can edit such policies, i.e., those related to temporary acceptance of vulnerabilities, the execution of our CI Agent, and the removal of users due to inactivity.

Squashed bug

✔️ Improperly displayed table: In the Members section at the organization level, the tables with information about members to remove were not displayed correctly, and the Details column presented readability problems.

Upcoming

🔤 Renaming roles: The name "User Manager" is used both at the group and organization levels within the platform when, in fact, it refers to two different roles. Hence, to avoid confusion, mainly regarding permissions, the name will change to "Group Manager" for the former and "Organization Manager" for the latter. (Coming up on February 21.)

✨Have 10-15 minutes to spare?✨

Share your opinions on our AppSec solution on Gartner Peer Insights and earn a $25 gift card! Your feedback helps others make informed decisions and shapes the future of application security. Just follow this link!

🎉 We're thrilled to announce that Fluid Attacks is now an AWS partner! 🎉

Implemented

⏩ Improved vulnerability tables: We implemented a new version of the vulnerability tables that handles a different query strategy. These tables load information much faster, provide more visual feedback, and enhance your browsing experience.

🏛️ Column management: You have a new interface to manage the columns in the tables of vulnerability types and specific vulnerabilities. You can choose which to enable and which to disable, organize them as you wish, and save the applied changes.

🦠 Reporting use of software with malware: We started reporting the use of third-party software components with code publicly known to be affected by malware as a type of vulnerability in your software products.

Implemented unexpectedly

🔧 Vuln. management menu: The options to request reattacks and accept treatments have been grouped into a single drop-down menu called "Vuln. Management," located at the top right above the table corresponding to each type of vulnerability.

🔁 Redirection for inactive users: You no longer see an alert window with an unauthorized access message due to your session being closed due to inactivity on the platform. Now, in such cases, you are simply redirected to the login page, avoiding unnecessary clicks.

🪛 DevSecOps report name: We have modified the name of the downloadable execution report file of our DevSecOps or CI/CD Agent to match the name within the platform and thus avoid confusion.

Squashed bugs

✔️ Incorrect package display for Docker images: Sometimes, when users in the Surface section wanted to see only the packages associated with a Docker image, they were erroneously redirected to the list of all packages.

✔️ Filtering issues: When filtering data in tables was done through a text input field, and the expected result was not on the first page of results, the message "No data to display" was mistakenly displayed to the user.

✔️ Error changing Docker image credentials: When trying to modify credentials previously added to the platform using the "user:pass" mode, the user encountered an error stating that the credentials were invalid.

Promised but not implemented yet / Upcoming

🎫 Reporting issues in permissions for CSPM: When running CSPM tests, these can sometimes fail due to changes in credential permission settings by users. The idea is to be able to start reporting these problems as events within the platform. (Coming up on February 14.)

👩‍⚖️ Improved Policies section: In the Policies section, you will be able to centrally manage both your organization's policies and those of each of your groups. Only members with the role of User Manager at the organizational level will be able to edit these policies. (Coming up on February 14.)

✨Have 10-15 minutes to spare?✨

Share your opinions on our AppSec solution on Gartner Peer Insights and earn a $25 gift card! Your feedback helps others make informed decisions and shapes the future of application security. Just follow this link!

We've recently streamlined vulnerability management on our platform. The options to request reattacks and accept treatments are now conveniently located in a single drop-down menu called "Vuln. Management." This menu is in the top right corner above the table of each type of vulnerability.

To reattack vulnerabilities and verify the success of your team's remediation efforts, click Vuln. Management and then select Reattack. Next, from the table, choose the vulnerabilities you wish to reattack and click Reattack again.

If you need to stop this process anytime, just click the Cancel button.

We hope this change simplifies your workflow and makes vulnerability management more efficient.

✨Make your voice heard in the AppSec world!✨

Share your thoughts on Fluid Attacks' solution on Gartner Peer Insights and get a $25 gift card! It will only take 10-15 minutes to help shape the future of the application security industry.

Implemented

🖥️ Testing your production environment: From now on, you can also add the production environment of your system under assessment to undergo our continuous security testing. Being more stable than the pre-production environment, evaluating your production environment can give us a broader understanding of your real risks. This way, our testing is carried out during all phases of your software development lifecycle. Please note that you can enjoy all of this at no additional cost.

🛠️ Injected and Inherited sections modified: The section where you can see all your third-party components or dependencies, including those highlighted as vulnerable, reachable, or affected by malware, which we called Inherited for a short time, is now called Packages and is part of the Surface section. Likewise, the Injected section got its previous name back, Vulnerabilities, where you will continue to find reports of all your security issues.

⚠️ Active policy announcements: Each day you access the DevSecOps and Members sections, you will find an announcement about the policies you have active. In the DevSecOps section, you will see information about your policies relating to the temporary acceptance of vulnerabilities and the severity ranges in which our CI Agent breaks the build after a certain grace period. In the Members section, you will see your current inactivity policy for member removal.

➕ Amazon ECR is now supported: We have extended the capability of our scanner to assess container images stored, shared, and deployed in the Amazon Elastic Container Registry (ECR).

⬇️ Export of filtered event lists: Each time you apply a filter in the Events section list and click on the Export button, you will see a drop-down menu where you can choose whether to download the filtered or all the data from the list.

🪚 Environment URL modification: When the URLs of the environments under assessment include at the end unnecessary query parameters that may affect the evaluations and reports, these are removed, leaving only the base URLs.

🔕 Fewer alerts in treatment windows: We removed unnecessary alerts you received while filling in the required fields to improve your experience when assigning treatments to your software vulnerabilities.

❌ Change in the Vulnerabilities column: In the Vulnerabilities column of the list of groups in your organization, we mistakenly mentioned the number of types of vulnerabilities we "found" in each. We have corrected the message since what we really show you is the number of vulnerability types you have open in each group.

Squashed bugs

✔️ Failed folder exclusion for SBOM: We had to readjust the exclusion logic for the SBOM definition, as it failed in the case of listed folders such as ".git/," commonly located in the root directory.

✔️ Endless SBOM generation: The creation of SBOMs for download sometimes became interminable, so we had to make several adjustments to ensure this was always achieved within reasonable time frames.

Upcoming

⏩ Improved vulnerability tables: We are implementing a new version of the vulnerability tables that handles a different query strategy. These tables will load information much faster, provide more visual feedback, and enhance your browsing experience. (Coming up on February 7.)

🏛️ Column management: Linked to the previous feature, you will have a new interface to manage the columns in the tables of vulnerability types and specific vulnerabilities. You will be able to choose which ones to enable and which ones to disable, organize them as you wish, and save the applied changes. (Coming up on February 7.)

🎫 Reporting issues in permissions for CSPM: When running CSPM tests, these can sometimes fail due to changes in credential permission settings by users. The idea is to be able to start reporting these problems as events within the platform. (Coming up on February 7.)

🦠 Reporting use of software with malware: We will begin reporting the use of third-party software components with code publicly known to be affected by malware as a type of vulnerability in your software products. (Coming up on February 7.)

👩‍⚖️ Improved Policies section: In the Policies section, you will be able to centrally manage both your organization's policies and those of each of your groups. Only members with the role of User Manager at the organizational level will be able to edit these policies. (Coming up on February 11.)