{"id":36636,"date":"2019-05-14T06:00:59","date_gmt":"2019-05-14T13:00:59","guid":{"rendered":"http:\/\/devblogs.microsoft.com\/premier-developer\/?p=36636"},"modified":"2019-05-06T07:51:10","modified_gmt":"2019-05-06T14:51:10","slug":"azure-devops-pipelines-leveraging-owasp-zap-in-the-release-pipeline","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/premier-developer\/azure-devops-pipelines-leveraging-owasp-zap-in-the-release-pipeline\/","title":{"rendered":"Azure DevOps Pipelines: Leveraging OWASP ZAP in the Release Pipeline"},"content":{"rendered":"

In this blog App Dev Manager Francis Lacroix<\/strong> shows how to integrate OWASP ZAP within a Release pipeline, leveraging Azure Container Instances, and publish these results to Azure DevOps Test Runs.<\/p>\n

\n

As part of an organization\u2019s automated Release pipeline, it is important to include security scans and report on the results of these scans. One tool used in the industry is the OWASP Zed Attack Proxy (ZAP)<\/a>. In this blog, we will integrate OWASP ZAP within a Release pipeline, leveraging Azure Container Instances, and publish these results to Azure DevOps Test Runs.<\/p>\n

Assumptions<\/h2>\n

As this work is based on a PoC for a Premier Developer customer, this solution presented operates within certain assumptions.<\/p>\n

    \n
  1. Leverage ACI to host OWASP ZAP on demand<\/strong>. The customer did not want to maintain an IaaS based installed of OWASP ZAP, nor did they have an AKS cluster to deploy the OWASP ZAP container into. They wanted an on-demand deployment to minimize management overhead of the security scanning tool.<\/li>\n
  2. Import the scan results into Azure DevOps Test Runs<\/strong>. Since the customer already leverages Azure DevOps for automated test runs, they wanted the results of the OWASP ZAP scan in the same tool to present a single view of all test results.<\/li>\n
  3. Run on a Microsoft Hosted Windows agent<\/strong>. The customer did not want to manage their own self-hosted agent(s), and requested this be done on a Windows based (VS 2017 at the time) agent.<\/li>\n<\/ol>\n

    Issues and Limitations<\/h2>\n

    Based on the above assumptions, there were a few issues and limitations to overcome:<\/p>\n

      \n
    1. Due to how ACI handles NATing, OWASP ZAP wasn\u2019t able to bind to the container\u2019s public address (know OWASP issue: see Behind NAT<\/a>). As such, we were not able to leverage the API, which made us unable to use the task available in the Marketplace. An IaaS base solution could simply use the Talk in the Marketplace.<\/li>\n
    2. OWASP ZAP\u2019s report format is not natively supported by the PublishTestResults task. As such, we needed to convert it to a compatible format. A few options are available, we chose to use an XSL Template to convert it to a Nunit3 formatted results file.<\/li>\n
    3. The work presented here is part of a Release Pipeline based on the customer needs. However, if it is to be reused in multiple pipelines, it would make more sense to set it up as a Task Group<\/a>.<\/li>\n<\/ol>\n

      Building the Release Pipeline<\/h2>\n

      The Release Pipeline itself is fairly simple. In our example, we will have one Artifact, which is an Azure Git artifact containing only the XSLTemplate used to transform the results file for publishing.<\/p>\n

      <\/p>\n

      We have several Variables set on the Pipeline:<\/p>\n