> 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/docker-content-trust-dct-scanner-reference.md).
# Docker Content Trust (DCT) step configuration
You can run container image scans and ingest results from [Docker Content Trust (DCT)](https://docs.docker.com/engine/security/trust/).
### Workflow descriptions
Orchestration/extraction workflows
This workflow applies to scanner integrations that support [`orchestratedScan`](/security-testing-orchestration/new-to-sto/key-concepts/run-an-orchestrated-scan-in-sto.md) or [`dataLoad`](/security-testing-orchestration/new-to-sto/key-concepts/extraction-scans.md) scan modes.
1. Add a **Build** or **Security** stage to your pipeline.
2. If you're scanning a code repository, set up your [codebase](/continuous-integration/use-harness-ci/use-harness-ci/codebase-configuration/create-and-configure-a-codebase.md).
3. Add a [Custom Scan](/security-testing-orchestration/use-sto/sto-custom-scanning-and-ingestion/custom-scan-reference.md) step.
4. Review the [Important notes for Custom Scan steps](/security-testing-orchestration/use-sto/sto-custom-scanning-and-ingestion/custom-scan-reference.md#important-notes-for-custom-scan-steps) for additional requirements and relevant information.
If you're setting up a scan on a Kubernetes or Docker build infrastructure, you need to add a [Docker-in-Docker background step](/security-testing-orchestration/use-sto/sto-scanner-configuration/security-step-settings-reference.md#configuring-docker-in-docker-dind-for-your-pipeline) to the stage.
5. Add the relevant `key:value` pairs to **Settings**.
Ingestion workflows
This workflow applies to scanner integrations that support Ingestion mode.
1. Add a Build or Security stage to your pipeline.
2. Add a Run step and set it up to save your scan results to a shared folder.
For more information, go to [Run an ingestion scan in an STO Pipeline](/security-testing-orchestration/new-to-sto/key-concepts/ingest-scan-results-into-an-sto-pipeline.md).
3. Add a [Custom Scan](/security-testing-orchestration/use-sto/sto-custom-scanning-and-ingestion/custom-scan-reference.md) step.
4. Review the [Important notes for Custom Scan steps](/security-testing-orchestration/use-sto/sto-custom-scanning-and-ingestion/custom-scan-reference.md#important-notes-for-custom-scan-steps) for additional requirements and relevant information.
5. Add the relevant `key:value` pairs to **Settings**.
### Custom Scan step settings for Docker Content Trust
#### Scanner settings
These settings are required for most scanners. For more information, go to the reference for the scanner integration you're setting up.
* [Product name](#product-name)
* [Scan type](#scan-type)
* [Policy type](#policy-type)
* [Product config name](#product-config-name)
**Product name**
The scanner name. This is required for all Custom Scan steps.
**Key**
```
product_name
```
**Value**
```
docker-content-trust
```
**Scan type**
The target type to scan.
**Key**
```
scan_type
```
**Value**
```
containerImage
```
**Policy type**
The [scan mode](/security-testing-orchestration/new-to-sto/key-concepts/sto-workflows-overview.md) to use.
**Key**
```
policy_type
```
**Value**
Must be one of the following.
```
orchestratedScan
```
```
ingestionOnly
```
**Product config name**
Required for most scanner integrations.
**Key**
```
product_config_name
```
**Value**
```
default
```
#### Target and variant
Every Custom Scan step needs a [target and baseline](/security-testing-orchestration/new-to-sto/key-concepts/targets-and-baselines.md).
* [Target name](#target-name)
* [Target variant](#target-variant)
**Target name**
**Key**
```yaml
target_name
```
**Value**
A user-defined label for the code repository, container, application, or configuration to scan. Specify a unique, descriptive name. This makes it much easier to navigate your scan results in the STO UI.
**Target variant**
**Key**
```yaml
target_variant
```
**Value**
A [user-defined label](/security-testing-orchestration/new-to-sto/key-concepts/targets-and-baselines.md) for the branch, tag, or other target variant to scan.
#### Container image
These settings apply to Custom Scan steps when both of these conditions are true:
1. The `policy_type` is `orchestratedScan` or `dataLoad`.
2. The `scan_type` is `containerImage`.
* [Container type](#container-type)
* [Container domain](#container-domain)
* [Container project](#container-project)
* [Container tag](#container-tag)
* [Container access Id](#container-access-id)
* [Container access token](#container-access-token)
* [AWS region](#aws-region)
**Container type**
**Key**
```
container_type
```
**Value**
The registry type where the image is stored. Specify one of the following:
Scan a local image built and stored within the context of the current stage (via `/var/run/docker.sock` registered as a stage level volume mount).
```
local_image
```
A registry that uses the Docker Registry v2 API such as [Docker Hub](https://docs.docker.com/registry/spec/api/), [Google Container Registry](https://cloud.google.com/container-registry), or [Google Artifact Registry](https://cloud.google.com/artifact-registry).
```
docker_v2
```
[JFrog Docker Registry](https://jfrog.com/container-registry/).
```
jfrog_artifactory
```
[Amazon Container Registry](https://aws.amazon.com/ecr/).
```
aws_ecr
```
**Container domain**
**Key**
```
container_domain
```
**Value**
The URL of the registry that contains the image to scan. Examples include:
```
docker.io
```
```
app.harness.io/registry
```
```
us-east1-docker.pkg.dev
```
**Container project**
**Key**
```
container_project
```
**Value**
The image name. For non-local images, you also need to specify the image repository. Example: `jsmith/myalphaservice`
**Container tag**
**Key**
```
container_tag
```
**Value**
The image tag. Examples: `latest`, `1.2.3`
**Container access Id**
**Key**
```
container_access_id
```
**Value**
Your access Id to the image registry.
**Container access token**
**Key**
```
container_access_token
```
**Value**
The password or access token used to log in to the image registry. In most cases this is 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("container-access-id")>`. For more information, go to [Add and Reference Text Secrets](/harness-ai/use-harness-platform/secrets/add-use-text-secrets.md).
**AWS region**
**Key**
```
container_region
```
**Value**
The region where the image to scan is located, as defined by the cloud provider such as AWS.
#### Ingestion file
This setting applies to Custom Scan steps when the `policy_type` is [`ingestionOnly`](/security-testing-orchestration/new-to-sto/key-concepts/ingest-scan-results-into-an-sto-pipeline.md).
**Key**
```
ingestion_file
```
**Value**
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 scan results 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
```
#### Fail on Severity
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. `NONE` means do not fail on severity.
For more information, go to:
* [STO workflows for blocking builds and PRs](/security-testing-orchestration/troubleshooting-and-resources/sto-use-cases/stop-builds-based-on-scan-results/stop-pipelines-overview.md).
* [Exemptions to override Fail on Severity thresholds for specific issues in STO](/security-testing-orchestration/use-sto/sto-exempt-issues/exemption-workflows.md)
**Key**
```
fail_on_severity
```
**Value**
```
CRITICAL
```
```
MEDIUM
```
```
LOW
```
```
INFO
```
```
NONE
```