> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/security-testing-orchestration/use-sto/sto-scanner-configuration/checkmarx/checkmarxone-scanner-reference.md). # Checkmarx One step configuration The Checkmarx One step in Harness STO can help you perform code scanning, container image scanning and DAST for security vulnerabilities. It performs the following scans * **Static Application Security Testing (SAST)** - Analyzes source code for security vulnerabilities. * **Secret Scanning** - Detects hardcoded secrets in the codebase. * **Software Composition Analysis (SCA)** — Scans dependencies and third-party libraries for vulnerabilities, including files related to container images in the repository. * **Infrastructure as Code (IaC)** - Identifies security misconfigurations in IaC files. * **Container Scanning** - Scan the layers, libraries, and packages in a container image. * **Instance Scanning** - Scan a running application. This document provides details to understand the step fields and configure them. {% hint style="info" %} * You can utilize custom STO scan images and pipelines to run scans as a non-root user. For more details, refer [Configure your pipeline to use STO images from private registry](/security-testing-orchestration/troubleshooting-and-resources/sto-use-cases/set-up-sto-pipelines/configure-pipeline-to-use-sto-images-from-private-registry.md). * STO supports three different approaches for loading self-signed certificates. For more information, refer [Run STO scans with custom SSL certificates](/security-testing-orchestration/troubleshooting-and-resources/sto-use-cases/secure-sto-pipelines/ssl-setup-in-sto.md#supported-workflows-for-adding-custom-ssl-certificates). {% endhint %} ### Checkmarx One step settings The recommended workflow is to add a Checkmarx One step to a **Security** or **Build** stage and then configure it as described below. #### Scan **Scan Mode** * **Orchestration** Configure the step to [run a scan](/security-testing-orchestration/new-to-sto/key-concepts/run-an-orchestrated-scan-in-sto.md) and then ingest, normalize, and deduplicate the results. * **Extraction** Configure the step to [extract scan results from an external SaaS service](/security-testing-orchestration/new-to-sto/key-concepts/sto-workflows-overview.md#extraction-workflows-in-sto) and then ingest, normalize, and deduplicate the data. * **Ingestion** Configure the step to [read scan results from a data file](/security-testing-orchestration/new-to-sto/key-concepts/ingest-scan-results-into-an-sto-pipeline.md) and then ingest, normalize, and deduplicate the data. **Scan Configuration** The predefined configuration to use for the scan. All scan steps have at least one configuration. #### Target **Type** * **Repository** Scan a codebase repo. In most cases, you specify the codebase using a code repo connector that connects to the Git account or repository where your code is stored. For information, go to [Configure codebase](/continuous-integration/use-harness-ci/use-harness-ci/codebase-configuration/create-and-configure-a-codebase.md). * **Container Image** Scan the layers, libraries, and packages in a container image. * **Instance** Scan a running application. Choose the Target **Type** to display and configure the relevant fields for that scan target. {% tabs %} {% tab title="Repository" %} **Target and variant detection** When **Auto** is enabled for code repositories, the step detects these values using `git`: * To detect the target, the step runs `git config --get remote.origin.url`. * To detect the variant, the step runs `git rev-parse --abbrev-ref HEAD`. The default assumption is that the `HEAD` branch is the one you want to scan. Note the following: * **Auto** is not available when the **Scan Mode** is **Ingestion**. * By default, **Auto** is selected when you add the step. You can change this setting if needed. **Name** The identifier for the [target](/security-testing-orchestration/new-to-sto/key-concepts/targets-and-baselines.md), such as `codebaseAlpha` or `jsmith/myalphaservice`. Descriptive target names make it much easier to navigate your scan data in the STO UI. It is good practice to [specify a baseline](/security-testing-orchestration/new-to-sto/key-concepts/targets-and-baselines.md#every-target-needs-a-baseline) for every target. **Variant** The identifier for the specific variant to scan. This is usually the branch name, image tag, or product version. Harness maintains a historical trend for each variant. **Workspace** The workspace path on the pod running the scan step. The workspace path is `/harness` by default. You can override this if you want to scan only a subset of the workspace. For example, suppose the pipeline publishes artifacts to a subfolder `/tmp/artifacts` and you want to scan these artifacts only. In this case, you can specify the workspace path as `/harness/tmp/artifacts`. Additionally, you can specify individual files to scan as well. For instance, if you only want to scan a specific file like `/tmp/iac/infra.tf`, you can specify the workspace path as `/harness/tmp/iac/infra.tf` #### Authentication {% tabs %} {% tab title="API Key" %} **Access Token** The access token to log in to the scanner. This is usually a password or an API key. You should create a Harness text secret with your encrypted token and reference the secret using the format `<+secrets.getValue("my-access-token")>`. For more information, go to [Add and Reference Text Secrets](/harness-ai/use-harness-platform/secrets/add-use-text-secrets.md). {% endtab %} {% tab title="Username and Password" %} **Domain** The fully-qualified URL to the scanner. **Access ID** The username to log in to the scanner. For **Access ID**, you can use an existing OAuth client in Checkmarx or create a new one and use its `Client ID`. **Access Token** The access token to log in to the scanner. This is usually a password or an API key. You should create a Harness text secret with your encrypted token and reference the secret using the format `<+secrets.getValue("my-access-token")>`. For more information, go to [Add and Reference Text Secrets](/harness-ai/use-harness-platform/secrets/add-use-text-secrets.md). For **Access ID**, you can use an existing OAuth client in Checkmarx or create a new one and use its `Client Secret`. {% endtab %} {% endtabs %} *** #### Ingestion File This filed is visible when you are using **Ingestion** Scan Mode The path to your scan results when running an [Ingestion scan](/security-testing-orchestration/new-to-sto/key-concepts/ingest-scan-results-into-an-sto-pipeline.md), for example `/shared/scan_results/myscan.latest.sarif`. * The data file must be in a [supported format](/security-testing-orchestration/new-to-sto/sto-whats-supported/scanners.md#supported-ingestion-formats) for the scanner. * The data file must be accessible to the scan step. It's good practice to save your results files to a [shared path](/continuous-integration/new-to-harness-ci/key-concepts.md#stages) in your stage. In the visual editor, go to the stage where you're running the scan. Then go to **Overview** > **Shared Paths**. You can also add the path to the YAML stage definition like this: ```yaml - stage: spec: sharedPaths: - /shared/scan_results ``` #### Scan Tool **Project Name** The name of the scan project as defined in the scanner. This is the also the target name in the Harness UI (Security Tests > Test Targets). If the specified project does not exist, the step will create a new project using the provided Project Name. **Use Raw Scanner Severity** This option allows you to configure the step to use the severity reported directly by the scanner. By default, STO assigns severity based on numeric scores (such as CVSS). When this option is enabled, STO bypasses its internal severity mapping and uses the severity levels reported by the scanner (e.g., Critical, High, Medium, Low). To enable this behavior, check the **Use Raw Scanner Severity** field (recommended), or add `ingest_tool_severity: true` setting in the **Settings** section. {% endtab %} {% tab title="Container Image" %} **Target and variant detection** When **Auto** is enabled for container images, the step detects the target and variant using the **Container Image Name** and **Tag/Digest** defined in the step or runtime input. Note the following: * **Auto** is not available when the **Scan Mode** is **Ingestion**. * By default, **Auto** is selected when you add the step. You can change this setting if needed. **Name** The identifier for the [target](/security-testing-orchestration/new-to-sto/key-concepts/targets-and-baselines.md), such as `codebaseAlpha` or `jsmith/myalphaservice`. Descriptive target names make it much easier to navigate your scan data in the STO UI. It is good practice to [specify a baseline](/security-testing-orchestration/new-to-sto/key-concepts/targets-and-baselines.md#every-target-needs-a-baseline) for every target. **Variant** The identifier for the specific variant to scan. This is usually the branch name, image tag, or product version. Harness maintains a historical trend for each variant. #### Container Image **Type** The registry type where the image is stored: * **Docker v2** A registry that uses the Docker Registry v2 API such as [Docker Hub](https://docs.docker.com/registry/spec/api/), [Google Container Registry](https://cloud.google.com/container-registry), or [Google Artifact Registry](https://cloud.google.com/artifact-registry). STO will automatically pull and scan the container image or OCI/Docker archive. * [**AWS ECR**](https://aws.amazon.com/ecr/) Set your AWS ECR connector with image details. STO will automatically pull and scan the container image or OCI/Docker archive. * [**Jfrog Artifactory**](https://jfrog.com/artifactory/) Set your Jfrog Artifactory connector with image details. STO will automatically pull and scan the container image or OCI/Docker archive. * **Local Image in this Stage** Scan a local image built and stored within the context of the current stage (via `/var/run/docker.sock` registered as a stage level volume mount). For this, you will need to [configure Docker-in-Docker](/security-testing-orchestration/use-sto/sto-scanner-configuration/security-step-settings-reference.md#configuring-docker-in-docker-dind-for-your-pipeline) as a background step. STO will identify and scan the container image matching the step configuration inside the Docker-in-Docker background within that stage. * **Local OCI/Docker archive in this Stage** Scan an OCI or Docker archive created and stored within the current stage. STO will scan the archive based on the path configured in the workspace field during the step. Ensure that the path to which the archive is saved is a shared volume mount. **Domain** The URL of the registry that contains the image to scan. Examples include: * `docker.io` * `app.harness.io/registry` * `us-east1-docker.pkg.dev` **Name** The image name. For non-local images, you also need to specify the image repository. Example: `jsmith/myalphaservice` **Tag/Digest** The image tag or digest. Examples: `latest`, `1.2.3`, `@sha256:abc123...` **Access Id** The username to log in to the image registry. **Access Token** The access token used to log in to the image registry. This is usually a password or an API key. You should create a Harness text secret with your encrypted token and reference the secret using the format `<+secrets.getValue("container-access-id")>`. For more information, go to [Add and Reference Text Secrets](/harness-ai/use-harness-platform/secrets/add-use-text-secrets.md). #### Authentication {% tabs %} {% tab title="API Key" %} **Access Token** The access token to log in to the scanner. This is usually a password or an API key. You should create a Harness text secret with your encrypted token and reference the secret using the format `<+secrets.getValue("my-access-token")>`. For more information, go to [Add and Reference Text Secrets](/harness-ai/use-harness-platform/secrets/add-use-text-secrets.md). {% endtab %} {% tab title="Username and Password" %} **Domain** The fully-qualified URL to the scanner. **Access ID** The username to log in to the scanner. For **Access ID**, you can use an existing OAuth client in Checkmarx or create a new one and use its `Client ID`. **Access Token** The access token to log in to the scanner. This is usually a password or an API key. You should create a Harness text secret with your encrypted token and reference the secret using the format `<+secrets.getValue("my-access-token")>`. For more information, go to [Add and Reference Text Secrets](/harness-ai/use-harness-platform/secrets/add-use-text-secrets.md). For **Access ID**, you can use an existing OAuth client in Checkmarx or create a new one and use its `Client Secret`. {% endtab %} {% endtabs %} *** #### Ingestion File This filed is visible when you are using **Ingestion** Scan Mode The path to your scan results when running an [Ingestion scan](/security-testing-orchestration/new-to-sto/key-concepts/ingest-scan-results-into-an-sto-pipeline.md), for example `/shared/scan_results/myscan.latest.sarif`. * The data file must be in a [supported format](/security-testing-orchestration/new-to-sto/sto-whats-supported/scanners.md#supported-ingestion-formats) for the scanner. * The data file must be accessible to the scan step. It's good practice to save your results files to a [shared path](/continuous-integration/new-to-harness-ci/key-concepts.md#stages) in your stage. In the visual editor, go to the stage where you're running the scan. Then go to **Overview** > **Shared Paths**. You can also add the path to the YAML stage definition like this: ```yaml - stage: spec: sharedPaths: - /shared/scan_results ``` #### Scan Tool **Project Name** The name of the scan project as defined in the scanner. This is the also the target name in the Harness UI (Security Tests > Test Targets). If the specified project does not exist, the step will create a new project using the provided Project Name. **Use Raw Scanner Severity** This option allows you to configure the step to use the severity reported directly by the scanner. By default, STO assigns severity based on numeric scores (such as CVSS). When this option is enabled, STO bypasses its internal severity mapping and uses the severity levels reported by the scanner (e.g., Critical, High, Medium, Low). To enable this behavior, check the **Use Raw Scanner Severity** field (recommended), or add `ingest_tool_severity: true` setting in the **Settings** section. {% endtab %} {% tab title="Instance" %} **Target and variant detection** When **Auto** is enabled for application instances, the step detects these values as follows: * The target is based on the **Instance Domain** and **Path** defined in the step or runtime input, for example `https://qa.jpgr.org:3002/login/us`. * The variant is the UTC timestamp when the step scanned the instance. Note the following: * **Auto** is not available when the **Scan Mode** is Ingestion. * **Auto** is the default selection for new pipelines. **Manual** is the default for old pipelines, but you might find that neither radio button is selected in the UI. * You should carefully consider the [baseline you want to specify](/security-testing-orchestration/troubleshooting-and-resources/sto-use-cases/set-up-sto-pipelines/set-up-baselines.md) for your instance target. Every target needs a baseline to enable the full suite of STO features. Here are a few options: * Specify a RegEx baseline that captures timestamps. This ensures that every new scan compares issues in the new scan vs. the previous scan. Then it updates the baseline to the current scan. You can use this RegEx to capture timestamps: `\d{2}/\d{2}/\d{4}\,\s\d{2}\:\d{2}\:\d{2}` * Specify a fixed baseline. 1. Scan the instance using a manual variant name. 2. Select the baseline as a fixed value. 3. Update the step to use auto-detect for future scans. This ensures that future scans get compared with one fixed baseline. **Name** The identifier for the [target](/security-testing-orchestration/new-to-sto/key-concepts/targets-and-baselines.md), such as `codebaseAlpha` or `jsmith/myalphaservice`. Descriptive target names make it much easier to navigate your scan data in the STO UI. It is good practice to [specify a baseline](/security-testing-orchestration/new-to-sto/key-concepts/targets-and-baselines.md#every-target-needs-a-baseline) for every target. **Variant** The identifier for the specific variant to scan. This is usually the branch name, image tag, or product version. Harness maintains a historical trend for each variant. #### Authentication **Domain** The fully-qualified URL to the scanner. **Access Token** The access token to log in to the scanner. This is usually a password or an API key. You should create a Harness text secret with your encrypted token and reference the secret using the format `<+secrets.getValue("my-access-token")>`. For more information, go to [Add and Reference Text Secrets](/harness-ai/use-harness-platform/secrets/add-use-text-secrets.md). *** #### Ingestion File This filed is visible when you are using **Ingestion** Scan Mode The path to your scan results when running an [Ingestion scan](/security-testing-orchestration/new-to-sto/key-concepts/ingest-scan-results-into-an-sto-pipeline.md), for example `/shared/scan_results/myscan.latest.sarif`. * The data file must be in a [supported format](/security-testing-orchestration/new-to-sto/sto-whats-supported/scanners.md#supported-ingestion-formats) for the scanner. * The data file must be accessible to the scan step. It's good practice to save your results files to a [shared path](/continuous-integration/new-to-harness-ci/key-concepts.md#stages) in your stage. In the visual editor, go to the stage where you're running the scan. Then go to **Overview** > **Shared Paths**. You can also add the path to the YAML stage definition like this: ```yaml - stage: spec: sharedPaths: - /shared/scan_results ``` #### Scan Tool **Team Name** Enter your Checkmarx One [Tenant Name](https://docs.checkmarx.com/en/34965-68530-logging-in-to-checkmarx-one.html).\ Provide the tenant name in the format `//`.\ Example: `/server1.myorg.org/devOpsEast` **Project Name** Enter the project name to be scanned. * If the specified project does not exist, the step creates a new project with the provided name. * The provided [Domain URL](#domain-3) is configured as the project name if a new project is created. **Environment ID** Enter your [Checkmarx One Environment ID](https://docs.checkmarx.com/en/34965-154695-dast-creating-environments.html). You can execute the step by entering only the existing Checkmarx One Environment ID without specifying any optional fields. **Scan Type** Select the scan type based on your use case: * **WEB**: Select if scanning a web application. * **API**: Select if scanning an API. **Context Name** Specify the Checkmarx context file to use for the scan. * You must add the following shared path (**Overview** > **Shared Paths**) to your stage and copy your context file to this location:\ `/shared/customer_artifacts/context/` **Use Raw Scanner Severity** This option allows you to configure the step to use the severity reported directly by the scanner. By default, STO assigns severity based on numeric scores (such as CVSS). When this option is enabled, STO bypasses its internal severity mapping and uses the severity levels reported by the scanner (e.g., Critical, High, Medium, Low). To enable this behavior, check the **Use Raw Scanner Severity** field (recommended), or add `ingest_tool_severity: true` setting in the **Settings** section. {% endtab %} {% endtabs %} *** #### Log Level The minimum severity of the messages you want to include in your scan logs. You can specify one of the following: * **DEBUG** * **INFO** * **WARNING** * **ERROR** **Fail on Severity** Every STO scan step has a **Fail on Severity** setting. If the scan finds any vulnerability with the specified [severity level](/security-testing-orchestration/new-to-sto/key-concepts/severities.md) or higher, the pipeline fails automatically. You can specify one of the following: * **`CRITICAL`** * **`HIGH`** * **`MEDIUM`** * **`LOW`** * **`INFO`** * **`NONE`** — Do not fail on severity The YAML definition looks like this: `fail_on_severity : critical # | high | medium | low | info | none` #### Optional Settings For repository scans, you can optionally add the following key value pairs to the **Settings** section of your Checkmarx One step. Harness STO uses these values to call the Checkmarx One API and retrieve repository scan metadata that is not exposed by the Checkmarx One CLI. * **`product_domain`:** The regional IAM base URL for your Checkmarx One environment. * **`product_team_name`:** Your Checkmarx One tenant name, also referred to as your account or organization name. #### Exclude issues marked as Not Exploited You can configure the CheckmarxOne ingestion step to exclude issues detected by CheckmarxOne but flagged as Not Exploitable. To enable this setting, add the following key-value pair under **Settings**: `hide_not_exploitable` : `True` #### Additional Configuration The fields under **Additional Configuration** vary based on the type of infrastructure. Depending on the infrastructure type selected, some fields may or may not appear in your settings. Below are the details for each field * Override Security Test Image * [Container Registry](/security-testing-orchestration/troubleshooting-and-resources/sto-use-cases/set-up-sto-pipelines/configure-pipeline-to-use-sto-images-from-private-registry.md#step-level-override) * [Image Tag](/security-testing-orchestration/troubleshooting-and-resources/sto-use-cases/set-up-sto-pipelines/configure-pipeline-to-use-sto-images-from-private-registry.md#step-level-override) * [Privileged](/continuous-integration/use-harness-ci/use-harness-ci/manage-dependencies/background-step-settings.md#privileged) * [Image Pull Policy](/continuous-integration/use-harness-ci/use-harness-ci/manage-dependencies/background-step-settings.md#image-pull-policy) * [Run as User](/continuous-integration/use-harness-ci/use-harness-ci/manage-dependencies/background-step-settings.md#run-as-user) * [Set Container Resources](/continuous-integration/use-harness-ci/use-harness-ci/manage-dependencies/background-step-settings.md#set-container-resources) * [Timeout](/continuous-integration/use-harness-ci/use-harness-ci/run-step-settings.md#timeout) #### Advanced settings In the **Advanced** settings, you can use the following options: * [Conditional Execution](/harness-ai/use-harness-platform/pipelines/step-skip-condition-settings.md) * [Failure Strategy](/harness-ai/use-harness-platform/pipelines/failure-handling/define-a-failure-strategy-on-stages-and-steps.md) * [Looping Strategy](/harness-ai/use-harness-platform/pipelines/looping-strategies/looping-strategies-matrix-repeat-and-parallelism.md) * [Policy Enforcement](/harness-ai/use-harness-platform/governance/policy-as-code/harness-governance-overview.md) ### Proxy settings This step supports private network connectivity if you're using Harness Cloud infrastructure. For information on connectivity options, see [Private network connectivity options](/harness-ai/use-harness-platform/references/private-network-connectivity/private-network-connectivity.md). When using proxy configurations, the `HTTPS_PROXY` and `HTTP_PROXY` variables are automatically set to route traffic through the secure tunnel. If there are specific addresses that you want to bypass the proxy, you can define those in the `NO_PROXY` variable. This can be configured in the **Settings** of your step. If you need to configure a different proxy, you can manually set the `HTTPS_PROXY`, `HTTP_PROXY`, and `NO_PROXY` variables in the **Settings** of your step. **Definitions of Proxy variables:** * `HTTPS_PROXY`: Specify the proxy server for HTTPS requests, example `https://sc.internal.harness.io:30000` * `HTTP_PROXY`: Specify the proxy server for HTTP requests, example `http://sc.internal.harness.io:30000` * `NO_PROXY`: Specify the domains as comma-separated values that should bypass the proxy. This allows you to exclude certain traffic from being routed through the proxy. ### View Checkmarx One issue state Harness STO displays the Checkmarx One issue state, including custom states, in the **Issue Details** side panel for repository, container image, and instance scans.