Automated Security Testing with Jenkins Pipeline and OWASP ZAP: Step-by-Step Guide

In today’s software development landscape, security is a paramount concern. Cyber threats are evolving rapidly, and ensuring the security of your web applications is more critical than ever. One powerful tool at your disposal is OWASP ZAP (Zed Attack Proxy), an open-source security testing tool designed to identify vulnerabilities in web applications.

In this step-by-step guide, I’ll show you how to harness the power of OWASP ZAP for automated security testing, in conjunction with Jenkins, a widely used open-source automation server. Whether you’re a DevOps engineer, a developer, or involved in software development, the techniques outlined in this guide will help you enhance the security of your web applications by configuring OWASP ZAP, setting up a Docker container, defining scan types, and generating detailed security reports. Jenkins, as our automation server, plays a vital role in streamlining this process. By the end of this journey, you’ll have a strong foundation for automating security testing while maintaining a lean focus on the tools you need to safeguard your web applications.

OWASP

Setting Up Jenkins Pipeline

This pipeline streamlines the process of setting up the OWASP ZAP Docker container, defining scan types, scanning target applications, and emailing the scan reports.

1. Parameter Initialization

The first step in our pipeline is parameter initialization. We offer users the flexibility to choose the type of scan they want to perform inside the container. The parameters are as follows:

SCAN_TYPE: Users can select ‘Baseline,’ ‘APIS,’ or ‘Full’ scans, depending on their requirements.
TARGET: This parameter is for specifying the target URL to be scanned.
GENERATE_REPORT: Users can choose whether they want to generate a report for their scans.
Here’s how these parameters are defined in the Jenkins pipeline:

parameters {
choice choices: [‘Baseline’, ‘APIS’, ‘Full’],
description: ‘Type of scan that is going to perform inside the container’,
name: ‘SCAN_TYPE’

string defaultValue: ‘https://yuvaraj.com/’,
description: ‘Target URL to scan’,
name: ‘TARGET’

booleanParam defaultValue: true,
description: ‘Parameter to know if you want to generate a report.’,
name: ‘GENERATE_REPORT’
}

These parameters are essential as they allow users to customize the security testing process according to their needs.

2. Setting up the OWASP ZAP Docker Container

The second stage, titled ‘Setting up OWASP ZAP Docker container,’ is a crucial part of our pipeline. This stage involves pulling the latest OWASP ZAP Docker container and starting it in detached mode.

Here’s why this stage is important: The Docker container serves as the environment where OWASP ZAP will perform security scans. We ensure that we’re using the most up-to-date OWASP ZAP environment by pulling the latest stable container. Starting the container in detached mode allows it to work in the background, ready to execute scans.

The commands used for this stage are:

Stage(‘Setting up OWASP ZAP Docker container’) {

steps {

sh ‘docker pull owasp/zap2docker-stable:latest’
sh ‘docker run -dt — name owasp owasp/zap2docker-stable /bin/bash’

sh ‘docker exec owasp mkdir /zap/wrk’

}

}

The first command pulls the container, while the second one starts it. The — name flag assigns a name to the container, making it easy to reference in subsequent steps. The /bin/bash command starts a shell within the container, enabling interaction.

3. Scanning the Target on the OWASP Container

The heart of our pipeline is the stage where we perform security scans on the target application. This stage involves selecting a scan type (Baseline, APIS, or Full) and specifying the target URL. Here’s how it works:

• The scan_type and target variables are initialized based on the selected parameters.
• Depending on the chosen scan type, the appropriate OWASP ZAP scan is executed.
• If it’s a ‘Baseline’ scan, the command runs zap-baseline.py. For ‘APIS,’ it’s zap-api-scan.py. And for ‘Full’ scans, zap-full-scan.py is used.
• The scan results are saved as ‘report.html’ in the container.

Here’s how these steps are implemented in the Jenkins pipeline:

stage('Scanning target on owasp container') {
    steps {
        script {
            scan_type = "${params.SCAN_TYPE}"
            echo "----> scan_type: $scan_type"
            target = "${params.TARGET}"
            if (scan_type == 'Baseline') {
                sh """
                     docker exec owasp \
                     zap-baseline.py \
                     -t $target \
                     -r report.html \
                     -I
                 """
            } else if (scan_type == 'APIS') {
                sh """
                     docker exec owasp \
                     zap-api-scan.py \
                     -t $target \
                     -r report.html \
                     -I
                 """
            } else if (scan_type == 'Full') {
                sh """
                     docker exec owasp \
                     zap-full-scan.py \
                     -t $target \
                     -r report.html \
                     -I
                 """
            } else {
                echo 'Something went wrong...'
            }
        }
    }
}

The purpose of this stage is to perform comprehensive security scans on the target application, ensuring that any vulnerabilities are identified.

4. Copying the Report to Workspace

After the scan is completed, we need to transfer the scan report from the OWASP ZAP Docker container to the Jenkins workspace. This is a critical step as it allows further analysis and sharing of the scan results. The command for this is:

stage('Copy Report to Workspace') {
    steps {
        script {
            sh '''
                 docker cp owasp:/zap/wrk/report.html ${WORKSPACE}/report.html
             '''
        }
    }
}

By copying the report to the Jenkins workspace, we ensure easy access and processing of the scan results.

5. Emailing the Report

The final part of our pipeline involves sending the OWASP ZAP scan report via email. This stage is essential for sharing the results with relevant team members or stakeholders. The email includes the scan report as an attachment. Here’s how it works:

• The report file is attached to the email.
• The email’s body contains a message notifying the recipients of the attached report.
• The recipients are specified, and the email subject is set to “OWASP ZAP Report.”

This stage streamlines the sharing of critical security information with the team.

6. Post Actions

The last part of the pipeline consists of post-actions. These actions are executed always, regardless of the pipeline’s success or failure. In this stage:

• The OWASP ZAP Docker container is stopped and removed.

Here’s how this is implemented in the Jenkins pipeline:

post {
    always {
        echo 'Removing container'
        sh '''
             docker stop owasp
             docker rm owasp
         '''
        cleanWs()
    }
}

By removing the container and cleaning the workspace, we ensure that the environment remains clean and efficient for future runs of the pipeline.

Conclusion

In this guide, we’ve unlocked the potential of automated security testing with OWASP ZAP and Jenkins. Whether you’re a DevOps engineer or a developer, our journey has equipped you to enhance the security of your web applications.

By streamlining security testing, customizing scans, and automating report generation, we’ve laid the foundation for robust protection. The use of Docker containers ensures reliability, while seamless communication through email sharing keeps your team informed. Security is an ongoing journey, and with this newfound knowledge, you’re ready to safeguard your web applications, protect your users, and stay one step ahead of evolving threats.

Hopefully, you have found this post informative and the proposed solution useful.

Feel free to share your feedback

About the Author

Yuvaraj Yadav is a Software Engineer at Protegrity Inc. He is a subject matter expert for AWS Code Deploy and Jenkins. In his role, he enjoys supporting customers with their Automation and other DevOps configurations. Outside of work he enjoys Swimming and Chilling out with his pals.