> 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-custom-scanning-and-ingestion/custom-ingest-reference.md).

# Custom Ingest step for SARIF and JSON scan results

The Custom Ingest step enables you to ingest results from any third-party scanner. Harness STO supports two generic data formats:

* [SARIF](https://docs.oasis-open.org/sarif/sarif/v2.1.0/sarif-v2.1.0.html) is an open data format supported by many scan tools, especially tools available as GitHub Actions. You can easily ingest SARIF 2.1.0 data from any tool that supports this format. If your scanner can export to SARIF, use this format. For more information, go to [Ingest SARIF results](/security-testing-orchestration/use-sto/sto-custom-scanning-and-ingestion/ingest-sarif-data.md).
* Harness STO supports a custom JSON format that's useful for ingesting data from scanners that currently have no integration in STO and that cannot publish to SARIF. For more information, go to [Ingest Results from Unsupported Scanners](/security-testing-orchestration/use-sto/sto-custom-scanning-and-ingestion/ingesting-issues-from-other-scanners.md).

{% hint style="info" %}
The Custom Ingest step is intended for scanners that have no supported integration in STO. Harness recommends that you always use the documented workflow for supported scanners. For a list of all STO-supported scanners, go to [Supported Scanners](/security-testing-orchestration/new-to-sto/sto-whats-supported/scanners.md).
{% endhint %}

### For more information <a href="#for-more-information" id="for-more-information"></a>

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)

### Custom Ingest step settings for STO scans <a href="#custom-ingest-step-settings-for-sto-scans" id="custom-ingest-step-settings-for-sto-scans"></a>

#### Scan <a href="#scan" id="scan"></a>

**Scan mode**

* **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 <a href="#target" id="target"></a>

**Type**

The target type of the scanned object. You can ingest data for the following target types:

* **Repository** Ingest scan results for a code repo.
* **Container image** Ingest scan results for the layers, libraries, and packages in a container image.
* **Instance** Ingest scan results for a running application.
* **Configuration** Ingest scan results for your cloud environment, generated by gathering configuration data via the cloud provider's APIs.

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

#### Ingestion <a href="#ingestion" id="ingestion"></a>

**Ingestion File**

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

#### Log Level, CLI flags, and Fail on Severity <a href="#log-level-cli-flags-and-fail-on-severity" id="log-level-cli-flags-and-fail-on-severity"></a>

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

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

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

#### Advanced settings <a href="#advanced-settings" id="advanced-settings"></a>

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 <a href="#proxy-settings" id="proxy-settings"></a>

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.

### Custom Ingest pipeline examples <a href="#custom-ingest-pipeline-examples" id="custom-ingest-pipeline-examples"></a>

Here are some topics that describe end-to-end workflows for ingesting SARIF and JSON data:

* [Gitleaks step configuration](/security-testing-orchestration/use-sto/sto-scanner-configuration/gitleaks-scanner-reference.md)
* [Checkmarx step configuration](/security-testing-orchestration/use-sto/sto-scanner-configuration/checkmarx/checkmarx-scanner-reference.md)
* [Run scans using GitHub Action and Drone Plugin steps](/security-testing-orchestration/troubleshooting-and-resources/sto-use-cases/set-up-sto-pipelines/run-scans-using-github-actions.md)
* [Ingest JSON results from custom or unsupported scanners](/security-testing-orchestration/use-sto/sto-custom-scanning-and-ingestion/ingesting-issues-from-other-scanners.md)