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.

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.
• STO supports three different approaches for loading self-signed certificates. For more information, refer Run STO scans with custom SSL certificates.

The following topics contain useful information for setting up scanner integrations in STO:

• What's supported in STO
• Security Testing Orchestration FAQs
• Optimize STO pipelines

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 and then ingest, normalize, and deduplicate the results.

• Extraction Configure the step to extract scan results from an external SaaS service and then ingest, normalize, and deduplicate the data.

• Ingestion Configure the step to read scan results from a data file 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.

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

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

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

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.

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.

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:

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

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 defined in the step or runtime input.

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.

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

The image tag. Examples: latest, 1.2.3

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

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.

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.

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:

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

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

      - stage:
        spec:
          sharedPaths:
            - /shared/scan_results

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

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
  • Image Tag
• Privileged
• Image Pull Policy
• Run as User
• Set Container Resources
• Timeout

Advanced settings

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

• Conditional Execution
• Failure Strategy
• Looping Strategy
• Policy Enforcement

Proxy settings

This step supports Harness Secure Connect if you're using Harness Cloud infrastructure. During the Secure Connect setup, the HTTPS_PROXY and HTTP_PROXY variables are automatically configured to route traffic through the secure tunnel. If there are specific addresses that you want to bypass the Secure Connect 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 (not using Secure Connect), 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.