Data Theorem scanner reference for STO

You can run repository scans and ingest results from Data Theorem.

Important notes for running Data Theorem scans in STO

Docker-in-Docker requirements

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

• Container image scans on Kubernetes and Docker build infrastructures
  • Required for Orchestration and Dataload scan modes
• Security steps (not step palettes) on Kubernetes and Docker build infrastructures
  • Required for all target types and Orchestration/DataLoad modes

The following use cases do not require Docker-in-Docker:

• Harness Cloud AMD64 build infrastructures
• SAST/DAST/configuration scans that use scanner templates (not Security steps)
• 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 Optional Configuration, select the Privileged checkbox.

Visual setup

YAML setup

Add a Background step to your pipeline and set it up as follows:

- step:
   type: Background
   name: background-dind-service
   identifier: Background_1
   spec:
      connectorRef: CONTAINER_IMAGE_REGISTRY_CONNECTOR
      image: docker:dind
      shell: Sh
      entrypoint:
         - dockerd
      privileged: true

Root access requirements

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

• You need to run a Docker-in-Docker background service.

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

For more information

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

• What's supported in STO
• Security Testing Orchestration FAQs
• Optimize STO pipelines

Security step settings for Data Theorem scans in STO

Target and variant

The following settings are required for every Security step:

• target_name A user-defined label for the code repository, container, application, or configuration to scan.
• variant A user-defined label for the branch, tag, or other target variant to scan.

note

Make sure that you give unique, descriptive names for the target and variant. This makes navigating your scan results in the STO UI much easier.

You can see the target name, type, and variant in the Test Targets UI:

For more information, go to Targets, baselines, and variants in STO.

Data Theorem scan settings

• product_name = data-theorem
• product_config_name = default
• scan_type = repository
• policy_type = dataLoad or ingestionOnly
• When policy_type = dataLoad:
  • product_app_id
  • product_access_token
• fail_on_severity - See Fail on Severity.

Ingestion file

If the policy_type is ingestionOnly:

• ingestion_file = The path to your scan results when running an Ingestion scan, for example /shared/scan_results/myscan.latest.sarif.

• The data file must be in a supported format 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 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:

      - stage:
        spec:
          sharedPaths:
            - /shared/scan_results

Fail on Severity

Every Security step has a Fail on Severity setting. If the scan finds any vulnerability with the specified severity level 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