Checkmarx One

Ingests and normalizes findings from multiple AppSec tools (SAST, DAST, SCA, container scanning, secrets scanning) into a single unified finding model with a consistent severity scale across sources.

Groups findings from multiple tools that refer to the same underlying vulnerability in the same code location, presenting one actionable finding instead of multiple redundant alerts.

Scores aggregated findings using multiple contextual factors (exploitability, reachability, internet exposure, threat intelligence, and business criticality) rather than individual tool severity ratings, producing a single actionable priority queue across all AppSec signals.

Scores dependency vulnerabilities by whether the vulnerable function is reachable in the actual application execution path, not just present in the dependency tree, reducing the actionable finding list to confirmed code-level exposures.

Pushes prioritized findings to developer ticketing (Jira, GitHub Issues, Linear), and IDEs with remediation context, removing the security team from the routing path.

Maps aggregated AppSec findings and scan coverage to regulatory and framework controls (PCI DSS Requirement 6, ISO 27001 Annex A.8.28, SOC 2), and generates audit-ready evidence and compliance reports across the application portfolio.

Links each finding to the specific code, component, or pipeline that introduced it and traces it from source through build to the deployed runtime, so teams can fix the underlying cause and see which projects contribute the most risk.

Traverses the full dependency graph to surface CVEs in indirect dependencies, packages required by your direct dependencies. Direct-only scanning misses the majority of vulnerable code paths in modern polyglot projects.

Determines whether a vulnerable function is actually reachable and called in the codebase: not merely present in the dependency tree. Reduces actionable CVEs to those with real exploit paths; requires static code analysis on top of dependency scanning.

Identifies packages with known-malicious behavior (typosquatting, dependency confusion, backdoored releases), distinct from packages with CVEs in legitimate code.

Exports the dependency inventory as a machine-readable Software Bill of Materials in SPDX or CycloneDX format, consumable by downstream vulnerability scanners, compliance tools, and procurement workflows.

Identifies OSS licenses in the dependency tree and flags conflicts with the project's target license or policy (GPL contamination, copyleft obligations, export-controlled components). Separate from vulnerability detection.

Blocks or flags PRs in CI/CD pipelines based on policy-defined thresholds, configurable by severity, CVSS score, exploitability, fix availability, or CVE age. Prevents vulnerable code from merging without requiring zero-tolerance policies.

Identifies hardcoded credentials, API keys, tokens, and private keys in source files. Operates on the repository and commit history, not at runtime.

Scans images stored in registries (ECR, GCR, Artifact Registry, Docker Hub), for vulnerable OS packages and application dependencies at push time or on schedule, without requiring a running container.

Risk context for open-source dependencies including reachability, exploitability, and upgrade impact.

Detection and provenance tracking of AI and ML components, models, and LLM usage within the software supply chain.

Compiles vendor, third-party and open-source maintainer reputation to flag risk from unmaintained, deprecated or abandoned software.

Assessment and policy enforcement of CI/CD pipeline configuration, access, and integrity.

Governs third-party software consumption to apply consistent software supply chain security policy.