Continuous security testing
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. Detailed, credentials-filled code snippets and examples can be found from the CI/CD management page of your Escape application.
As of now, Escape scans can be triggered from the following usages:
We are currently implementing solutions for other integrations. Let us know your needs so that we can match them as closely as possible !
Automatic scan triggers
Escape provides a way for you to integrate its scanning functionalities within your CI/CD pipelines.
Basic scan triggers
As of now, we support two types of CI triggers:
- Trigger a scan in a non-blocking way (primarily intended for monitoring purposes)
- Trigger a scan, wait for this scan to be over, and ensure no vulnerabilities are detected (primarily intended for CI/CD purposes).
Compatibility with the Escape security platform
This integration includes every regular feature of the security scan from Escape.
Especially, scans triggered using this method will use the application configuration on the Escape platform. It will notify your team at the end using whatever contact channels that were defined for this organization (see integrations).
Scan configuration overrides
When using dynamic parameters for the scans configuration, our integrations allow you to provide configuration overrides when triggering a scan. It is possible, for instance to renew the authentication headers before starting a scan.
Schema for your applications can be programatically updated, allowing to easily keep your Escape application synced with the schema of your endpoint.
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