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!