Checkmarx

Checkmarx One 3.60: Tighter AI Supply Chain Governance and Policy Control

Checkmarx One 3.60 helps enterprises identify AI components embedded in source code, govern their use through policies, and bring security scanning into approved AI assistant workflows. It adds scanner-specific net-new vulnerability rules, a policy-violations API, SAST scanned-file reporting, and package-level container triage. These capabilities support more defensible AppSec governance without adding unnecessary friction to delivery teams.

By Chris CarpenterAppSecDevSecOpsSASTDAST
Checkmarx logoCheckmarx One
Checkmarx One 3.60: Tighter AI Supply Chain Governance and Policy Control cover graphic
Back to Checkmarx release updates
Release facts
VendorCheckmarx
Version3.60
Published by MeritoJuly 14, 2026
Newer release covered3.66 (October 6, 2026)
Release historyCheckmarx release history

Checkmarx One 3.60 introduces AI Supply Chain Security (AISC), giving release owners a way to identify AI agents, models, SDKs, and MCP components already present in their codebase before unapproved usage becomes a governance issue.

For enterprise delivery organizations, the release concentrates on a practical concern: security controls must cover the software supply chain as it exists now, including AI-enabled code paths, private dependencies, container packages, and automated test flows. It also adds better evidence for policy enforcement and audit review.

Govern AI components found in source code

AISC discovers and classifies AI assets directly from source code and configuration. Coverage includes MCP clients and servers, agent frameworks such as LangChain and Semantic Kernel, models, ML libraries including PyTorch and TensorFlow, and SDKs from providers such as OpenAI, Anthropic, Vertex AI, and Hugging Face.

The feature matters because AI use often enters products through developer libraries, integrations, and configuration rather than a centrally approved platform decision. Without an inventory, security, privacy, legal, and architecture teams cannot reliably assess data handling, third-party exposure, ownership, or policy compliance.

AISC includes:

  • Scan orchestration across projects
  • A dedicated viewer for detected AI assets
  • CLI support for CI/CD execution
  • Policy management for governance and compliance controls
  • AI Supply Chain scanner availability in code repository integration projects

When enabled for repository integration projects, AISC runs on push and pull-request events alongside other configured scanners. That places AI component visibility in the same delivery path as SAST, SCA, IaC, and Secrets Detection rather than creating a separate manual review process.

Teams should define what requires review: externally hosted models, agent frameworks, MCP endpoints, data-bearing AI integrations, or packages from designated providers. Detection alone is useful, but an ownership and exception process makes the controls operational.

Put AI assistant security workflows under enterprise control

Checkmarx One 3.60 adds a native MCP Server for interactions through supported AI assistants and IDE chat interfaces, including Claude, Cursor, Windsurf, Kiro, and Copilot Chat. Users can manage applications and projects, trigger and monitor scans, investigate findings, and work through remediation using natural-language requests.

This is not simply a productivity feature. It creates a new route into security operations that should be governed like any other engineering integration. The MCP Server uses Checkmarx One authentication and role-based access control, supports the predefined cx-mcp-client OAuth client and Dynamic Client Registration, and includes audit logging. No additional license is required.

Security and platform leaders should establish clear guardrails before deployment:

  • Approve the AI assistant clients permitted to connect
  • Apply least-privilege roles to scan and project actions
  • Review OAuth client lifecycle and Dynamic Client Registration limits
  • Retain and monitor audit records for sensitive actions
  • Define when chat-based remediation can modify code or workflows

The control model is important because conversational interfaces lower the effort required to run security operations. The same change reduce friction can also increase the volume of actions that need traceability.

Make pull-request policies more precise

Net-new vulnerability policy rules can now be configured at the scanner level, with independent severity thresholds per scanner. Pull-request results therefore reflect the scanners and severities specified in the rule, instead of generating noise from unrelated scanner results.

The Break Build option has moved from individual rules to the global policy level. This separation clarifies the difference between evaluating a condition and enforcing a release gate.

For a large delivery estate, this supports a more deliberate policy design:

  • Use scanner-specific thresholds where risk tolerance differs by finding type
  • Limit blocking controls to issues that meet documented release criteria
  • Keep advisory policies visible without creating unnecessary pipeline failures
  • Test policy revisions against representative repositories before rollout

The new Policy Violations Download API adds another governance capability. The GET /api/policy_management_service_uri/policy_violations endpoint returns policy-violating SAST findings, SCA package violations, or both based on the supplied Scan ID. Governance teams can use this data in operational dashboards, control attestations, exception workflows, and audit evidence repositories.

Improve audit evidence and reporting quality

