# 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](<https://app.escape.tech>): 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](<https://docs.escape.tech/documentation/automate/ci-cd/github/index.md>)
- ## **GitLab CI/CD**

  A pipeline job using the CLI image, with masked CI/CD variables. [Set it up](<https://docs.escape.tech/documentation/automate/ci-cd/gitlab/index.md>)
- ## **Bitbucket Pipelines**

  A pipeline step driven by repository variables. [Set it up](<https://docs.escape.tech/documentation/automate/ci-cd/bitbucket/index.md>)
- ## **CircleCI**

  A job using a Docker executor and project environment variables. [Set it up](<https://docs.escape.tech/documentation/automate/ci-cd/circleci/index.md>)
- ## **Jenkins**

  A declarative pipeline stage reading credentials from the Jenkins store. [Set it up](<https://docs.escape.tech/documentation/automate/ci-cd/jenkins/index.md>)
- ## **Azure DevOps**

  A pipeline task using secret variables from your variable group. [Set it up](<https://docs.escape.tech/documentation/automate/ci-cd/azure/index.md>)
- ## **Travis CI**

  A build script step using encrypted environment variables. [Set it up](<https://docs.escape.tech/documentation/automate/ci-cd/travis/index.md>)
- ## **Harness**

  A CI stage running the CLI container with Harness secrets. [Set it up](<https://docs.escape.tech/documentation/automate/ci-cd/harness/index.md>)
- ## **Bamboo**

  A script task using plan variables. [Set it up](<https://docs.escape.tech/documentation/automate/ci-cd/bamboo/index.md>)
- ## **Any CI**

  The CLI binary or the `escapetech/cli` Docker image, for any provider not listed above. [Set it up](<https://docs.escape.tech/documentation/automate/ci-cd/any-ci/index.md>)

## Shape the Scan From the Pipeline

A scan started from CI uses the profile's configuration from [the app](<https://app.escape.tech>), 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](<https://docs.escape.tech/documentation/automate/public-api/index.md>). Common uses are switching to non-destructive testing, capping scan duration, and swapping authentication headers for an ephemeral environment.

```bash
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](<https://docs.escape.tech/documentation/automate/ci-cd/incremental-scanning/index.md>).

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

```bash
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](<https://docs.escape.tech/documentation/automate/workflows/index.md>) 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.

## Related

- [Incremental Scanning](<https://docs.escape.tech/documentation/automate/ci-cd/incremental-scanning/index.md>): narrow scan scope to the code that changed
- [Escape CLI](<https://docs.escape.tech/documentation/automate/cli/index.md>): every command these pipelines call
- [Practical Recipes](<https://docs.escape.tech/documentation/automate/cli/recipes/index.md>): quality gates and other ready-made scripts
- [Public API](<https://docs.escape.tech/documentation/automate/public-api/index.md>): start scans without the CLI
- [Workflows](<https://docs.escape.tech/documentation/automate/workflows/index.md>): route findings to your tools