Ctrlk
Sign UpGet a DemoContact Us
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Burp Suite Enterprise Edition step configuration

Scan application instances with Burp.

You can configure the Burp Suite Enterprise Edition step in your pipeline to perform Dynamic Application Security Testing (DAST). The step supports multiple scan modes and customizable scan configurations to suit different testing needs.

Burp Suite Enterprise Edition step settings

The recommended workflow is to add a Burp Suite Enterprise Edition step to a Security or Build stage and then configure it as described below.

Scan

Scan Mode

Scan Configuration

The predefined configuration to use for the scan. All scan steps have at least one configuration.

The following configurations are available for Orchestration scans. These are built-in configurations provided by Burp Enterprise.

  • Default – This is the same as the Crawl and Audit - Lightweight built-in configuration.

  • 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

Target

Type

  • Instance Scan a running application.

Target and variant detection

When Auto is enabled for application instances, the step detects these values as follows:

  • The target is based on the Instance Domain and Path defined in the step or runtime input, for example https://qa.jpgr.org:3002/login/us.

  • The variant is the UTC timestamp when the step scanned the instance.

Note the following:

  • Auto is not available when the Scan Mode is Ingestion.

  • Auto is the default selection for new pipelines. Manual is the default for old pipelines, but you might find that neither radio button is selected in the UI.

  • You should carefully consider the baseline you want to specify for your instance target. Every target needs a baseline to enable the full suite of STO features. Here are a few options:

    • Specify a RegEx baseline that captures timestamps. This ensures that every new scan compares issues in the new scan vs. the previous scan. Then it updates the baseline to the current scan.

      You can use this RegEx to capture timestamps: \d{2}/\d{2}/\d{4}\,\s\d{2}\:\d{2}\:\d{2}

    • Specify a fixed baseline.

      1. Scan the instance using a manual variant name.

      2. Select the baseline as a fixed value.

      3. Update the step to use auto-detect for future scans.

      This ensures that future scans get compared with one fixed baseline.

Name

The identifier for the target, such as codebaseAlpha or jsmith/myalphaservice. Descriptive target names make it much easier to navigate your scan data in the STO UI.

It is good practice to specify a baseline for every target.

Variant

The identifier for the specific variant to scan. This is usually the branch name, image tag, or product version. Harness maintains a historical trend for each variant.

Authentication

Domain

The fully-qualified URL to the scanner.

Access Token

The access token used to log in to a specific product in the scanner. This is required for some scans. 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.

URL Scope

To configure the URL Scope using the Default Scope, set the following fields as described below:

Instance

Domain

Domain of the application instance to scan. You can include the full path to the app in this field, or split the full path between the Domain and the Path fields. Example: https://myapp.io/portal/us

Protocol

HTTPS (default) or HTTP.

Port

The TCP port used by the scanned app instance.

Path

Path to append to the application instance domain, if you're splitting the full path between the Domain and Path settings. For example, you might specify the domain as https://myapp.io and the path as /portal/us.

Username

Username to log in to the instance you want to scan.

Password

The access token to log in to the instance you want to scan. In most cases, this is a password or an API key.

To configure the URL Scope using Detailed Scope, you must set the following fields as described. For more information, refer to the Burp Suite documentation on Detailed Scope Configuration.

Instance

Username

Username to log in to the instance you want to scan.

Password

The access token to log in to the instance you want to scan. In most cases, this is a password or an API key.

Scope

Start URLs

Enter the URLs that you want Burp Scanner to start scans from. Scans only send requests to URLs that are in scope. By default, Burp Scanner automatically bases the scope on the start URLs. This is the same as the start_urls parameter in the Burp API. You can specify multiple URLs separated by commas. For example, https://ginandjuice.shop/,https://ginandjuice.shop/about

In Scope URL Prefixes

Add URL prefixes to modify the site scope. Burp Scanner can only scan URLs that begin with one of these prefixes. Your Start URLs need to be in scope. This is the same as the in_scope_url_prefixes parameter in the Burp API. You can specify multiple URLs separated by commas. For example, https://ginandjuice.shop/,https://ginandjuice.shop/about

Out of Scope URL Prefixes

Exclude URL prefixes from the site scope. All paths that start with the URL prefix are out of scope. This is the same as the out_of_scope_url_prefixes parameter in the Burp API. You can specify multiple URLs separated by commas. For example, https://ginandjuice.shop/blog,https://ginandjuice.shop/image/

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.

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:

Log Level

The minimum severity of the messages you want to include in your scan logs. You can specify one of the following:

  • DEBUG

  • INFO

  • WARNING

  • ERROR

Additional CLI flags

Use this field to run the scanner binary with additional flags supported by the external scanner.

Passing additional CLI flags is an advanced feature. Harness recommends the following best practices:

  • Test your flags and arguments thoroughly before you use them in your Harness pipelines. Some flags might not work in the context of STO.

  • Don't add flags that are already used in the default configuration of the scan step.

    To check the default configuration, go to a pipeline execution where the scan step ran with no additional flags. Check the log output for the scan step. You should see a line like this:

    Command [ scancmd -f json -o /tmp/output.json ]

    In this case, don't add -f or -o to Additional CLI flags.

Fail on Severity

Every STO scan 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

PreviousBrakeman step configuration
NextCheckmarx

Last updated

Was this helpful?