Project reports now offer a SAST Scanned Files section in PDF and JSON output. It records every file analyzed by SAST and the number of vulnerabilities identified in that file. Teams can include it by default or exclude it through the UI or API.

This is particularly relevant for regulated organizations and teams moving from CxSAST on-premises to Checkmarx One. It supplies clearer evidence of scan scope when audit teams ask what was tested, which files were in scope, and where findings occurred.

Reporting improvements also include:

  • Structured headers and report-type metadata in exported report emails
  • Entity-specific tag filtering across applications, projects, and scans in Analytics dashboards
  • Developer Assist seat usage by IDE on the License page and CSV export
  • A configurable, persistent confidentiality banner for each tenant

The confidentiality banner is disabled by default and can be enabled in Global Settings. Because it remains visible throughout a user session and cannot be dismissed, it can support internal data-classification requirements. Administrators should align its wording with approved information-handling policy.

Reduce operational drag in scan and triage workflows

A new Rescan action lets teams rerun a project using the latest source code already stored on the server, without uploading code again. The rescan uses the engines from the last successful scan while applying current project settings, such as presets, exclusions, and scan mode. It is available in the project actions menu and through the API.

This can shorten reassessment cycles after a policy, preset, or exclusion change. Teams should note that it relies on the latest source already held by the platform; it does not replace a repository-triggered scan when the branch itself has changed.

Repository URL handling is also stricter for imported code repository integration projects. The SCM integration is now the authoritative source, and manual repository URL edits are blocked. This reduces inconsistent project records and silent scan failures caused by a URL that no longer matches the configured integration.

Accessibility has improved in the Import Project wizard as well. Service buttons are keyboard-operable and focus now reaches the Select Service step in sequence, supporting WCAG 2.2 readiness and helping organizations meet accessibility audit expectations.

Extend dependency, container, and DAST controls

SCA delta scans now evaluate a wider set of monitored files, scan arguments, and platform configurations when determining whether a full scan is required. This improves the likelihood that dependency changes requiring complete analysis receive it.

SCA policy management also gains an Is Not a DEV or TEST Dependency rule. It simplifies policies intended to identify production dependencies by replacing a manual combination of separate development and test rules.

Private registry coverage expands in three areas:

  • GitHub registry integration with guided credential setup
  • Gradle support for on-premises or credential-protected repositories
  • Pip support for on-premises or credential-protected repositories

Container Security adds package-level muting and snoozing through the UI and API. A triage decision can apply to a package across all images, rather than being repeated for every image name and tag. This improves consistency, but teams should preserve expiry dates, rationale, and approver records for deferred findings.

DAST introduces recorded browser flows that can be converted into runnable DAST/API tests using current authentication details. Teams can manage API collections and authentication scripts from environment settings, then organize recordings into ordered business flows. Failure handling identifies dependent recordings that are skipped and provides an error with a screenshot.

These changes make it more practical to test authenticated, multi-step business processes. Release teams should treat recordings as test assets: assign ownership, review changes, and validate them when authentication or critical user journeys change. DAST also now alerts on unsecured TLS connections and includes these alerts in the default environment policy.

A focused implementation plan will produce better results than enabling every capability at once.

  • Inventory AI-related code assets with AISC and identify accountable owners.
  • Approve MCP clients, role mappings, audit review, and AI assistant usage boundaries.
  • Rework net-new vulnerability rules by scanner and document global break-build criteria.
  • Add SAST scanned-file evidence and policy-violation API exports to audit workflows.
  • Pilot package-level container triage and recorded DAST flows in selected product teams.
  • Validate private registry credentials, SCA delta scan behavior, and repository integration settings.

macOS CLI users should also update to CLI version 2.3.51 because the macOS binary has been re-signed and certificates for earlier macOS CLI binaries were revoked. Jenkins plugin version 2.0.13-848.v76e89de8a_053 uses this CLI version.

How Merito helps

Merito helps organizations convert Checkmarx One 3.60 features into governed delivery practices. We can assess AI supply chain exposure, design policy and release-gate models, configure repository and private registry integrations, establish audit evidence flows, and create operating procedures for MCP-enabled security workflows.

The objective is measurable: improve security coverage and evidence quality while keeping engineering teams focused on prioritized, actionable work.

Merito is an authorized Checkmarx reseller and services partner. Our Checkmarx One team can scope licensing, sizing, and rollout for 3.60, and our enterprise upgrade services help you plan and validate the upgrade with minimal disruption to release schedules.

About Checkmarx products

Checkmarx licenses, renewals, upgrades and implementation are available through Merito, an authorized Checkmarx reseller and services partner.

Frequently Asked Questions