# 🏁 CI/CD integration

# Continuous security testing

Including our security scans within the delivery flow of technical teams is a core part of Escape. You can use our security tools within your CI/CD flows, and we are constantly working more on improving how well security scans integrate as part of your processes.

Escape only runs one concurrent scan per application.

If a scan is already running on one of your apps, we will cancel it before the CI job starts a new scan on your application.

# Features

Escape provides a way for you to integrate its scanning functionalities within your CI/CD pipelines.

As of now, we support two types of CI triggers:

  1. Trigger a scan in a non-blocking way (primarily intended for monitoring purposes)
  2. Trigger a scan, wait for this scan to be over, and ensure no vulnerabilities are detected (primarily intended for CI/CD purposes).

We are currently implementing solutions for other integrations. Let us know your needs (opens new window) so that we can match them as closely as possible !

This integration includes every regular feature of the security scan from Escape. Especially the scan triggered using this method will use the application configuration on the Escape platform (opens new window). It will notify your team at the end using whatever contact channels that were defined for this organization (see notifications).

# Intended usage

Escape is effortless to integrate into your CI/CD at two different steps of your Gitlflow πŸ’ͺ.

  • Run a scan at every commit being pushed on a specific branch
  • Run a scan before deploying the test environment onto production

Beyond that, you can design your triggers using our CLI (opens new window).

# Required parameters

This action requires an application ID and an API key to be provided.

You can find these values in your Escape application settings.

An image

application_id: The id of the application on Escape that will be scanned continuously api_key: Your API key on the Escape platform

# Examples

# Secure my application at every commit on a specific branch

Escape will start every time a new feature branch or commit is merged on the targeted branch (this example will consider a branch named staging), after being deployed. That way, you can immediately ensure that every new commit merged on this branch does not add new security or performance issues to your app.

When Escape notifies you of a new issue, you can either revert the concerned merge request manually or fix it in another merge request using Escape’s remediations proposals (or by ignoring the issue). That way, you ensure that no issue can reach your production.

Github Action example:

# https://github.com/Escape-Technologies/action
name: Post Deploy
on:
  push:
    branches:
      - staging
jobs:
  Escape:
    runs-on: ubuntu-latest
    steps:
      - name: Escape Scan
        uses: Escape-Technologies/action@v0
        with:
          application_id: ${{ secrets.ESCAPE_APPLICATION_ID }}
          api_key: ${{ secrets.ESCAPE_API_KEY }}
          # timeout: 1200 (default - in seconds)

Gitlab CI example:

Escape:
  stage: post-deploy
  needs: deploy # name of your deployment job
  variables: # you can find those secrets directly in your Escape Application Settings
    - ESCAPE_APPLICATION_ID: $ESCAPE_APPLICATION_ID
    - ESCAPE_API_KEY: $ESCAPE_API_KEY
    # - TIMEOUT: 1200 (default - in seconds)
  image: node:alpine
  before_script:
    - npm install -g @escape.tech/action
    - npm show @escape.tech/action version
  script:
    - escape-action
  allow_failure: true
  only:
    refs:
      - staging

# Trigger a non-blocking scan every time a commit is pushed on a branch

In this case, a security scan will be triggered every time a commit on the targeted branch is pushed. This job will remain non-blocking: The scan will be started, but the CI job will not wait for it to be finished before terminating. The triggered scan will run asynchronously on Escape, and your team will be notified at the end of it, using your desired notifications settings.

Github Action example:

# https://github.com/Escape-Technologies/action
name: Post Deploy
on:
  push:
    branches:
      - staging
jobs:
  Escape:
    runs-on: ubuntu-latest
    steps:
      - name: Escape Scan
        uses: Escape-Technologies/action@v0
        with:
          application_id: ${{ secrets.ESCAPE_APPLICATION_ID }}
          api_key: ${{ secrets.ESCAPE_API_KEY }}
          timeout: 0 # This will make the pipeline terminate as soon as the scan is started (but will not stop the scan!)

Gitlab CI example:

Escape:
  stage: post-deploy
  needs: deploy # name of your deployment job
  variables: # you can find those secrets directly in your Escape Application Settings
    - ESCAPE_APPLICATION_ID: $ESCAPE_APPLICATION_ID
    - ESCAPE_API_KEY: $ESCAPE_API_KEY
    - TIMEOUT: 0 # This will make the pipeline terminate as soon as the scan is started (but will not stop the scan!)
  image: node:alpine
  before_script:
    - npm install -g @escape.tech/action
    - npm show @escape.tech/action version
  script:
    - escape-action
  allow_failure: true
  only:
    refs:
      - staging

# Trigger a blocking scan whenever a merge request is opened on a target branch

With this technique, a CI job will start a scan whenever you open a merge request onto the desired branch, and the pipeline will wait for the scan to terminate successfully before marking the merge request as ready.

When Escape notifies you of a new issue, you can either fix it in on the source branch using Escape’s remediations proposals (or by ignoring the issue), before merging to the target branch.

That way, you ensure that no issues are found on staging before you merge it into prod.

Github Action example:

# https://github.com/Escape-Technologies/action
name: Post Deploy
on:
  pull_request:
    branches:
      - prod
jobs:
  Escape:
    runs-on: ubuntu-latest
    steps:
      - name: Escape Scan
        uses: Escape-Technologies/action@v0
        with:
          application_id: ${{ secrets.ESCAPE_APPLICATION_ID }}
          api_key: ${{ secrets.ESCAPE_API_KEY }}
          # timeout: 1200 (default - in seconds)

Gitlab CI example:

Escape:
  stage: post-deploy
  needs: deploy # name of your deployment job
  variables: # you can find those secrets directly in your Escape Application Settings
    - ESCAPE_APPLICATION_ID: $ESCAPE_APPLICATION_ID
    - ESCAPE_API_KEY: $ESCAPE_API_KEY
    # - TIMEOUT: 1200 (default - in seconds)
  image: node:alpine
  before_script:
    - npm install -g @escape.tech/action
    - npm show @escape.tech/action version
  script:
    - escape-action
  allow_failure: true
  only:
    refs:
      - merge_requests

# Other CI/CD use cases

Please be aware that we are working hard to make Escape compatible with more use cases in your CI/CD. Especially if you are looking for a super fast blocking CI/CD integration, you can follow the advancement of your features by joining our Discord server (opens new window)!

If you need help integrating Escape in your CI/CD customarily or think about other ways of using Escape in your development process, we would be happy to hear from you!