> 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/github-advanced-security.md).

# GitHub Advanced Security step configuration

The GitHub Advanced Security (GHAS) step in Harness STO enables you to scan your code repositories from the following GHAS products:

* [**CodeQL**](#codeql) **(SAST):** Identify code vulnerabilities. Supported in [**Orchestration**](#scan-mode), [**Extraction**](#scan-mode), and [**Ingestion**](#scan-mode).
* [**Dependabot**](#dependabot) **(SCA):** Detect vulnerable open-source dependencies. Supported in [**Orchestration**](#scan-mode), [**Extraction**](#scan-mode), and [**Ingestion**](#scan-mode).
* [**Secret Scanning**](#secret-scanning)**:** Detect exposed secrets such as API keys and tokens. Supported in [**Extraction**](#scan-mode) and [**Ingestion**](#scan-mode).

{% hint style="info" %}

* To run scans as a non-root user, you can use custom STO scan images and pipelines. See [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 multiple workflows for loading self-signed certificates. See [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 %}

### GitHub Advanced Security step settings <a href="#github-advanced-security-step-settings" id="github-advanced-security-step-settings"></a>

The recommended workflow is to add a GitHub Advanced Security step to a **Security** or **Build** stage and configure it as described below.

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

**Scan Mode**

* **Orchestration**: Executes the scan, normalizes, and deduplicates results. Supported for **CodeQL** and **Dependabot**.

  <div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><ul><li>To comply with <a href="https://docs.github.com/en/get-started/learning-about-github/about-github-advanced-security#about-github-advanced-security-products">GitHub’s licensing requirements</a>, orchestration scans are uploaded to GitHub and then imported into STO.</li><li><strong>Orchestration</strong> mode currently supports <em>Python (pip)</em> and <em>JavaScript/TypeScript (npm or yarn)</em>. <strong>Extraction</strong> mode supports all languages available in GHAS.</li></ul></div>
* **Extraction**: Pulls existing results from GitHub APIs (**CodeQL**, **Dependabot**, **Secret Scanning**).
* **Ingestion**: Ingests SARIF files from previously run GHAS scans.

**Scan Configuration**

The predefined configuration to use for the scan. All scan steps have at least one configuration.

The GitHub Advanced Security step supports the following configurations:

* [**CodeQL**](#codeql)
* [**Dependabot**](#dependabot)
* [**Secret Scanning**](#secret-scanning)

#### CodeQL <a href="#codeql" id="codeql"></a>

You can use **CodeQL** to perform Static Application Security Testing (SAST). For details about CodeQL itself, see the [CodeQL documentation](https://docs.github.com/en/code-security/code-scanning/introduction-to-code-scanning/about-code-scanning-with-codeql).

Here are a few important points to note when using CodeQL with **Orchestration mode**:

* The repository must be configured with **Advanced setup** for **CodeQL analysis**. To do this, go to your repository settings, click on **Advanced Security**, then go to **Code scanning** section and select **Advanced setup** for **CodeQL analysis**. If you're using default setup, you must switch to Advanced setup before running scans with Orchestration scan mode.

For **Extraction mode**, CodeQL works with both **Default** and **Advanced setup**.

{% hint style="info" %}
The **CodeQL** scan configuration using the [**Orchestration**](#scan-mode) scan mode requires a minimum of `2Gi` of RAM. You can set this in the [**Additional Configuration**](#additional-configuration) section of your step.
{% endhint %}

***

#### Dependabot <a href="#dependabot" id="dependabot"></a>

You can use **Dependabot** for dependency (SCA) scans. For more information, see the [Dependabot documentation](https://docs.github.com/en/code-security/dependabot/dependabot-alerts/about-dependabot-alerts).

Prerequisites for Dependabot scans:

* **Dependabot alerts** must be enabled. To check this, go to your repository settings, select **Advanced Security**, then click on **Enable** for **Dependabot alerts**.
* **Dependabot** with **Orchestration mode** requires a **Docker-in-Docker (DinD)** background step. When you configure this step, set the **Entrypoint** to `dockerd-entrypoint.sh` instead of `dockerd`. For setup instructions, go to [Configure Docker-in-Docker (DinD) for your pipeline](/security-testing-orchestration/use-sto/sto-scanner-configuration/security-step-settings-reference.md#configuring-docker-in-docker-dind-for-your-pipeline).

***

#### Secret Scanning <a href="#secret-scanning" id="secret-scanning"></a>

You can use **Secret Scanning** to detect exposed secrets such as API keys, tokens, or other sensitive values in your repositories. For more details about this feature, see the [Secret Scanning documentation](https://docs.github.com/en/code-security/securing-your-organization/understanding-your-organizations-exposure-to-leaked-secrets/choosing-github-secret-protection).

Prerequisites for Secret Scanning:

* **Secret protection** must be enabled. To enable this, go to your repository settings, click on **Advanced Security**, then click on **Enable** for **Secret Protection**.

#### Target <a href="#target" id="target"></a>

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

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

#### Ingestion File <a href="#ingestion-file" id="ingestion-file"></a>

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

#### Authentication <a href="#authentication" id="authentication"></a>

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

Use a GitHub fine-grained **Personal Access Token (PAT)** with the following repository permissions:

| **Scan Mode**                                        | **Permission**         | **Level**    |
| ---------------------------------------------------- | ---------------------- | ------------ |
| **Orchestration** (CodeQL, Dependabot)               | Code scanning alerts   | Read & Write |
|                                                      | Dependabot alerts      | Read & Write |
|                                                      | Secret scanning alerts | Read & Write |
| **Extraction** (CodeQL, Dependabot, Secret Scanning) | Code scanning alerts   | Read-only    |
|                                                      | Dependabot alerts      | Read-only    |
|                                                      | Secret scanning alerts | Read-only    |

Make sure **Repository access** is set to *All repositories* or *Only selected repositories*.

#### Log Level <a href="#log-level" id="log-level"></a>

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 <a href="#fail-on-severity" id="fail-on-severity"></a>

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.