Upcoming Multi-Tenant Version | 3.56

Checkmarx One has expanded audit logging coverage across the platform. Additional events were added to existing coverage for the Core platform and IAM (user management), and audit logging was also introduced 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.

The functionality for retrieving logs through the Audit Trail REST API remains unchanged, so existing integrations and workflows continue to work as before. However, due to the expanded coverage, customers should expect a significant increase in the volume of audit events.

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.

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.