Configure Dast Scan

Configure DAST Scan

Add a Dynamic Application Security Testing (DAST) step to an existing Harness pipeline using Harness STO scanners. DAST scanners test running application instances for security vulnerabilities at runtime.

Instructions

Step 1: Establish Scope and Pipeline Context

Ask for org, project, and pipeline identifier if not already known. This skill only works with existing pipelines.

Call MCP tool: harness_get
Parameters:
  resource_type: "pipeline"
  resource_id: ""
  org_id: ""
  project_id: ""

Step 2: Analyze Pipeline Structure

Parse the pipeline YAML to identify:

• All stages and their types (CI, SecurityTests, Deployment, Approval)
• Whether a SecurityTests stage already exists
• Existing steps in each stage

Present the structure to the user:

Pipeline: 

Stage 1:  (type: )
  - Step 1:  (type: )
  ...

Ask the user where they want the DAST scanner step added:

Present the available insertion points:

• Any existing SecurityTests stage (scanner step is added into that stage's execution.steps)
• Any existing CI stage (scanner step is added directly into that stage's execution.steps)
• A new SecurityTests stage (appended to the pipeline)

Recommendation guidance:

• DAST scans run against a live application instance — they are best placed after deployment so the target is running
• If the pipeline has a Deployment stage, recommend adding a SecurityTests stage after the deployment stage
• If no deployment stage exists, the user must provide the target URL of an already-running instance
• Adding to an existing SecurityTests stage is simplest if one already exists

If the user doesn't specify, default to adding a new SecurityTests stage at the end of the pipeline (or after the Deployment stage if one exists).

Step 3: Recommend Scanner Type

Present the available DAST scanners supported in Harness STO:

Available DAST Scanners:

• API DAST (Traceable) (default — Harness native API security scanner, formerly called Traceable)
• Burp Suite Enterprise (commercial, comprehensive web app DAST with crawl + audit)
• ZAP (OWASP Zed Attack Proxy, open-source web app scanner)
• Nikto (open-source, web server scanner)
• Nmap (open-source, network/port scanner with vulnerability scripts)

Default recommendation: Use API DAST (Traceable) — the Harness native DAST scanner for API security testing. It connects with your Traceable account to initiate scans against existing scan configurations, and results integrate directly with Harness STO.

Ask the user which scanner they prefer. If they don't specify, use API DAST (Traceable) as the default.

Step type mapping and scanner auth requirements:

| Scanner | type field | Product auth needed? | Auth fields | |---------|-------------|----------------------|-------------| | API DAST (Traceable) | Traceable | Yes | domain (Traceable platform URL), access_token (API token) | | Burp Suite Enterprise | BurpEnterprise | Yes | domain (Burp Enterprise URL), access_token (API key) | | ZAP | Zap | No | — | | Nikto | Nikto | No | — | | Nmap | Nmap | No | — |

If the user picks a scanner that requires auth (API DAST, Burp Suite):

1. Inform the user that scanner product credentials are required
2. Ask for the required secret references from the table above — these must already exist as Harness secrets
3. Format them as ")>
4. These go into the auth block of the step spec

Example prompt to user: > "API DAST (Traceable) requires a platform domain and access token. Please provide: > 1. Your Traceable platform URL (e.g., https://api.traceable.ai/) > 2. The Harness secret identifier for your Traceable API token (e.g., traceable_api_token). I'll reference it as ``."

If the secret doesn't exist yet, suggest creating it first via /create-secret before proceeding.

Step 4: Select Scan Mode (API DAST / Traceable only)

This step applies only to API DAST (Traceable). For other scanners (Burp Suite, ZAP, Nikto, Nmap), default to orchestration and skip to Step 5.

Present the three available scan modes and ask the user which one they want:

Available Scan Modes:

• Orchestration (default) — Triggers a new scan run within an existing Traceable Scan. Results are automatically saved in STO. Requires an active runner in Traceable.
• Extraction — Retrieves the latest scan results from an existing Traceable Scan and imports them into STO. No new scan is triggered — useful for pulling results from scans run on a schedule or externally.
• Ingestion — Reads scan results from a local JSON file and imports them into STO. The user must fetch results separately (e.g., via a Run step with Traceable API call). No Traceable credentials needed in the step itself.

If the user doesn't specify, default to Orchestration.

Fields required per mode:

| Field | Orchestration | Extraction | Ingestion | |-------|:---:|:---:|:---:| | Domain (Traceable URL) | Yes | Yes | No | | Access Token | Yes | Yes | No | | Scan Name (Suite ID) | Yes | Yes | No | | Runner Selection | Optional | No | No | | Ingestion File path | No | No | Yes | | Target Name (manual) | No | No | Yes | | Target Variant (manual) | No | No | Yes |

For Ingestion mode, inform the user they need a preceding Run step to fetch results from Traceable's API and save them as a JSON file. Example command for the Run step:

curl -H "Authorization: Bearer $API_TOKEN" \
  "https://api.traceable.ai/graphql/scans/$SCAN_ID/vulnerabilities" \
  -o /harness/vulnerabilities.json

The ingestion file path (e.g., /harness/vulnerabilities.json) must be configured as a shared path in the stage.

Step 5: Collect Target Instance Details

DAST scans require a running application target. Collect different fields based on the scanner:

---

For API DAST (Traceable):

Traceable uses its own scan configurations managed in the Traceable platform. Collect based on the scan mode chosen in Step 4:

Orchestration mode:

| Field | Required | Description | |-------|----------|-------------| | Traceable Domain | Yes | Platform URL, e.g., https://api.traceable.ai/ or https://api-staging.traceable.ai/ | | Access Token | Yes | Traceable API token (Harness secret reference) | | Scan Name (Suite ID) | Yes | The Traceable Scan ID from the scan URL (e.g., b35b11b4-3e87-47df-8c2e-a5ceb5ea764c) | | Runner Selection | No | auto (default) or manual Runner ID — runners must be active in Traceable |

Extraction mode:

| Field | Required | Description | |-------|----------|-------------| | Traceable Domain | Yes | Platform URL, e.g., https://api.traceable.ai/ | | Access Token | Yes | Traceable API token (Harness secret reference) | | Scan Name (Suite ID) | Yes | The Traceable Scan ID to pull latest results from |

Ingestion mode:

| Field | Required | Description | |-------|----------|-------------| | Ingestion File | Yes | Path to the JSON results file, e.g., /harness/vulnerabilities.json | | Target Name | Yes | Manual target identifier (e.g., my-api-service) | | Target Variant | Yes | Manual variant label (e.g., 1.0.0 or staging) |

---

For Burp Suite Enterprise:

| Field | Required | Description | |-------|----------|-------------| | Burp Domain | Yes | Burp Enterprise server URL | | Access Token | Yes | Burp API key (Harness secret reference) | | Instance Domain | Yes | Target application URL, e.g., https://myapp.io | | Instance Protocol | No | https (default) or http | | Instance Port | No | TCP port (e.g., 443, 8080) | | Instance Path | No | Path to append (e.g., /api/v1) | | Scan Configuration | No | Default is Crawl and audit lightweight. See Step 5 for options |

---

For ZAP, Nikto, Nmap (instance scanners):

| Field | Required | Description | |-------|----------|-------------| | Instance Domain | Yes | Target application domain, e.g., https://myapp.io | | Instance Protocol | No | https (default) or http | | Instance Port | No | TCP port (e.g., 443, 8080, 3000) | | Instance Path | No | Path to append (e.g., /portal/us) |

---

Step 6: Generate the Scanner Step YAML

Use the step type from the scanner mapping in Step 3.

For API DAST / Traceable (default — Orchestration mode):

- step:
    type: Traceable
    name: API_DAST_Scan
    identifier: API_DAST_Scan
    spec:
      mode: orchestration
      config: default
      target:
        type: instance
        detection: auto
      auth:
        domain: 
        access_token: 
      tool:
        suite_id: 
      advanced:
        log:
          level: info

For API DAST / Traceable (Extraction mode):

- step:
    type: Traceable
    name: API_DAST_Scan
    identifier: API_DAST_Scan
    spec:
      mode: extraction
      config: default
      target:
        type: instance
        detection: auto
      auth:
        domain: 
        access_token: 
      tool:
        suite_id: 
      advanced:
        log:
          level: info

For API DAST / Traceable (Orchestration with manual runner):

- step:
    type: Traceable
    name: API_DAST_Scan
    identifier: API_DAST_Scan
    spec:
      mode: orchestration
      config: default
      target:
        type: instance
        detection: auto
      auth:
        domain: 
        access_token: 
      tool:
        suite_id: 
        runner_id: 
      advanced:
        log:
          level: info

For API DAST / Traceable (Ingestion mode):

- step:
    type: Traceable
    name: API_DAST_Scan
    identifier: API_DAST_Scan
    spec:
      mode: ingestion
      config: default
      target:
        type: instance
        name: 
        variant: 
      ingestion:
        file: 
      advanced:
        log:
          level: info

For Burp Suite Enterprise (Orchestration mode):

- step:
    type: BurpEnterprise
    name: Burp_Suite_Scan
    identifier: Burp_Suite_Scan
    spec:
      mode: orchestration
      config: default
      target:
        type: instance
        detection: auto
      auth:
        domain: 
        access_token: 
      instance:
        domain: 
        protocol: https
        port: 
        path: 
      advanced:
        log:
          level: info

Burp Suite scan configuration options (for config field):

• default (same as Crawl and Audit - Lightweight)
• Never stop Crawl due to application errors
• Never stop audit due to application errors
• Minimize false positives
• Minimize false negatives
• Crawl strategy most complete
• Crawl strategy more complete
• Crawl strategy fastest
• Crawl strategy faster
• Crawl limit 60 minutes
• Crawl limit 30 minutes
• Crawl limit 10 minutes
• Crawl and audit lightweight
• Crawl and audit fast
• Crawl and audit deep
• Crawl and audit balanced
• Audit coverage thorough
• Audit coverage maximum
• Audit checks medium active
• Audit checks light active
• Audit checks critical issues only
• Audit checks all except time based detection methods
• Audit checks all except java script analysis

For ZAP (open-source):

- step:
    type: Zap
    name: ZAP_DAST_Scan
    identifier: ZAP_DAST_Scan
    spec:
      mode: orchestration
      config: default
      target:
        type: instance
        detection: auto
      instance:
        domain: 
        protocol: https
        port: 
        path: 
      advanced:
        log:
          level: info

For Nikto (open-source):

- step:
    type: Nikto
    name: Nikto_DAST_Scan
    identifier: Nikto_DAST_Scan
    spec:
      mode: orchestration
      config: default
      target:
        type: instance
        detection: auto
      instance:
        domain: 
        protocol: https
        port: 
        path: 
      advanced:
        log:
          level: info

For Nmap (open-source network scanner):

- step:
    type: Nmap
    name: Nmap_Scan
    identifier: Nmap_Scan
    spec:
      mode: orchestration
      config: default
      target:
        type: instance
        detection: auto
      instance:
        domain: 
        protocol: https
        port: 
        path: 
      advanced:
        log:
          level: info

Nmap scan configuration options:

• default (common port scan with scripts)
• No Default CLI Flags (blank slate for custom flags)
• Firewall Bypass
• Unusual Port
• SMB Security Mode
• Vuln
• Exploit

Step 7: Collect Infrastructure Details (if needed)

Only required when adding a new SecurityTests stage. If inserting into an existing stage, skip this step.

Ask the user for their infrastructure type:

Option A — Harness Cloud (recommended for simplicity):

platform:
  os: Linux
  arch: Amd64
runtime:
  type: Cloud
  spec: {}

Option B — Kubernetes Direct:

Ask for:

• Delegate connector (e.g., account.mydelegate)
• Namespace (e.g., harness-delegate-ng)

infrastructure:
  type: KubernetesDirect
  spec:
    connectorRef: 
    namespace: 
    automountServiceAccountToken: true
    nodeSelector: {}
    os: Linux

If the user doesn't specify, default to Harness Cloud infrastructure.

Step 8: Build the Updated Pipeline YAML

Scenario A — Adding to an existing SecurityTests or CI stage:

Insert the step into spec.execution.steps of the chosen stage. The stage already has its own infrastructure. Just append the step.

Scenario B — Creating a new SecurityTests stage (Harness Cloud):

- stage:
    name: DAST Scan
    identifier: DAST_Scan_Stage
    type: SecurityTests
    spec:
      cloneCodebase: false
      platform:
        os: Linux
        arch: Amd64
      runtime:
        type: Cloud
        spec: {}
      execution:
        steps:
          - step:
              type: Traceable
              name: API_DAST_Scan
              identifier: API_DAST_Scan
              spec:
                mode: orchestration
                config: default
                target:
                  type: instance
                  detection: auto
                auth:
                  domain: 
                  access_token: 
                tool:
                  suite_id: 
                advanced:
                  log:
                    level: info

Scenario C — Creating a new SecurityTests stage (Kubernetes Direct):

- stage:
    name: DAST Scan
    identifier: DAST_Scan_Stage
    type: SecurityTests
    spec:
      cloneCodebase: false
      infrastructure:
        type: KubernetesDirect
        spec:
          connectorRef: 
          namespace: 
          automountServiceAccountToken: true
          nodeSelector: {}
          os: Linux
      execution:
        steps:
          - step:
              type: Traceable
              name: API_DAST_Scan
              identifier: API_DAST_Scan
              spec:
                mode: orchestration
                config: default
                target:
                  type: instance
                  detection: auto
                auth:
                  domain: 
                  access_token: 
                tool:
                  suite_id: 
                advanced:
                  log:
                    level: info

Step 9: Update Pipeline via MCP

Call MCP tool: harness_update
Parameters:
  resource_type: "pipeline"
  resource_id: ""
  org_id: ""
  project_id: ""
  body: { yamlPipeline: "" }

Step 10: Provide Summary and Next Steps

## DAST Scanner Configured

**Pipeline:** 
**Scanner:**  ()
**Stage:**  (SecurityTests)
**Target:** 
**Mode:** 

**Pipeline URL:** https://app.harness.io/ng/account//module/sto/orgs//projects//pipelines//pipeline-studio/

### Next Steps
1. Run the pipeline to verify the DAST scan step executes successfully
2. View scan results in the Security Tests tab of the execution
3. Set failure thresholds using `fail_o

…

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [harness](https://github.com/harness)
- **Source:** [harness/harness-skills](https://github.com/harness/harness-skills)
- **License:** Apache-2.0
- **Homepage:** https://developer.harness.io/docs/platform/harness-ai/harness-skills/

Install and usage instructions live in the source repository linked above.