One of the most effective ways of enhancing the security posture of a solution is to incorporate security into the development lifecycle and embed it within the normal CI/CD pipelines of a project. As a CI/CD pipeline should complete within only a few minutes testing should be minimal to allow the identification of critical issues, in order to reduce the need for long running processes as part of this pipeline, but ensure a complete assessment, a regular nightly process should run to perform more thorough assessment of the solution.
In this post I am going to look at the Passive Pentest stage of the CI/CD Pipeline, I will cover the other stages in another post. The tool I normally choose for penetration testing is OWASP ZAP. OWASP is a worldwide not-for-profit organization dedicated to helping improve the quality of software. The Zed Attack Proxy (ZAP) is a free penetration testing tool for beginners to professionals. ZAP includes an API and a weekly docker container image that can be integrated into your deployment process.
There is a set of scripts available from https://github.com/Deliveron/owasp-zap-vsts-extension which help with the tasks in this pipeline. And make it a fairly simple process of integrating into you process. Unfortunately these scripts use the old Azure RM powershell module, I have updated the baseline script, to use the newer Az module. You can download a copy here.
The entire stage consists of 3 tasks:
- ACI Pentest baseline
- Transform the results
- Publish the test results
Step 1 – run the baseline scan
The first task needs to run the PowerShell script Invoke-OwaspZapAciBaseline.ps1, this script will configure a resource group and storage account, download the latest OWASP-ZAP container image run this within the Azure Container Service. Then initiate a baseline scan of the target system, retrieve the test results and then destroy the resources.
Step 2 – Transform the report
In order to be able to make use of the output from the scan this needs to be transformed into a supported format, using an XLST. This is again done via a bit of powershell script.
This uses the XLST (OWASPToNUnit3.xslt)and powershell script (Transform.ps1) contained in the resource zip file available here.
Step 3 – publish the test results
The third and final step in the pipeline is to publish the results of the test to Azure DevOps, this can be done using the native Publish Test Results task.
You can view the number of identified issues form the release screen.
Clicking on this will then take you a list of the issues, and from here you can either view further details or choose to raise a bug within the backlog for the identified issue.
Pingback: Integrating ARM Template Security Testing into a DevOps Pipeline - John Nunn's Blog
Pingback: Top Stories from the Microsoft DevOps Community – 2020.09.04 - Microsoft Today