OWASP Zed Attack Proxy (ZAP) is an open source tool performing pen testing on web
applications and APIs. Pen testing a web application helps ensure that there are no security
vulnerabilities hackers could exploit. OWASP ZAP can be installed as a client application
or comes configured on a docker container. The container option is a great solution for
incorporating pen testing into your DevOps practices and Software Delivery Pipeline to
perform a pen test on each deployment of your application.
In Azure, there are several options for using containers. These options include Azure Container
Services (ACS), Azure Kubernetes Service (AKS), and Azure Container Instances (ACI).
I originally wrote a script that uses a Docker Swarm cluster in ACS but this required always
running virtual machines running in the background. AKS is a fully managed Kubernetes
service but Kubernetes provided a ton of features that I didn’t really need with this deployment.
ACI provides a consumption based option for using containers. This is the perfect tool to to
spin up the container, run the scan, and discard the container after it completes. If you’re
looking for professional penetration testing services, have a look into the penetration testing
cost to better understand what you’re paying for.
The solution for running the pen test includes a PowerShell script to create the Azure resources from
a resource group and execute the scan. There is also a .NET console app that is used to create the
bugs and attach the OWASP report in Azure DevOps. The solution has been posted on GitHub. Please
reach out with an issue for any questions or if you have any problems.
https://github.com/Deliveron/owasp-zap-vsts-extension
I’m using Azure Pipelines to execute the OWASP ZAP pen test against the application after it has
been deployed. I perform this by executing a custom PowerShell script along with a command line
utility that updates Azure DevOps with the scan results and creates bugs for any issues found to
provide actionable work for the developers to trace fixing the issues.
The PowerShell script utilizes a new or existing resource group and the target location to create the ACI
resource attached to a storage account for retrieval of the reports. Once the scan completes, the reports are
attached and bugs created. The ACI and storage accounts are deleted.
The command line utility will attach the OWASP ZAP report and create the bugs into Azure DevOps.
This will need to be compiled and included as an artifact in your release definition.
Use a command line task to execute the following commands. Here are the settings for Attaching the
Reports. Be sure to modify this to include your organization, team project, and personal access token.
Tool
$(System.DefaultWorkingDirectory)/owasp-zap/drop/owasp-zap-vsts-tool/
bin/Release/owasp-zap-vsts-tool.exe
Arguments
attachreport collectionUri="https://youraccount.visualstudio.com" teamProjectName=
"Showcase" releaseUri=$(Release.ReleaseUri) releaseEnvironmentUri=$(Release.EnvironmentUri) filepath=$(System.DefaultWorkingDirectory)\testreport.html personalAccessToken="123456789"
Here are the command line task settings for Creating the Bugs. In this be sure to replace the organization,
team project, team, target URL, and personal access token.
Tool
$(System.DefaultWorkingDirectory)/owasp-zap/drop/owasp-zap-vsts-tool
/bin/Release/owasp-zap-vsts-tool.exe
Arguments
createbugfrompentest collectionUri="https://youraccount.visualstudio.com"
teamProjectName="Showcase" team="Showcase Team" releaseUri=$(Release.ReleaseUri) releaseEnvironmentUri=$(Release.EnvironmentUri) filepath=
$(Agent.ReleaseDirectory)\issues.xml prefix="No WAF" targetUrl=
"https://mywebsite.azurewebsites.net" failOnHigh=False
personalAccessToken="123456789"
I’m actively working on a full-fledged Azure DevOps extension so you can more easily install it in
your Azure DevOps instance and not have to compile command line project. Let me know how it
works for you.
No comments:
Post a Comment