Implemented

↔️ Design Map: Our platform's new Design Map section shows you the relationships we establish between elements of your company's threat model and the vulnerabilities in your software that we detect and report. This information allows you to prioritize vulnerabilities to be remediated according to the most critical risks to your business, defined by your teams beforehand. For more information about this feature and how to upload your threat model to the platform, we invite you to review the corresponding article in our Knowledge Base.

🤖 Model Context Protocol (MCP): Thanks to this evolving feature, you can query the platform using natural language to obtain information about your organization and groups, such as roots, vulnerabilities, analytics, executions of our CI Agent, unresolved events, and more. Currently in its beta version, MCP is a software component that allows different generative AI models to connect and work with our platform data to keep you informed according to your needs. Apart from the platform, it is available in Cursor, Claude, and Visual Studio Code. We invite you to review the corresponding article in our Knowledge Base for more information.

🧩 Cursor extension: Our Cursor plugin is now available for your developers. Thanks to it, they can identify affected lines of code or vulnerabilities we report to them and use the GenAI-powered Autofix and Custom Fix support options to remediate them without leaving their IDE. See the articles on how to install it and how to use it in our Knowledge Base.

🌳 More extensive reports from SCA: Now, for each vulnerability detected in third-party software components on which your application depends, you will be able to see much more details, which you can access from the Locations section. This includes, for example, the type of dependency, advisory ID, affected version, exploitation probability (EPSS), and reachability. For this last variable, we now handle three labels: "latent," "potential," and "reachable."

A latent vulnerability is present in a declared package, but your code doesn't call its associated function. A potential vulnerability means the function is called, but not necessarily in the way described in the CVE (it might depend on user input). Finally, a reachable vulnerability indicates the function is called exactly as described in the CVE; therefore, we're entirely sure attackers can reach it.

Squashed bugs

✔️ Manual reattacks in the Essential plan: Users who had switched from the Advanced plan to the Essential plan were allowed to request manual reattacks, even though the latter only offers automated assessments and reattacks.

✔️ Vulnerabilities in Docker images missing: Vulnerabilities present in our customers' Docker images were not shown in the main reporting table, but only in our platform's Surface section.

Upcoming

👩🏽‍🔧 Fixing support for all prioritized languages: At Fluid Attacks, we currently have a list of prioritized supported languages. What we are looking to achieve is for the GenAI features Autofix and Custom Fix to work for all of these languages, and our Knowledge Base to have many more examples of vulnerability remediation.

✨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! Now, you can also do it in Spanish:

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.