Current Multi-Tenant Version | 3.56

Checkmarx One has launched a new audit log service with expanded coverage for a wide range of events across the platform. The new audit log is accessed using a new (REST) API, GET /audit-events. The new service adds new events for existing coverage for the Core platform and IAM (user management), and introduces logging for new areas, including Back Office and several scanners:

These improvements provide broader visibility into platform activity and strengthen auditability for security monitoring, compliance, and governance. Due to the expanded coverage, customers should expect a significant increase in the volume of audit events.

This API will replace the current Audit Trail REST API. The deprecated API will remain available for a 6 month transition period prior to being removed. We recommend taking steps to transition to the new audit log API as soon as possible.

Checkmarx One reports now display date-time values based on the user’s local time zone (instead of UTC). The applied time zone appears in the report header, and all date-time fields are adjusted accordingly.

Project reports now include a Results Distribution section with tables showing vulnerability distribution by status and state. This provides clearer visibility into workflow classification and improves report completeness, readability, and governance reporting.

The structure also aligns with SAST on-premises reports, improving the user experience for customers migrating to Checkmarx One.

The CxLink UI now provides enhanced setup instructions for Kubernetes environments, including examples for creating a Kubernetes secret to store Link credentials and a pod definition for running the Link client image.

In addition, Docker setup instructions have been updated to support using an environment file instead of passing secrets directly via the command line.

The CxLink UI now provides updated Docker setup instructions that avoid passing secrets as command-line arguments. Instead, users create a local .env file to store sensitive values such as the Link token and tunnel name, and reference them when running the container.

To improve traceability and auditability of changes, users are now required to provide a comment when changing the state of a result.

Checkmarx One now provides a public Assign Project to Policy API for assigning projects to policies.

You can use this API in combination with existing endpoints to implement bulk assignment logic. For example:

Checkmarx One now supports IP allowlisting at the tenant level, enabling IAM Admins to restrict platform access to specific IP addresses or CIDR ranges.

Admins can configure up to 10 IPv4 entries in the IAM settings. During login, the user’s origin IP is validated before authentication. Access is granted only if the IP matches the allowlist. IAM Admins and service accounts are always allowed, ensuring uninterrupted administration and automation.

For more information, see Restricting IP Addresses

Checkmarx One CLI scans now support Delta Scan resolution when running SCA scans via the CLI with SCA Resolver. Delta Scan now runs by default when rescanning an existing project, significantly reducing scan time. You can override this behavior by using the --sca-resolver-params flag with the --disable-delta-scan argument. This enhancement improves scan efficiency and accelerates feedback during repeated scans.

Requirements (minimum versions for this functionality):

Results from the SCA scanner are now presented using the same shared UI components and interaction patterns used by other scanners. The Packages, Risks and License views now support consistent navigation, filtering, searching, and drill-down views, aligning the SCA experience with other Checkmarx One results viewers.

This alignment improves usability and consistency across scanners, making it easier for users to analyze SCA findings alongside results from other Checkmarx One scanners.

Checkmarx One has introduced a new metric, CxScore, for SCA vulnerabilities. CxScore improves remediation prioritization by providing a composite score that better reflects the actual risk posed by a vulnerable package. The score is calculated using multiple risk factors, including CVSS 3.0 and 4.0 (when available), EPSS score, dependency type (direct or transitive), and the presence of an exploitable path.

CxScore is automatically calculated whenever scans complete or when relevant CVE data changes. The score is now available across SCA views, including Packages, Risks, Risk Details, and Global Inventory. The existing Risk Score (based solely on CVSS) remains available, and users can toggle between Risk Score and CxScore in relevant views. CxScore is also included in exported reports (JSON, XML, and CSV) and can be used in policy rules to define vulnerability thresholds.

By incorporating additional risk intelligence and contextual factors, CxScore provides a more holistic vulnerability prioritization model and improves visibility into application security risk across the organization.

In addition to uploading your configuration files or setting up your authentication during environment setup, you can use your own custom scripts during authentication. This is especially useful for users who have authentication secrets that change dynamically.

Instances of vulnerabilities shown in the Results Table (Vulnerability View) are now labeled as Systemic when they are detected across multiple parts of the system during a scan. Previously, this view displayed the number of individual instances in which the vulnerability appeared.

This update groups systemic vulnerabilities by their Similarity ID rather than by node or URL, improving consistency across scans and reducing memory overhead.

This change will cause all instances of a systemic alert to appear as New in the first scan after the update, even if they had been identified in earlier scans. In subsequent scans, if the issue has not been resolved, these alerts will appear as Recurrent.