Upcoming Single-Tenant Version | 3.25

Developers using the new Projects page API now receive an additional attribute, "imported_proj_name", in the API response to represent migrated projects.

The Filter by Vulnerability Severity feature in the Analytics module allows users to filter vulnerabilities detected across all projects within the Checkmarx One platform based on their severity. Users can choose from severity levels such as High, Medium, and Low, providing a clear view of the most critical vulnerabilities.

Previously, the BYOR feature retained only the most recent results per provider, discarding historical data. This limitation made it challenging for users to effectively triage, compare results over time, track vulnerability progress, and analyze remediation trends.

To resolve this, we now retain the full history of imported results per provider (tool name), allowing for more comprehensive tracking and analysis.

We have integrated triaging capabilities into the BYOR (Bring Your Own Results) feature. This enhancement enables users to categorize, prioritize, and manage vulnerabilities based on severity, risk, and other relevant metrics. As a result, users can focus on addressing the most critical vulnerabilities first, ensuring a more effective security posture.

Customers can now dynamically set scan tags when performing scans through Code Repository imports during Pull Request and Push Webhook events. This feature enhances the flexibility and organization of scan results, allowing for better categorization and tracking of vulnerabilities.

Complex network architectures - such as those using CDNs, WAFs, and reverse proxies - make it challenging to automatically determine network exposure for each container image in various use cases. To address this, we have enabled customers to manually specify whether each container image is publicly exposed.

This enhancement allows customers to provide network exposure runtime data more easily, eliminating the need for us to develop automatic support for every potential use case.

We have improved Cloud Insights by allowing users to trigger manual scans in addition to the existing automated scans that occur every 24 hours. This enhancement enables customers to initiate scans whenever there are changes to assets in the production environment or modifications in network exposure.

The Cloud Insights Attack Path graph now provides a more holistic view for container images marked as publicly exposed. Users can access these comprehensive results in the left side panel, allowing for a more thorough understanding of vulnerabilities and security risks associated with their container images.

Users are now able to edit project tags, instead of just deleting them. This significantly enhances the user experience, especially for those transitioning from SAST. This feature is particularly valuable for users with large tags, as it eliminates the need to manually recreate them and reduces the chance of errors. It provides flexibility and familiarity, enhancing efficiency and streamlining workflow.

We have addressed the gap in critical information needed to accurately count contributing developers and display this data to our customers. By integrating a new gRPC call, we can now retrieve this information directly from the integrations team responsible for the imported repositories. This enhancement enables us to provide customers with accurate and comprehensive data on developer contributions.

During the implementation of Data Retention, we identified the absence of a mechanism to exclude specific scans from deletion. To address this, we have introduced a new feature that allows users to mark certain scans as "locked." This ensures that important scan data is not subjected to automated purging, providing users with better control over their critical information.

We have revised the existing permissions in the Risk Management module to enhance clarity and functionality. The previous permission structure, which combined viewing the top 10 most risky applications and the Risk Management tab, has been split into two separate permissions:

The update-risk-management permission remains unchanged, enabling users to edit the table in the tab.

Additionally, the view-risk-management permission will be removed to streamline access and improve user experience.

The current risk management approach lacks consistency compared to the established method for SAST results, where clicking a result opens a tab in the same table. This inconsistency hampers the efficiency of risk assessments and limits access to partial MFE results.

To address this, we are implementing a new tab for displaying result views, providing a centralized location for users to access crucial risk management data clearly and organized. This enhancement will improve visibility and accessibility, leading to quicker analysis and more informed decision-making.

We have developed two related features that enhance code privacy and result clarity:

Currently, these features are controlled by feature flags with no option for user-driven activation or deactivation.

We have introduced a Detection Date column, displaying the date each vulnerability was detected. This column is sortable and includes a filter option to help users easily manage and view vulnerability timelines.

The SAST engine in Checkmarx One has been upgraded to version 9.6.7. To discover all the new features and updates in the latest version, refer to this page.

We now identify private and unresolved packages in the scanned project. Private Packages are shown in the SCA Results > Packages tab.

We have expanded our support for private packages. When viewing the list of private packages in the Scan Results > Packages tab, you can now drill down to show additional details for a specific package.

Learn more about private packages here.

We added a new tab, Remediation Tasks, to the SCA results viewer. This tab shows detailed information about specific remediation tasks that Checkmarx recommends implementing for your Project. These tasks involve replacing vulnerable packages in your project with non-vulnerable versions of those packages.

The Remediation Tasks tab contains sub-tabs that show two types of pages:

Learn more about Remediation Tasks here.

You can now generate remediated manifest file/s that contain the recommended versions of your packages. You can download the remediated manifest files and use them to update your project.

You can export the remediated manifest file/s from the SCA scan results viewer page. The file/s is exported as a zip archive, which maintains your project's file structure.

Download the new version here.

For Code Repository Integration projects, we now support automatically submitting a pull request to remediate SCA vulnerabilities. The PR updates the package versions specified in your manifest file with remediated versions of those packages based on Checkmarx's recommendations. This feature is supported for all supported SCMs (GitHub, GitLab, Bitbucket and Azure DevOps).

This feature can be activated on the project level by turning on the SCA Auto Pull Request toggle in the project settings.

SCA results in application risk management often lack clarity due to the use of generic framework names, requiring users to invest additional effort to understand the associated risks.

By renaming framework types with specific SCA conventions, we can provide clearer and more meaningful risk classifications. This enhancement improves the user experience and boosts productivity by making the SCA risk results easier to interpret.

We have dramatically cut the time of SCA scans by introducing the new Delta scan feature. When rescanning an existing project, if the manifest files haven’t been changed since the last scan, then we skip the dependency resolution process. This can cut scan times by up to 95% without detracting from the accuracy of the scan.

Currently, this only applies to scans run in the cloud, not to scans run using SCA Resolver.

For more information, click here.