Upcoming Single-Tenant Version | 3.66

The SAST engine in Checkmarx One has been upgraded to version 9.7.7 and will be rolled out gradualy over the following weeks. To discover all the new features and updates in the latest version, refer to this page.

SAST automatically routes your code to a traditional, query-based SAST scan or an LLM-based scan depending on the language and framework it's written in, so you get broader language coverage without changing how you trigger a scan.

If your codebase uses only languages SAST already supports, it's scanned exclusively by the traditional SAST. If it includes languages SAST doesn't support, those files are analyzed by the LLM-based engine instead.

For mixed codebases, each engine scans the parts it supports, and you see the combined results as one unified set. You can opt in or out of LLM-based scanning, and the feature follows the AI Usage toggle in your Global Settings.

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.

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.

Running AI Triage and Remediation from the Risk Orchestration screen is now supported for SCA risks, bringing parity with the AI T&R experience already available for SAST. This gives AppSec and security teams a consistent, scalable way to triage and remediate risk across scan engines, improving traceability and reducing dependency on developer workflows for risk understanding.

The Changelog now shows the user who triggered Triage Assist and includes a link to the AI Triage insight for every AI-driven state change in SAST and SCA findings. This gives AppSec teams full auditability of AI-assisted triage decisions - reviewers can see who initiated the action and follow the link to understand the reasoning behind the state change.

This applies to both manual and automated (auto-triage) executions. For auto-triage rules, the triggering user reflects the user who configured the rule. For bulk triage actions, each finding's changelog entry links to its own individual insight.

 We have fundamentally upgraded the AI Triage and AI Remediation agents to improve accuracy and performance. This upgrade is applied automatically with no action required by the end user.

The Scan Report now includes two new tables - Results Distribution by Status and Results Distribution by State - giving a tabular breakdown of vulnerabilities alongside the existing pie charts. These tables appear in the Scan Results Overview section of the report and are included in both PDF and JSON exports.

This addition brings the Scan Report in Checkmarx One to parity with the equivalent reports for SAST on-premises customers, providing a consistent user experience for migrating customers.

API Security engine data is now included in Analytics. Vulnerability data from API Security scans is ingested alongside other engines and reflected in dashboard KPIs, charts, and summary counters. Severity and state changes to API Security findings are also captured and reflected in Analytics.

You can now change a risk's state and severity directly through the MCP Server, without opening Checkmarx One. This lets developers and AppSec engineers act on a risk — for example, marking it Not Exploitable or Confirmed — directly from their AI assistant using natural language. Support spans all major scan engines, so the same workflow applies regardless of where the risk originated. By keeping triage inside the tools developers already use, this reduces context switching and speeds up remediation decisions.

For more information, see documentation

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.

Global Inventory now uses simple Next and Previous controls to move through results, replacing page-number navigation on the Packages, Risks, and Licenses tabs. This aligns with how the feature is typically used - applying filters to answer specific questions rather than browsing sequentially - and eliminates cases where page numbers pointed to results beyond what could be displayed. The result is a more consistent and reliable way to move through filtered inventory data.

This improvement also speeds up data export and removes the previous limitation of the number of results that can be exported.

SCA now performs reachability analysis natively as part of the scan, removing the need for a separate SAST scan to determine Package Usage and Exploitable Path results. Reachability results appear in the same manner as before, with no additional configuration required. A new Reachability column adds visibility into how the analysis ran for each risk, showing one of the following statuses: Exp.Path Found, Not Detected, Not Supported, Pending Analysis, or Calculation Failed. By running independently of the SAST engine, this change removes prior connectivity requirements and scan-method restrictions, delivering faster and more accurate exploitable path results.

SCA now supports UV as a Python package manager for dependency resolution, in addition to the existing pip-based support. This is available both in Checkmarx One cloud scans and through the SCA Resolver.

You can adjust the UV Resolution setting at the tenant or project level to use UV for resolving Python projects. Pip remains the default selection to preserve existing scan behavior for projects that continue using pip. Scan results, including vulnerabilities, license findings, and SBOM exports, display consistently with other supported Python package managers.

This gives teams that have adopted UV for its speed and deterministic dependency management full SCA visibility, closing a coverage gap for projects using modern Python tooling.

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 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.

You now need specific permissions to use each DAST AI feature. Two new permissions, Dast-to-code-initiator and Dast-AI-attack-initiator, have been added to the dast-admin role.

Without the permission, you will still see the DAST AI features in the menu, but they will appear disabled with a tooltip prompting you to contact your admin. If you have access to the environment but not the new permissions, you can still view existing correlation and AI attack results.