Integrating ZAP into CI/CD Pipeline

DAST in the SDLC

It’s common to include DAST during the test phase. The automated tools used here are often optimized for speed, so they’ll usually only catch low-hanging fruit vulnerabilities.

When the application is ready to go into production, running a full-blown web application pentest is always good practice to find any flaws in the final product implementation.

Integrating ZAP

In order to integrate ZAP into our pipeline, we need to use zap2docker which is a dockerized version of ZAP.

In this example, we have a simple application with a webapp and an api backend with the following Jenkinsfile for both repositories.

node{

  git branch: "main", url: "http://172.17.0.1:3000/simple-api"

  stage ('Build the Docker image') {
    sh "echo building the image..."
    sh "docker build --tag simple-api:latest ."
    sh "echo building image complete."

  }

  stage ('Deploy the Docker image') {
    sh "echo Deploying the container..."
    sh " docker rm -f simple-api"
    sh "docker run -d -p 8081:5000 --name simple-api simple-api:latest "
    sh "echo Container successfully deployed."

  }
}

This gives us the following stages in Jenkins.

We can add the following block to have OWASP ZAP scan in our pipeline.

  stage ('Scan with OWASP ZAP') {
    sh "mkdir -p zap-reports"
    sh "chmod 777 zap-reports"
    sh "docker run -v \$(pwd)/zap-reports:/zap/wrk/:rw -t owasp/zap2docker-stable zap-api-scan.py -t http://172.17.0.1:8081/swagger.json -f openapi -r api-simple-api-${env.BUILD_NUMBER}.html"
  }

Let’s breakdown this docker command that we’re adding.

• docker run is the command to run a Docker container.
• -v \$(pwd)/zap-reports:/zap/wrk/:rw specifies a volume mount, where \$(pwd)/zap-reports where the command is being executed appended with "/zap-reports".
• -t specifies the option to allocate a terminal for the container.
• owasp/zap2docker-stable is the name of the Docker image to be used for the container.
• zap-api-scan.py initiates the API scan using OWASP ZAP.
• -t http://172.17.0.1:8081/swagger.json specifies the target for the API scan.
• -f openapi specifies the format of the output report.
• -r api-simple-api-${env.BUILD_NUMBER}.html specifies the name of the output report file with the build number appended to it.

Once this is added, we should see a third column now in Jenkins that includes the ZAP scan.

It’s important to note that this is a basic scan which will catch mainly low hanging fruit like SQL injection or XSS. However, since this is running on every commit that’s made, we want to keep it basic so it doesn’t take hours to finish and hold up the pipeline.

We can then find the ZAP report file in the Workspace folder.