Current Single-Tenant Version | 3.64

Organization-level configuration is now available in Checkmarx One for Code Repository Integration projects, giving account administrators the ability to define scanner and integration settings that apply across all projects within a connected organization. A new Organizations tab in Account Settings, shows each connected SCM organization with a summary of its current configuration.

From the Organization Settings panel, administrators can enable or disable individual scanners and features. Each setting includes an Allow Override option that determines whether individual projects can deviate from the organization default. Settings that are locked at the organization level appear as disabled in Project Settings, with a tooltip indicating that they are controlled at the account level. Settings that allow override remain editable at the project level. Organization-level configuration reduces manual setup overhead across large repository fleets and gives administrators consistent, enforceable control over scanning policy for Code Repository Integration projects while preserving flexibility where needed.

For more information, see Organization-Level Configuration for Code Repository Integrations.

Checkmarx One now supports allowedLevel and unableToBlockOverride attributes on settings metadata, giving platform administrators greater control over where settings can be configured and how override behavior is enforced across levels.

Administrators can now restrict specific settings to either the tenant or project level, preventing misconfiguration by ensuring settings are only accessible and modifiable at their intended scope.

For settings marked as unable to block override, the override option is always enforced regardless of any value provided in a request, ensuring consistent resolution behavior across all levels.

These enhancements reduce the risk of misconfiguration in complex multi-tenant environments and provide a more predictable, enforceable settings hierarchy.

The Checkmarx One MCP Server now supports Container Security scanning, extending MCP coverage to include container risk detection alongside the existing SAST, SCA, IaC, and Secrets integrations.

Access to this functionality is subject to the applicable license and role-based permissions, consistent with other engine integrations.

Scan results stay consistent across scans by preventing vulnerabilities from being marked as fixed when scan configurations change or when vulnerabilities have not been tested or are newly introduced. This leads to reliable scan results across different runs and keeps your feedback loops fast and your developer workflow accurate and predictable.

Bring Your Own Results (BYOR) data is now included in the risk summary views across the Checkmarx One platform, ensuring that projects using imported scan results are accurately represented. The Applications view, including the Overview and Projects tab, also reflects accurate totals that incorporate BYOR results, covering total vulnerabilities, results by scanner type, results by state, and other relevant summary fields.

This update ensures a complete and consistent picture of security risk across all projects, regardless of how scan results were ingested.

The Checkmarx One Analytics Dashboard now supports CSV export for the Fixed Vulnerabilities drill-down table.

This makes it easier to use fixed vulnerability data for external reporting and compliance purposes.

A new AI Usage toggle is now available in Global Settings, giving organizations a single control to instantly disable all AI-driven capabilities across the Checkmarx One platform. When disabled, both user-facing and backend AI-powered features are turned off, and any future AI capabilities will also be governed by this setting. Disabling the toggle triggers a confirmation prompt before taking effect.

This provides enterprises with a reliable governance mechanism to enforce compliance, respond to policy changes, or mitigate risk without requiring per-feature configuration.

API Security triage actions are now recorded in the Checkmarx One Audit Trail, giving security and compliance teams full visibility into result state and severity changes. Each audit event captures the user who performed the action, the timestamp, and the before and after values, including an indication of whether the change was applied individually or in bulk, and whether it was triggered by Similarity or Attack Vector ID logic.

Events are accessible via the Audit Trail API.

Policy Management now supports state-based exemption rules, letting teams define which vulnerability states are excluded from build-break enforcement. Findings that match an exemption rule are skipped during enforcement evaluation but remain fully visible and tracked. All other findings are evaluated against enforcement rules as normal, consistently across pull requests, builds, and CI/CD pipelines.

This allows teams to honour approved exception workflows and proceed with releases without disabling enforcement or misclassifying vulnerabilities.

The Risk Orchestration table now supports column management across SAST, SCA, IaC, DAST, Containers, and Secrets. You can show or hide columns, reorder them via drag-and-drop, and filter or sort by any column, with your preferences saved for future sessions.

Since engines expose different columns, shared columns stay consistent across engines while engine-specific columns remain available for deeper context. This gives teams a more tailored view of risk data that better fits their workflow.

AI-BOM export from Global Inventory now runs through the unified reporting pipeline for a more consistent, reliable experience. You can trigger the export as before and download it once it's ready.

This ensures dependable exports, even for large inventories.

You can now triage SAST and SCA risks directly through the MCP Server, without opening Checkmarx One. Using your AI assistant, you can update a risk's state, such as marking it Confirmed or Not Exploitable, add a comment, and view its triage history within your existing workflow.

This lets teams review and remediate risks faster, without switching context between tools.

