Penetration testing is really the last piece in the DevOps puzzle in terms of application testing and brings us full circle, or rather back to the right-hand end of the DevOps pipeline, so to speak. The question becomes, how can we automate penetration testing as part of our CI, CD process? There are many tools out there that will do this, but I'm going to look at one in particular and how to integrate it with the build pipeline.

If you recall earlier on in the course, when I talked about injection attacks and I said it was the number one on the top 10 list of OWASP, the Open Web Application Security Project Security Risks. Well, it turns out, OWASP has a product called OWASP ZAP, which can perform both passive and active penetration testing on your web app.

Currently, OWASP ZAP is not provided as a service. But to give you an idea of how it works, you can download an executable, which I've done here and I'm running it against my app service. The good people at Microsoft have created an extension you can download for free into your Azure DevOps organization.

Let's go over to the marketplace and find that extension. I'll just search for OWASP ZAP. Here it is, the OWASP ZAP scanner. We'll just have a quick look down the page because there are some interesting scripts here that we're going to use later on for integrating their reports into our DevOps tests. I'll just install it by clicking the Get It For Free button and go back to my project build pipeline.

So the first thing I need to do is add the OWASP scanner task. You have two choices of scan type, targeted or scan on an agent. We are going to use targeted scan, as this means targeting a URL. Scan on an agent is when you want to scan on a container app. Aggressive scan mode means active penetration testing, which simulates what a hacker might do to try and break into or break your website.

Failure threshold is the number of failures the scanner will tolerate until it fails the build. And of course, I'll be scanning on port 80, but obviously you can change that if the need arises. After the scanning has been run, we need to get hold of the reports. And we are going to do that with a publish build artifacts task. I'm just going to give it a meaningful name, but I will also need to change the path to publish to, Build dot Sourcedirectory forward-slash owaspzap. I don't need the published location. And while I remember, we shouldn't run aggressive mode on OWASP ZAP scanning during continuous integration and deployment. Aggressive or active mode is resource and time-intensive and it's something that should be done on a scheduled job, perhaps overnight when people aren't working on the build pipeline. And if the application is in production, at times when it is likely not to be highly-utilized.

Having published the reports, this is where I want to go back to the marketplace and grab those scripts to integrate into Azure DevOps testing. So I'll just copy the first one and paste it in, then grab the next script, which is another bash script, paste that in. And then the last task is to publish the test results. Now that we've finished setting up the build script, we can save and run it. Let's just go and have a look at the pipeline in action.

As I mentioned before, OWASP ZAP is not a service. So to get it to work as an extension within Azure DevOps, there is a build of the executable in a container that gets downloaded and run. OWASP has a regularly updated container image on their website that is free to use. So we go to our artifacts under build summary and we can see the raw, OWASP ZAP reports.

Let's have a look at the HTML report. Next, if we go into tests under summary, we can see that the tests are being integrated from OWASP ZAP. Let's have a look at the details. But you can also create a bug issue directly from the tests, with all the details from the report filled in and suggested solutions. So I'll just do that and assign it to the guy with the five empty coffee cups on his desk. And there we go.