Checkmarx CxONE 3.60: Tighter AI Supply Chain Governance and Policy Control
CheckMarx CxONE 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.
CheckMarx CxONE 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.
July 14, 2026
By Chris Carpenter
AppSec
DevSecOps
SAST
DAST
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
CxONE 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.
Recommended adoption priorities
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.
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 CxONE 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 a CheckMarx partner. Our CheckMarx CxONE 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.
Frequently Asked Questions
AI Supply Chain Security identifies AI-related assets in source code and configuration, including agents, models, MCP clients and servers, ML libraries, and AI SDKs. It can run through repository integrations and SCM events, then present detected assets in a dedicated results view and apply policy controls. Merito can help define an AI asset inventory, ownership model, and policy baseline that fit existing AppSec governance.
The MCP Server lets developers and AppSec teams manage projects, initiate scans, review findings, and work on remediation from supported AI assistant and IDE chat interfaces. It uses Checkmarx One authentication and RBAC, supports OAuth and Dynamic Client Registration, and records activity through audit logging. Security leaders should approve supported clients, scope roles carefully, and establish logging review expectations before broad rollout.
Teams can now set net-new vulnerability severity thresholds independently for each scanner, so pull-request policy decisions reflect the scanners relevant to that rule. The Break Build setting now sits at the global policy level, separating release-gate behavior from individual rule logic. Merito can help rationalize existing policies, reduce duplicate rules, and test gate changes against representative pipelines.
Project reports can include a SAST Scanned Files section that lists analyzed files and the number of SAST vulnerabilities found in each file. The new Policy Violations Download API also provides programmatic access to SAST and SCA policy-violating findings. Together, these additions improve traceability for control testing, audit requests, and migration from CxSAST on-premises reporting.
Platform teams should assess AI Supply Chain scanner enablement, MCP client governance, scanner-level policy rules, and the policy-violations API first. They should also review SCA delta-scan behavior, private registry connections, container package-level triage, and DAST recorded-flow management. Merito can run an adoption workshop that turns these release capabilities into an ordered implementation backlog.
Keep Reading
Related Product Release Updates
Explore a few more Merito release updates that align with the themes in this article.
.png&w=2560&q=75)