Skip to content

Continuous Security Testing

Run Escape scans from the pipeline you already have. Every integration on this page does the same two things: start a scan on a profile, and optionally wait for it to finish so your build can act on the result.

You need two values, both on the profile's CI/CD page in the app: the profile ID and your API key. Store the key as a secret in your CI provider, never in the repository.

Pick Your Provider

  • GitHub Actions

    A published Action with profile_id, api_key, watch, and configuration override inputs. Set it up

  • GitLab CI/CD

    A pipeline job using the CLI image, with masked CI/CD variables. Set it up

  • Bitbucket Pipelines

    A pipeline step driven by repository variables. Set it up

  • CircleCI

    A job using a Docker executor and project environment variables. Set it up

  • Jenkins

    A declarative pipeline stage reading credentials from the Jenkins store. Set it up

  • Azure DevOps

    A pipeline task using secret variables from your variable group. Set it up

  • Travis CI

    A build script step using encrypted environment variables. Set it up

  • Harness

    A CI stage running the CLI container with Harness secrets. Set it up

  • Bamboo

    A script task using plan variables. Set it up

  • Any CI

    The CLI binary or the escapetech/cli Docker image, for any provider not listed above. Set it up

Shape the Scan From the Pipeline

A scan started from CI uses the profile's configuration from the app, including authentication, scope, security tests, and notification channels. Three hooks let a pipeline change that per run.

Configuration overrides replace profile settings for a single scan. Pass JSON matching the scanner configuration schema with --override, the Action's configuration_override input, or configurationOverride through the Public API. Common uses are switching to non-destructive testing, capping scan duration, and swapping authentication headers for an ephemeral environment.

escape-cli scans start <profile-id> --watch \
  --override '{"mode": "read_only", "max_duration": 3600}'

Scope narrowing is the same mechanism pointed at a smaller target. Your pipeline maps the Git diff to affected routes or pages, then passes that scope as an override, so a merge request scan tests what the merge request changed. See Incremental Scanning.

Schema upload keeps API coverage in sync with the code. Upload the OpenAPI or GraphQL schema your build just produced, then attach it to the profile:

escape-cli profiles update-schema <profile-id> <schema-id>

On GitHub Actions, the schema input runs this step for you with the upload ID you give it.

What Happens After the Scan

Pipeline-triggered scans are regular scans, so everything configured on the platform still applies. Findings land in the profile's results, notification channels fire, and Workflows run their triggers, conditions, and actions: open a Jira ticket, post to Slack, call a webhook.

A common Gitflow setup pairs both modes: a scoped blocking scan on merge requests to gate the merge, and a full non-blocking scan on main after deployment.