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
MacOSarm64RoadmapRoadmapRoadmap❌ 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

Docker-in-Docker requirements for STO​

The following use cases require a Docker-in-Docker background step in your pipeline:

  • Container image scans on Kubernetes and Docker build infrastructures
  • Custom Scan steps on Kubernetes and Docker build infrastructures
    • Required for all target types and Orchestration/DataLoad modes

The following use cases do not require a Docker-in-Docker background step:

  • Harness Cloud AMD64 build infrastructures
  • SAST/DAST/configuration scans that use a scanner-specific step and not a Custom Scan step.
  • Ingestion scans where the data file has already been generated
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 Additional Configuration, select the Privileged checkbox.

Configure the background step

Root access requirements for STO​

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

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