Scan results from imported BYOR files are now included in analytics and reports, alongside results from standard scans. This data is available wherever project or application-level reports are generated.

As a result, reports reflect a complete and consistent view of all scan results, regardless of how they were produced.

When triaging BYOR imported findings, you can now attach a comment or note to a state change, consistent with the triage experience for findings from Checkmarx One built-in engines.

The scan summary API now includes AI asset counters, enabling the CLI to display asset data alongside existing scan results. CLI users who initiate AI Supply Chain scans can now view the assets table directly in their CLI output.

The AI Supply Chain Global Inventory now displays code snippets for each detected asset, consistent with the existing behavior in Scan Results. When viewing an asset in the inventory side panel, you can see the code snippet for each evidence item and copy the file path. Assets with multiple evidence locations display a snippet for each occurrence.

The /api/results endpoint now returns custom triage states for API Security findings. When a custom state has been applied to an API Security vulnerability, it is reflected in the customState field of the response, consistent with how custom states are surfaced for other scanners.

We improved the initial load times for showing results on the SCA Global Inventory screen.

SCA now supports dependency resolution using pnpm-lock.yaml, extending lockfile-based analysis to projects managed with PNPM.

When a pnpm-lock.yaml file is detected in a project, it is used as the authoritative source for resolving both direct and transitive dependencies, reflecting the exact versions installed by PNPM. For projects without a pnpm-lock.yaml, existing NPM-based resolution behavior is unchanged. This ensures that PNPM-managed projects receive accurate vulnerability and license risk analysis without requiring any changes to the project configuration.

Checkmarx One now automatically reverts the triage state of a risk from Not Exploitable to To Verify when a subsequent scan detects a new Exploitable Path for that risk.

Previously, this state change had to be performed manually, which meant exploitable risks could remain incorrectly triaged across scans.

A message logged in the risk History explains the reason for the automatic state change, keeping the audit trail clear. This improvement ensures that exploitability changes are surfaced immediately, so that prioritization policies, merge blockers, and remediation workflows reflect accurate and up-to-date risk information.

SCA archive unpacking now supports tgz, rpm, and whl files, expanding on the existing capability to detect and analyze package manifests found inside archive and package files. This applies to both Checkmarx One cloud scans and the SCA Resolver CLI, using the same unpacking pipeline already applied to other supported archive types.

With this expanded coverage, teams working in Linux, Red Hat, and Python ecosystems get accurate dependency and risk visibility for software distributed as pre-packaged archives, without any change to existing scan configuration.

The CycloneDX SBOM generated by Checkmarx One is now compliant with version 1.7 of the CycloneDX specification. As part of this upgrade, each component in the SBOM now includes evidence of its provenance and detection method: the file path in your project that produced it, and whether it was identified through manifest analysis or hash comparison, with both shown separately when a component was identified through more than one method.

This is available in the CycloneDX SBOM downloaded from Checkmarx One, whether generated through the UI, API, or CI integration.

By aligning with the latest CycloneDX standard, the SBOM is more useful for enterprise audit, provenance, and compliance workflows.

SCA now extends its C/C++ open source detection to include packages sourced from vcpkg, in addition to the existing Conan-based detection.

Since C/C++ projects don't have a standardized manifest or lockfile format, SCA identifies open source packages using fingerprint analysis; this analysis now runs against a combined Conan and vcpkg fingerprint database. Detected vcpkg packages appear in scan results with their name, version, and source registry, along with any associated risk data from the Checkmarx security knowledge base.

This gives teams that manage C/C++ dependencies through vcpkg the same visibility into open source risk that Conan users already have, closing a previous blind spot in C/C++ scanning.

Added support for Chrome in DAST CLI. Choose between Firefox and Chrome browser to run your DAST scans. See the --browser CLI command in the table here.

Added column management to environments table. Show or hide columns, pin key ones to lock their place in the table, and drag others to reorder them for better visibility. See here for more information on column management in DAST.

Client Spider has been added as an additional web crawler to web scans. Client Spider is more adept at crawling single-page applications (SPA) than other web crawlers (Spider Ajax).

Guided scan results now show errors from the recordings used in a scan, so you can see which recordings failed and why. This also shows how each recording affected scan coverage - including any additional paths or vulnerabilities it uncovered.

You can now define additional attributes when uploading an API file for scanning. Add key/value variables to Postman files, set a Target URL for OpenAPI/Swagger, or an Endpoint for GraphQL schemas.

This is especially helpful when a file's paths are relative and don't specify a host. Once saved, uploaded files show an icon indicating extra attributes are attached, with options to edit or delete them.