> 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/harness-security-scanners/sast.md).

# Harness Code Scanner

Harness Code scanner integrates directly into your CI/CD pipelines to scan source code for security vulnerabilities, secrets, and open-source dependencies - without requiring external scanners or connectors.

With one-click configuration, Harness automatically manages authentication and licensing, while providing built-in [data flow visualization](#data-flow), [reachability analysis](#reachability) to determine whether a vulnerability is exploitable, and [AI-powered remediation](#ai-remediation-for-harness-code-security-issues) to help developers quickly understand and fix issues.

The Harness Code step works natively within STO, with all findings unified and visible alongside results from other security scanners.

{% hint style="info" %}

#### Licensing <a href="#licensing" id="licensing"></a>

Running the Harness Code step in STO pipelines requires a Harness SAST Enterprise license.

For licensing details or to enable the Enterprise license, contact [Harness Sales](mailto:support@harness.io).

#### Free Trial <a href="#free-trial" id="free-trial"></a>

A **45-day free trial** is available. If you are an existing Harness STO customer and want to access the Harness scanners, contact the [Harness sales](mailto:support@harness.io) representative to have them enabled for your account.
{% endhint %}

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

* [What's supported in STO](/security-testing-orchestration/new-to-sto/sto-whats-supported/sto-deployments.md)
* [Security Testing Orchestration FAQs](/security-testing-orchestration/troubleshooting-and-resources/faqs.md)
* [Optimize STO pipelines](/security-testing-orchestration/troubleshooting-and-resources/sto-use-cases/set-up-sto-pipelines/optimize-sto-pipelines.md)

### Harness Code step settings for STO scans <a href="#harness-code-step-settings-for-sto-scans" id="harness-code-step-settings-for-sto-scans"></a>

Setting up the Harness Code scanner is the same as configuring any other [built-in scanner step](/security-testing-orchestration/use-sto/set-up-sto-scans/built-in-scanners.md). The required configuration is handled automatically, making the setup process simple and straightforward. Here’s how to set it up:

* In your Build or Security stage, open the step palette by clicking the **Add Step** option in your pipeline.
* Navigate to the Harness Security Scanners section under the Security Tests category.

<figure><img src="/files/nf4QwSSh88H8W0e8t8tH" alt=""><figcaption><p>Add shared path for scan results</p></figcaption></figure>

\- By default, all the below fields are configured automatically by the Harness Code scanner.

* Set the **Scan Mode** to **Orchestration**.
* Set the **Scan Configuration** to one of the following:
  * **SAST** — Scan for code vulnerabilities and secrets. Requires a **Harness SAST** license.
  * **SCA** — Scan for application layer dependency vulnerabilities. Requires both **Harness SAST** and **Harness SCA** licenses.
  * **SAST + SCA** — Perform both SAST and SCA scans. Requires both **Harness SAST** and **Harness SCA** licenses.
* Set the **Target Type** to **Repository**.

To run the Harness Code scan step in the pipeline, no further configuration is required; If you want to add additional scan settings, you can configure the following below fields in the step.

<figure><img src="/files/lgPOSNJSSrknEXAt0bKC" alt=""><figcaption><p>Add shared path for scan results</p></figcaption></figure>

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

When you select it as **Manual**, specify the name and variant of the code repo.

**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 (*****repository*****)**

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

You can also override this to scan a JAR, WAR, or EAR file by specifying the exact file location. For example, `/harness/target/myapp.jar`.

{% hint style="info" %}

* The Harness Code scanner is not supported in SMP.
* With a Harness Code Enterprise license, you also get access to the **Qwiet AI by Harness** platform. AppSec users can log in to the platform.
* The Qwiet AI dashboard does not support [exemptions](/security-testing-orchestration/use-sto/sto-exempt-issues/issue-exemption-workflow.md), so any issues you mark as exempt in Harness STO will not appear as exempted in Qwiet AI. Exemptions must be managed in Harness STO only.
  {% endhint %}

#### Scan Tool <a href="#scan-tool" id="scan-tool"></a>

**Target Language**

Specify which programming language needs to be analyzed in the scan by passing the corresponding parameter. [Learn more](https://docs.shiftleft.io/sast/analyzing-applications/apex) about the supported languages.

| Language              | Parameter                    |
| --------------------- | ---------------------------- |
| Apex                  | `--apex`                     |
| C/C++                 | `--c`                        |
| C#                    | `--csharp`                   |
| Go                    | `--go`                       |
| Java                  | `--java`                     |
| JavaScript/TypeScript | `--javascript` / `--jssrc`\* |
| Kotlin (Beta)         | `--kotlin`                   |
| PHP (Beta)            | `--php`                      |
| PL/SQL (Beta)         | `--plsql`                    |
| Python                | `--python`                   |
| Ruby (Beta)           | `--ruby`                     |
| Scala                 | `--java` (uses Java flag)    |
| Swift (Alpha)         | `--swift` (if applicable)    |
| Terraform             | `--terraform`                |

**App Name**

Provide a unique name to identify the scanning application. All scan results for this application are grouped and tracked under this name in the [Qwiet AI by Harness dashboard](https://docs.shiftleft.io/sast/ui-v2/dashboard).

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

**Additional CLI flags**

Use this field to run the scanner binary with additional flags supported by the scanner.

* Instead of running two separate Harness Code and Container scans, you can use the Harness Code scanner to scan container images and determine [dependency reachability](https://docs.shiftleft.io/sast/analyzing-applications/containers#including-the-container-in-the-analysis) by adding the `--container` flag with the image name. Example: `--container docker.io/shiftleft/demoContainer:latest`. This requires an active [**Harness Container**](/security-testing-orchestration/use-sto/harness-security-scanners/sca.md) license

{% hint style="warning" %}
Passing additional CLI flags is an advanced feature. Harness recommends the following best practices:

* Test your flags and arguments thoroughly before you use them in your Harness pipelines. Some flags might not work in the context of STO.
* Don't add flags that are already used in the default configuration of the scan step.

  To check the default configuration, go to a pipeline execution where the scan step ran with no additional flags. Check the log output for the scan step. You should see a line like this:

  `Command [ scancmd -f json -o /tmp/output.json ]`

  In this case, don't add `-f` or `-o` to **Additional CLI flags**.
  {% endhint %}

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

#### Settings <a href="#settings" id="settings"></a>

You can use this field to specify environment variables for your scanner.

#### Additional Configuration <a href="#additional-configuration" id="additional-configuration"></a>

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)

#### View Harness Code Scanner results in the Vulnerabilities tab <a href="#view-harness-code-scanner-results-in-the-vulnerabilities-tab" id="view-harness-code-scanner-results-in-the-vulnerabilities-tab"></a>

After running the Harness Code scanner in your pipeline, navigate to the Vulnerabilities tab. Use the **Issue Type** filter to view all vulnerabilities detected by the scanner, including **SAST**, **SCA (Open Source dependencies)**, and **Secrets**.

<figure><img src="/files/DWWFLJOwANI5b0eIJheK" alt=""><figcaption><p>Add shared path for scan results</p></figcaption></figure>

#### Secret Detection <a href="#secret-detection" id="secret-detection"></a>

Harness Code detects hardcoded secrets in your code, such as API keys, tokens, and passwords, helps you prevent accidental credential leaks early in the development lifecycle. After the successful pipeline run, in the vulnerabilities tab, apply the **Issue Type** filter as **Secret** to view the Secrets identified by the Harness Code scanner.

<figure><img src="/files/leJ8BrMrVOvchJRcjvXy" alt=""><figcaption><p>Add shared path for scan results</p></figcaption></figure>

#### Static Reachability <a href="#static-reachability" id="static-reachability"></a>

A vulnerability is considered as Reachable when an attacker can reach the affected code (CVE) through a controlled path from application input. A vulnerability is marked as Reachable if at least one of its occurrences is reachable. Exempted occurrences are not considered. You can view the Reachability for each of the occurrences of a security issue in the [**Vulnerabilities**](/security-testing-orchestration/use-sto/sto-security-issues/view-scan-results.md) and [**Issues**](/security-testing-orchestration/use-sto/sto-security-issues/issues.md) page.

After a successful pipeline run, the Vulnerabilities tab shows whether a vulnerability is marked as Reachable. On the Vulnerabilities page, use the Reachability filter to view findings by reachability. This helps reduce noise and focus on vulnerabilities that pose real risk. [Learn more](https://docs.shiftleft.io/sast/analyzing-applications/oss-vulnerabilities?_highlight=reac#reachable-and-exploitable-findings).

<figure><img src="/files/fLqLX5dmpp9F7lZNVW5f" alt=""><figcaption><p>Add shared path for scan results</p></figcaption></figure>

#### Data Flow <a href="#data-flow" id="data-flow"></a>

The Data Flow helps you understand how an issue propagates through your application by leveraging the [Code Property Graph (CPG)](https://docs.shiftleft.io/core-concepts/code-property-graph), making it easier to assess risk and prioritize remediation by showing the path from the source to the sink.

**SOURCE:** The part of the code that allows the issue to occur. For example, a function that accepts user input could be the source of a command injection vulnerability.

**SINK:** The point where the issue is triggered or exploited. For example, a command executed using unvalidated user input would be the sink.

You can view the Dataflow for each of the occurrences of a security issue in the [**Vulnerabilities**](/security-testing-orchestration/use-sto/sto-security-issues/view-scan-results.md) page.

<figure><img src="/files/Wb4MeSg9U3Ed976KLZHh" alt=""><figcaption><p>Add shared path for scan results</p></figcaption></figure>

#### IDE Integration <a href="#ide-integration" id="ide-integration"></a>

Harness provides a code extension that helps you shift security even further left by allowing you to identify and fix vulnerabilities as you write code. It integrates directly into the developer workflow through IDE plugins for [VS Code](https://docs.shiftleft.io/sast/integrations/vs-code-extension) and [JetBrains](https://docs.shiftleft.io/sast/integrations/jetbrains-plugin), with support for AI-native IDEs such as Cursor and Windsurf coming soon.

Harness also provides a CLI to run SAST and SCA scans locally, to help you identify code vulnerabilities and dependency risks before pushing code to your repository. [Learn more](https://docs.shiftleft.io/cli/reference/overview) on how to install, authenticate, and use the CLI commands in the Harness CLI.

#### AI remediation for Harness Code Security Issues <a href="#ai-remediation-for-harness-code-security-issues" id="ai-remediation-for-harness-code-security-issues"></a>

Harness AI analyzes security issues and provides AI remediation within the security details for each specific issue. This includes an analysis of the issue, remediation concepts, and step-by-step instructions to fix them, along with example code snippets. Additionally, AI remediation details can be found for each occurrence of an issue. You also have the option to make a Code Suggestion or create a **Pull Request** to apply the suggested remediation.

You can view the PR by clicking on the View Fix button. Make sure to read the [configuration details](/security-testing-orchestration/use-sto/sto-remediate-issues/ai-based-remediations.md#configuration-for-code-suggestions-and-create-pull-request-features) to understand the requirements and what is supported for this feature.

<figure><img src="/files/tUdPm4RXJpAT0e0gtyVP" alt=""><figcaption><p>Add shared path for scan results</p></figcaption></figure>

#### Enforce OPA Policy to block the Static Reachable Vulnerabilities <a href="#enforce-opa-policy-to-block-the-static-reachable-vulnerabilities" id="enforce-opa-policy-to-block-the-static-reachable-vulnerabilities"></a>

Enforce OPA Policy to automatically [warn or block pipelines](/security-testing-orchestration/use-sto/enforce-sto-policies-for-governance/create-opa-policies.md#warn-or-block-reachable-or-exploitable-vulnerabilities-reported-by-the-harness-scanner) based on static reachability, exploitability, and license metadata, to help you prevent risky deployments and maintain security and compliance.

#### View Harness Code Scan results in the Qwiet AI Dashboard <a href="#view-harness-code-scan-results-in-the-qwiet-ai-dashboard" id="view-harness-code-scan-results-in-the-qwiet-ai-dashboard"></a>

After running the Harness Code scanner in your pipeline in the scan logs, you can click the provided `shiftleft`link, which redirects you to the [Qwiet AI dashboard](https://docs.shiftleft.io/sast/ui-v2/dashboard), where you can explore detailed scan results and analyze identified issues.

You can also find the Qwiet AI dashboard URL in the pipeline **Output** tab. Look for the `SCANNER_CONSOLE_URL` output variable, which contains the direct link to your scan results in the Qwiet AI dashboard.

Alternatively, you can manually log in to the [Qwiet AI dashboard](https://docs.shiftleft.io/sast/ui-v2/dashboard) and search for the application name that corresponds to the target name used in the scan.

You can view the [generated SBOM](https://docs.shiftleft.io/sast/ui-v2/application-details/sbom) for application dependencies, along with the [scan summary](https://docs.shiftleft.io/sast/ui-v2/application-details/summary) and [compliance results](https://docs.shiftleft.io/sast/ui-v2/application-details/compliance), in the [Qwiet AI by Harness dashboard](https://docs.shiftleft.io/sast/ui-v2/dashboard). These details are currently available only in Qwiet AI by Harness dashboard and are not currently supported in Harness STO.

<figure><img src="/files/waHPkDR3fEVgLUEp9xmc" alt=""><figcaption><p>Add shared path for scan results</p></figcaption></figure>

#### License Usage <a href="#license-usage" id="license-usage"></a>

Usage is calculated based on Active Developers. An Active [Developer](https://docs.shiftleft.io/sast/getting-started/definitions#contributing-developer) is an individual who, within the last 90 days, has created or modified code, configurations, content, or artifacts that are scanned by STO. An individual is counted only once, even if they contribute to multiple scanned repositories.

You can view your current usage and subscription details on the STO subscription page under the **Harness Code and Container** sub-tab.

<figure><img src="/files/dXaIJVuOgmZRBIvmpD8w" alt=""><figcaption><p>Add shared path for scan results</p></figcaption></figure>