Skip to main content

STO external scanner support and requirements

This section describes how to set up each of the external scanners supported by Harness STO.

For more information about STO support, go to What's supported in STO.

Scanner categories supported by STO​

The following list shows the scan types that STO supports:

  • SAST (Static Application Security Testing) scans a code repository and identifies known vulnerabilities in open-source and proprietary code.
  • SCA (Software Composition Analysis) scans a code repository and identifies known vulnerabilities in open-source libraries and packages used by the code.
  • Secret Scanning scans a code repository and identifies all secrets such as access keys and passwords.
  • DAST (Dynamic Application Security Testing) scans a running application for vulnerabilties by simulating a malicious external actor exploiting known vulnerabilties.
  • Container Scanning identifies vulnerabilities in container images.
  • IaC identifies vulnerabilities in Infrastructure as Code scripts that automatically provision and configure infrastructures.

Scanners supported by STO​

The following sections describe the scanners supported by Harness STO, based on the target type:

Code repo scanners​

A code scanner can detect one or more of the following issue types in your source code. For information about the specific vulnerabilities detected by each scanner, go to the scanner provider's documentation.

  • SAST (Static Application Security Testing): Known vulnerabilities in open-source and proprietary code.
  • SCA (Software Composition Analysis): Known vulnerabilities in open-source libraries and packages used by the code.
  • Secrets: Hard-coded secrets such as access keys and passwords.
  • IaC: Known vulnerabilities in Infrastructure-as-Code files such as Terraform configurations.
  • Misconfigurations: Known vulnerabilities in software configurations.
Open SourceCommercial

Artifact scanners​

An artifact scanner can detect one or more of the following issue types in your container images and other artifacts. For information about the specific vulnerabilities detected by each scanner, go to the scanner provider's documentation.

  • SCA (Software Composition Analysis): Known vulnerabilities in open-source libraries and packages used by the code.
  • Container Scanning: Identify vulnerabilities in container images.
Open SourceCommercial

Instance scanners​

An instance scanner scans a running application for vulnerabilities by simulating a malicious external actor exploiting known vulnerabilities. This is also known as a DAST (Dynamic Application Security Testing) scan.

For information about the specific vulnerabilities detected by each scanner, go to the scanner provider's documentation.

Open SourceCommercial

Configuration scanners​

The following scanners detect misconfigurations in your cloud environment that can result in vulnerabilities. For information about the specific vulnerabilities detected by each scanner, go to the scanner provider's documentation.

Open SourceCommercial

Other scanners​

If you use a scanner that isn't listed above, you can still ingest your scan results into STO.

Operating systems and architectures supported by STO​

STO uses CI build infrastructures to orchestrate scans and ingest issues. The following table shows STO support for each infrastructure type.

Operating SystemArchitectureHarness CloudSelf-managed local runnerSelf-managed AWS/GCP/Azure VMsSelf-managed Kubernetes cluster
Linuxamd64✅ Supported✅ Supported✅ Supported✅ Supported
Linuxarm64✅ Ingestion mode only✅ Ingestion mode only✅ Ingestion mode only✅ Ingestion mode only
Windowsamd64✅ Ingestion mode only❌ Not supportedRoadmap❌ Not supported
MacOSarm64✅ Ingestion mode onlyRoadmapRoadmap❌ Not supported

Ingestion formats supported by STO​

Harness STO can automatically ingest, aggregate, normalize, and deduplicate data from the following scanners and formats.

info

Static Analysis Results Interchange Format (SARIF) is an open JSON format supported by many scan tools, especially tools available as GitHub Actions. Harness STO can ingest SARIF 2.1.0 data from any tool that supports this format.

Harness recommends that you publish and ingest using the scanner-specific JSON format when available, because it tends to include more useful information.

  • Anchore Enterprise — JSON
  • Aqua Security — JSON
  • Aqua Trivy — JSON (recommended), SARIF
  • AWS ECR — JSON
  • AWS Security Hub — JSON
  • Bandit — JSON (recommended), SARIF
  • Black Duck Hub — JSON
  • Brakeman — JSON
  • Burp — XML
  • Checkmarx — XML, SARIF
  • CodeQL — SARIF
  • Coverity — XML
  • Data Theorem — JSON
  • Docker Content Trust — JSON
  • Fortify — JSON
  • Fortify on Demand — JSON
  • Fossa — JSON
  • Gitleaks — JSON (recommended), SARIF
  • HQL AppScan — XML
  • Grype — JSON
  • Mend (formerly Whitesource) — JSON
  • Nessus — XML
  • Nexus — JSON
  • Nikto — XML
  • Nmap — XML
  • OpenVAS — JSON
  • OWASP Dependency Check — JSON
  • Prisma Cloud — JSON
  • Prowler — JSON
  • Qualys — XML
  • Qwiet — JSON
  • Reapsaw — JSON
  • Semgrep — SARIF
  • Snyk — JSON (recommended), SARIF
  • SonarQube — JSON
  • Sysdig — JSON
  • Tenable — JSON
  • Veracode — XML
  • JFrog Xray — JSON
  • Wiz - JSON (recommended), SARIF
  • Zed Attack Proxy (ZAP) — JSON
  • Checkov - JSON, SARIF

