Ctrlk
Sign UpGet a DemoContact Us
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Checkmarx One step configuration

Scan code repositories, container and web instances with Checkmarx One.

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.

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

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.

  • 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.

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, 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 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

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.

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.

For Access ID, you can use an existing OAuth client in Checkmarx or create a new one and use its Client Secret.

Ingestion File

This filed is visible when you are using Ingestion Scan Mode

The path to your scan results when running an Ingestion scan, for example /shared/scan_results/myscan.latest.sarif.

  • The data file must be in a supported format 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 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:

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.

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, 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 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, Google Container Registry, or Google Artifact Registry. STO will automatically pull and scan the container image or OCI/Docker archive.

  • AWS ECR Set your AWS ECR connector with image details. STO will automatically pull and scan the container image or OCI/Docker archive.

  • Jfrog 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 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.

Authentication

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.

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.

For Access ID, you can use an existing OAuth client in Checkmarx or create a new one and use its Client Secret.

Ingestion File

This filed is visible when you are using Ingestion Scan Mode

The path to your scan results when running an Ingestion scan, for example /shared/scan_results/myscan.latest.sarif.

  • The data file must be in a supported format 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 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:

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.

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 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, 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 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.

Ingestion File

This filed is visible when you are using Ingestion Scan Mode

The path to your scan results when running an Ingestion scan, for example /shared/scan_results/myscan.latest.sarif.

  • The data file must be in a supported format 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 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:

Scan Tool

Team Name

Enter your Checkmarx One Tenant Name. Provide the tenant name in the format /<server-name>/<team-name>. 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 is configured as the project name if a new project is created.

Environment ID

Enter your Checkmarx One Environment ID. 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.

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 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

Advanced settings

In the Advanced settings, you can use the following options:

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. 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.

PreviousCheckmarx step configuration
NextCheckmarx GitHub Action - Ingestion

Last updated

Was this helpful?