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: "<pipeline_identifier>"
  org_id: "<organization>"
  project_id: "<project>"

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: <name>

Stage 1: <stage_name> (type: <stage_type>)
  - Step 1: <step_name> (type: <step_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:

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 <+secrets.getValue("project.<secret_identifier>")>
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 <+secrets.getValue("project.traceable_api_token")>."

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:

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:

Extraction mode:

Ingestion mode:

For Burp Suite Enterprise:

For ZAP, Nikto, Nmap (instance scanners):

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: <traceable_platform_url>
        access_token: <+secrets.getValue("project.traceable_api_token")>
      tool:
        suite_id: <traceable_scan_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: <traceable_platform_url>
        access_token: <+secrets.getValue("project.traceable_api_token")>
      tool:
        suite_id: <traceable_scan_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: <traceable_platform_url>
        access_token: <+secrets.getValue("project.traceable_api_token")>
      tool:
        suite_id: <traceable_scan_id>
        runner_id: <traceable_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: <target_name>
        variant: <target_variant>
      ingestion:
        file: <ingestion_file_path>
      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: <burp_enterprise_url>
        access_token: <+secrets.getValue("project.burp_api_key")>
      instance:
        domain: <target_app_url>
        protocol: https
        port: <port>
        path: <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: <target_app_url>
        protocol: https
        port: <port>
        path: <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: <target_app_url>
        protocol: https
        port: <port>
        path: <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: <target_app_url>
        protocol: https
        port: <port>
        path: <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: <delegate_connector>
    namespace: <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: <traceable_platform_url>
                  access_token: <+secrets.getValue("project.traceable_api_token")>
                tool:
                  suite_id: <traceable_scan_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: <delegate_connector>
          namespace: <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: <traceable_platform_url>
                  access_token: <+secrets.getValue("project.traceable_api_token")>
                tool:
                  suite_id: <traceable_scan_id>
                advanced:
                  log:
                    level: info

Step 9: Update Pipeline via MCP

Call MCP tool: harness_update
Parameters:
  resource_type: "pipeline"
  resource_id: "<pipeline_identifier>"
  org_id: "<organization>"
  project_id: "<project>"
  body: { yamlPipeline: "<updated pipeline YAML string>" }

Step 10: Provide Summary and Next Steps

## DAST Scanner Configured

**Pipeline:** <pipeline_name>
**Scanner:** <scanner_name> (<scanner_type>)
**Stage:** <stage_name> (SecurityTests)
**Target:** <target_instance_url_or_scan_name>
**Mode:** <orchestration | extraction | ingestion>

**Pipeline URL:** https://app.harness.io/ng/account/<account_id>/module/sto/orgs/<org_id>/projects/<project_id>/pipelines/<pipeline_id>/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_on_severity` (CRITICAL, HIGH, MEDIUM, LOW) in the step's Advanced tab
4. Configure exemptions for false positives via `/security-report` skill
5. Enforce pipeline gates on severity via `/create-policy` skill

Examples

Add API DAST scan with Traceable (orchestration)

/configure-dast-scan
Add an API DAST scan to my backend-deploy pipeline. My Traceable domain is https://api.traceable.ai/ and the scan ID is b35b11b4-3e87-47df-8c2e-a5ceb5ea764c.

Add Traceable in extraction mode

/configure-dast-scan
I want to pull the latest DAST results from my Traceable scan into STO. Use extraction mode.
The scan ID is abc123-def456 and my Traceable token secret is traceable_token.

Add Burp Suite Enterprise scan

/configure-dast-scan
Add Burp Suite Enterprise scanning to my pipeline targeting https://staging.myapp.io:8443/api.
Use the "Crawl and audit deep" configuration for thorough coverage.

Add ZAP scan after deployment

/configure-dast-scan
Add a ZAP DAST scan after the deployment stage in my frontend-deploy pipeline.
Target the deployed app at https://staging.example.com

Add Nikto web server scan

/configure-dast-scan
Add Nikto scanning to check my web server at https://myapp.io:443 for common vulnerabilities.
Add it to the existing SecurityTests stage.

Add Nmap network scan

/configure-dast-scan
Add an Nmap vulnerability scan against my service at 10.0.1.50 port 8080.
Use the Vuln scan configuration.

Performance Notes

• Only works with existing pipelines — do not offer to create a new standalone pipeline
• Always ask the user which scanner they want — present the full list; default to API DAST (Traceable) if not specified
• DAST scans target running application instances — they do NOT need source code access, so cloneCodebase: false is always set on SecurityTests stages
• Place DAST scans after deployment stages when possible — the target application must be running and accessible
• For API DAST (Traceable), the scan must already exist in the Traceable platform — orchestration mode initiates a run of an existing scan, it cannot create new scans
• For Traceable orchestration mode, ensure runners are created and active in Traceable — the step cannot create runners
• For commercial scanners (API DAST, Burp Suite), always ask for scanner product credentials (auth.domain / auth.access_token) before generating YAML
• If required secrets don't exist yet, prompt the user to create them via /create-secret before proceeding
• For ZAP, Nikto, and Nmap, no product auth is needed — only the target instance details
• Default to mode: orchestration and config: default unless the user specifies otherwise
• Default to target.detection: auto — this sets the target name from the scan and variant from the timestamp
• Default to Harness Cloud infrastructure for new SecurityTests stages unless the user specifies Kubernetes Direct
• Nmap is primarily a network scanner — recommend it for port/service discovery and network-level vulnerabilities, not application-layer DAST
• Burp Suite provides the most comprehensive web application DAST with crawl + audit capabilities

Troubleshooting

Pipeline Not Found

• Verify org_id and project_id are correct
• Confirm the pipeline exists with harness_list (resource_type: "pipeline")

API DAST (Traceable) Scan Fails to Start

• Verify the Scan ID (suite_id) is correct — find it in the Traceable scan URL
• Ensure the Traceable access token is valid and has permissions to trigger scans
• For orchestration mode: confirm runners are active in Traceable — the step cannot create runners
• Verify the Traceable domain URL is correct (e.g., https://api.traceable.ai/ vs https://api-staging.traceable.ai/)

Burp Suite Authentication Failure

• Verify auth.domain points to your Burp Enterprise server URL
• Confirm auth.access_token references a valid Harness secret containing the Burp API key
• Ensure the Burp Enterprise server is reachable from the pipeline infrastructure

Target Instance Unreachable

• Verify the instance domain, protocol, and port are correct
• Ensure the target application is running and accessible from the pipeline infrastructure (delegate or Harness Cloud)
• For internal/private applications, ensure the delegate has network connectivity to the target
• Check firewall rules and security groups allow traffic from the scanner to the target

Scanner Authentication Failure (commercial scanners)

• Verify auth.access_token (and auth.domain) reference valid Harness secrets
• Confirm the secret identifiers match exactly — check with harness_get(resource_type="secret")
• If secrets don't exist, create them first via /create-secret then re-run the skill

No Results in Security Tests Tab

• Confirm STO module is enabled for the account
• Check the execution logs for scanner errors
• For API DAST (Traceable): verify the scan completed successfully in the Traceable platform
• For Burp Suite: ensure the crawl completed — very large applications may time out with restrictive crawl limits

Pipeline Update Validation Errors

• Verify YAML indentation (2 spaces throughout)
• Ensure step identifier matches pattern ^[a-zA-Z_][0-9a-zA-Z_]{0,127}$
• Confirm the SecurityTests stage has a valid infrastructure block (Harness Cloud or KubernetesDirect with a working delegate)
• Ensure cloneCodebase: false is set on SecurityTests stages (DAST does not need source code)