Home  Audience  Developers

Developers

DevSecOps: Integrating a Dynamic Application

Security Testing Tool with Jenkins
By B Thangaraju - Akhilank M J Kaipu - March 4, 2021  3270  0

Subscribe to updates
Unsubscribe from updates

In this article, the authors propose a method to integrate the OWASP ZAP DAST tool with Jenkins to publish
reports on the vulnerabilities found in a Web application ‘IIITB feedback’ and corresponding solutions. The
source code of the project is available at https://github.com/RahulSapparapu/Iiitbfeedback/. The Web
application accepts student ratings about a professor and saves each response in an SQL database. The
authors use the open source tool OWASP ZAP to integrate with Jenkins for easier manual or automatic
security testing, which can be helpful for both beginners and professional Web application developers.
Security is the main concern in the case of Web applications. Testing a product after deployment is a
hard task. DevSecOps is a process of integrating security measures into the DevOps process. The
Software Development Life Cycle (SDLC) is introduced in DevSecOps to make applications very secure
by using a variety of tools for different security concerns. Dynamic Application Security Testing or
DAST is a security measure where Web applications are tested dynamically for vulnerabilities while
still in production. This type of testing is also called ‘black box testing’ as it does not consider the
internal infrastructure of applications but instead looks at an attacker’s perspective. It is helpful to
weed out vulnerabilities like SQL injection, cross-site scripting and even with some runtime problems
like server issues and authentications. The DAST tool we have used for our experiment is called
OWASP ZAP, which is one of the existing popular open source tools.

The system requirements are as follows.

OS version: Kali Linux (with pre-installed security tools including OWASP ZAP)
RAM allocation: Minimum of 4GB (in case of VM)
Installed Jenkins and Java 8 version

Introduction to OWASP ZAP

Open Web Application Security Project Zaproxy (OWASP ZAP) is a popular DAST tool. It is used by
most penetration testers for testing automation. We have used this tool for our Web application
testing since it is easily integrated with Jenkins in the CI/CD pipeline with a plugin.

Integration with Jenkins

To automate the process of testing, we have integrated the OWASP ZAP tool with Jenkins using the
tool’s plugin. The steps for the process of integration are given below.

1. Install the OWASP ZAP official plugin, HTML publisher plugin and custom tools plugin. In the
Manage Jenkins option, select Manage Plugins. In the available section, select the OWASP ZAP
official plugin, as shown in Figure 1.

Figure 1: OWASP ZAP plugin in Manage Plugins

2. In the Global Tool Configuration, click on the custom tools installations and complete the entries, as
shown in Figure 2.
Figure 2: Custom tools in the Global Tool Configuration

This allows us to use different tools in Jenkins like OWASP ZAP.

3. Create a new freestyle project called ZAP_demo using the New Item option shown in the dashboard
(Figure 3) as soon as we start Jenkins.

Figure 3: New freestyle project

4. We can start the configuration of the new project by selecting the Configure option when we open
the project. We will get a Configuration setup page, as shown in Figure 4. We specify how our new
project should work when we build in this page.
Figure 4: Configuration of the new project

5. In the build stage, add a build step called Execute ZAP and fill in the Admin configuration as
depicted in Figure 5.

Figure 5: Admin configuration section

6. If the OWASP ZAP tool is installed in the system, check the System Installed option in the
installation method stage. If not, then check the custom tool installation option. If ZAP is already
installed in the system, set the environment variable to the path of ZAP

(ZAPROXY_HOME) like in Figure 6.

Figure 6: Installation method and ZAP directory

7. Next, in Session management, select Persist session and input any name for the session, as shown
in Figure 6.

8. Under Session properties, set the context name to default and enter the URL where your Web
application is running in the Include in Context option, as shown in Figure 7.

Figure 7: Session properties

9. In the Attack mode stage, select the type of attack to be carried out on the mentioned Web
application. This allows us to make a premeditated attack on our Web application to actively weed out
the vulnerabilities from the viewpoint of the attacker. You can also choose the type of attack on the
website to find different types of vulnerabilities. ZAP gives us two spiders to crawl a given Web
application. These are the traditional spider and the Ajax spider.
The traditional spider is faster compared to the Ajax spider but not as effective for Ajax Web
applications. The traditional spider explores the response HTML, while the Ajax spider invokes
browsers and then follows the links that are given out. We can use either one of these or can use both
in our penetration testing, as shown in Figure 8.

Figure 8: Attack mode

10. In the Finalize run section, select Generate Reports to get the results of the attack previously
conducted, and select the type of reports you want to get. It has two options — XML or HTML type of
reports or both can be published, as seen in Figure 9. Save the configurations.

Figure 9: Finalize run

11. In the post-build step, select Archive the artifacts, publish the HTML reports option and fill in the
details, as shown in Figure 10. Here, we can name the HTML reports as per our needs as well as the
folder where it is being published.
 Figure 10: Post-build actions

The result

After building the project, we get the options to open the reports of our choice in the Stage view area.
Reports can be accessed by selecting the links below the last successful artefact’s icon, which is
shown in Figure 11.

Figure 11: Stage view of the project

From the generated report, we can find a detailed summary of the type of attacks done, the number of
vulnerabilities found at various degrees of threat levels, and an explanation of the vulnerability along
with the solutions for it. Figure 12 shows the ZAP scanning report for our Web application.

Figure 12: Report on the scan conducted on the Web application

From the report, we can infer that the threat levels of the vulnerabilities are divided into four
categories, namely, High, Medium, Low and Informational which are provided to us in the form of a
table. For example, in the above case we found one medium level threat and four low level threats in
our Web application.

The report also gives a detailed account of each type of vulnerability found. It provides a description
of the vulnerability parameters as well as the solutions to resolve them as shown in Figure 13, where
we have found a vulnerability called ‘X-frame option header is not present’. The method to resolve this
vulnerability is given in the solution section. You can also use the link given in the Reference section
to further read up on the resolution method.

Figure 13: Description of vulnerability and proposed solution

The Open Web Application Security Project Zaproxy (OWASP ZAP) tool is used for Dynamic
Application Security Testing of the Web application. From the result, we were able to identify threats
and proposed solutions. This article may help you to identify threats at the production or development
stage, and resolve the security issues early on instead of after the complete product development.

TAGS application security DevOps jenkins SQL database ZAP DAST