Current Multi-Tenant Version | 3.65

Dashboard views can now be saved and shared with selected filters preserved. Once filters are applied to a dashboard, users can generate a link that retains the chosen criteria, allowing that exact view to be shared with others. This makes it easy for teams to align on the same filtered data without each person needing to recreate the same filter selections.

We added support for token-based authentication when setting up an integration with Bitbucket Cloud. Previously, token-based authentication in Bitbucket was only available for on-prem instances. This capability is now available when using the custom setup flow.

This improvement is especially impactful for Checkmarx One single tenant customers, since they are now able to set up Code Repository Integrations for cloud instances of Bitbucket.

SAST scans now support Findings Analysis, an optional capability that automatically classifies scan results and filters out results identified as unlikely to be relevant. When enabled, the results viewer shows only findings classified as relevant, helping analysts focus on actionable risks.

Findings Analysis can be enabled or disabled at the account level or overridden per project, giving teams control over where automatic classification is applied.

Checkmarx One now supports optional enforcement requiring every project to have at least one associated application. When enabled for a tenant, project creation and updates are rejected if they would leave a project without an application association, and applications cannot be deleted if doing so would leave any project unassociated.

This enforcement applies consistently across direct API and CLI calls as well as project creation through the Import API, migration, Code Repository Integration project creation, and repositories created automatically via webhook.

This helps organizations that require strict application governance prevent unassociated projects from existing in their environment, regardless of how those projects are created.

Checkmarx One now supports tagging scans with the Git commit ID that triggered them. When enabled, scans initiated by push or pull request events are automatically tagged with the associated commit ID.

Users can configure this option through the SCM setup flow, project settings, or during project migration. This makes it easy to correlate a Checkmarx scan with the exact commit it scanned, improving traceability across your SCM-integrated projects.

Vulnerability entries generated from new SCA scan results now display the associated package name and version alongside the CVE identifier. This applies wherever CVE-based vulnerabilities are listed, ranked, or broken down, making it easier to identify which specific package and version a vulnerability affects without opening the individual scan result.

Checkmarx One now provides a public Global Inventory API that lets you programmatically retrieve packages, risks, and license data aggregated across your account. The API is accessed using your platform API token, and each request returns one inventory type - packages, risks, or licenses - with optional filters such as project, application, severity, or exploitability, along with pagination to retrieve complete datasets.

This eliminates the need for manual exports and enables automated, repeatable integration of Global Inventory data into SIEMs, ticketing systems, dashboards, and other security workflows.

For more information, see API Reference Guide.

You can now attach manually identified vulnerabilities to an existing scan, unifying automated (ZAP) and manual findings in one view as a single source of truth.

Upload manual findings via CLI or a CSV/JSON file; they'll appear alongside automated results across the UI, can be filtered separately, and are included in reports. Manual findings can be deleted individually or in bulk from the UI, or overridden via the CLI.

Admins can now enable a setting that removes the raw API key from copied scan-trigger commands, replacing it with CLIENT_ID/CLIENT_SECRET placeholders for teams that authenticate via OAuth. This applies everywhere a command is generated so no one who copies a command, internal or external, is exposed to the raw key.