DinD and without-DinD flows in STO​

STO supports two primary container scanning workflows, Docker-in-Docker (DinD) and without-Docker-in-Docker. In most cases, Docker-in-Docker (DinD) is no longer required, but it remains an option for certain use cases or specific scanner types. You can understand both flows and choose the right one based on your use case and scanner compatibility

Docker-in-Docker(DinD) flow in STO​

You should use Docker-in-Docker if:

  • Your scanner requires Docker access to perform operations inside a container.
  • You're using a Custom Scan step or DataLoad/OrchestratedScan scan modes that depend on Docker functionality.
  • Your scanner does not support without-DinD scanning (see the table below).
info

STO will automatically attempt to use the Without-DinD flow if it does not detect a Docker socket (/var/run/docker.sock).

Configuring Docker-in-Docker (DinD) for your pipeline​

Set up a Docker-in-Docker background step

  1. Go to the stage where you want to run the scan.

  2. In Overview, add the shared path /var/run.

  3. In Execution, do the following:

    1. Click Add Step and then choose Background.
    2. Configure the Background step as follows:

      1. Dependency Name = dind

      2. Container Registry = The Docker connector to download the DinD image. If you don't have one defined, go to Docker connector settings reference.

      3. Image = docker:dind

      4. Under Entry Point, add the following: dockerd

        In most cases, using dockerd is a faster and more secure way to set up the background step. For more information, go to the TLS section in the Docker quick reference.

        If the DinD service doesn't start with dockerd, clear the Entry Point field and then run the pipeline again. This starts the service with the default entry point.

      5. Under Optional Configuration, select the Privileged checkbox.

Configure the background step

For Orchestrated and Extraction scans, you might want to increase the resource limits for your Docker-in-Docker background step. This can speed up your scan times, especially for large scans. For more information, go to Optimize STO pipelines.

If you want to force STO to use Docker-in-Docker (DinD), set the following variable in the Settings section of your step configuration (optional):

  • docker_mode: docker-in-docker

This setting is optional and only needed if you want force the STO to use a specific mode. By default, STO will automatically choose the appropriate mode based on your environment.

Without-Docker-in-Docker flow in STO​

You should use without-Docker-in-Docker if:

  • Your environment doesn’t have or doesn’t need Docker access.
  • You’re using scanners that support Without-DinD scanning (see the table below).
  • You want a simplified configuration with less security overhead (since privileged mode is not required in the Without-DinD flow).

For configuration, STO will automatically attempt to use the Without-DinD flow if it does not detect a Docker socket(/var/run/docker.sock), you won’t need to configure anything.

If you want to force STO to use Without Docker-in-Docker flow, set the following variable in the Settings section of your step configuration (optional):

  • docker_mode: without-docker-in-docker

This setting is optional and only needed if you want force the STO to use a specific mode. By default, STO will automatically choose the appropriate mode based on your environment.

Scanners that support Without-DinD flow​

Without-DinD supported scanners
ScannerSupports Without-DinD Scanning
Anchor✅
Aqua Security✅
Aqua Trivy✅
AWS ECR Scan✅
Black Duck❌ Does not support
Custom Scan❌ Does not support
Grype✅
Prisma Cloud✅
Snyk✅
Sysdig✅
Wiz✅

Root access requirements for STO​

You need to run the scan step with root access if either of the following apply:

  • You need to add trusted certificates to your scan images at runtime.
note

You can set up your STO scan images and pipelines to run scans as non-root and establish trust for your own proxies using custom certificates. For more information, go to Configure STO to Download Images from a Private Registry.

Security steps and scanner templates in STO​

The Step library includes a Custom Scan step for setting up scanners: open the step and configure the scan as a set of key/value pairs under Settings.

Some scanners also have their own steps with simplified UIs that simplify the setup process.

Step Library with scanner-specific steps and Custom Scan step

Step Library with scanner-specific steps and Custom Scan step

Custom Scan step configuration

Custom Scan step configuration

Scanner-specific step configuration

Scanner-specific step configuration