2 Approaches for DAST Automation in CI/CD

by | Nov 23, 2018 | CI/CD, DAST

CI/CD & Automated Testing

“DevOps” and “Agile” as software development approaches are in style and with it the operating principles of continuous integration (CI) and continuous delivery (CD). In order to make these philosophies and set of operating structures work, developers rely heavily on automated testing to quickly deploy new code. A typical testing pipeline includes a variety of unit and integration tests that need to be passed successfully before a new code commit can be deployed to staging/production.

An introduction to DAST within CI/CD

Within those testing pipelines, dynamic application security testing (DAST) has been mostly left out of the picture. This is mainly due to the innate characteristics of the testing approach. DAST scanners examine the web application while it is already running (in a staging or production environment). They test at the HTTP layer by simulating different attacks (e.g. injection attacks) and evaluate the response of the application. On the upside, as the actual response of the running application is evaluated, the false-positive rate is usually pretty low. However, for complex web applications, the testing time is usually quite long, making DAST unsuitable to run after every new code commit in the usual testing pipeline.

The benefits of integration

Integrating a DAST scanner in the CI/CD pipeline has the advantage that a very representative system (in staging) can be tested for crucial security risks early on. This enables development teams to quickly remediate high-risk vulnerabilities as soon as they are introduced.

2 Ways to integrate a DAST scanner into CI/CD

In this article, we want to point out two examples of how a DAST scanner like our pentest module can be integrated into a typical CI/CD pipeline without a lot of configuration.

1. Scheduled: Run the pentest module on a weekly or bi-weekly basis
  • Schedule a weekly/bi-weekly scan on your staging/testing system
  • Pipeline: Create a seperate pipeline
  • Optional: Make it a requirement before pushing to production
  • Suits well with an agile weekly or bi-weekly production schedule
2. Automated in Sequence: Trigger the pentest module once the Build-time checks are complete
  • Automatically trigger a scan, once the Build-time checks such as SAST, integration and unit tests are complete
  • Pipeline: Integrate within existing pipeline for staging
  • Optional: Make it a requirement before pushing to production
  • Note: Plan in a time buffer before pushing to production as the scan can take several hours

Outlook: More automation to come

Looking at current adoption we see that the DAST scanners are not mandatorily blocking items for (continuous) deployment. We are working hard to make that a reality but realize that in order for that to happen, the scanners need to suit a lot more specific use cases. At the moment we advise that tests are run at certain frequencies in parallel with other pipelines in a continuous delivery workflow. Based on the findings of each test run, the security team/DevOps needs to evaluate the corresponding risk level and in critical instances manually block a deploy.

Save time on every test run and gain security insights to improve your code quality.