Inside an Azure-based OWASP ZAP implementation

What if you could deploy enterprise-grade security with just a few lines of YAML?
That’s exactly what one global DevOps team set out to do – and shared with us in detail.
Based on insights from a senior developer working hands-on with one of our clients, this article breaks down how they built a scalable, automated scanning solution using OWASP ZAP, fully integrated into Azure and CI/CD pipelines. 

The result?
A cost-effective tool that runs in minutes, fits seamlessly into developer workflows, and delivers security at scale.

The security challenge

Scale meets complexity

Modern enterprises often maintain hundreds of web endpoints across development, testing, and production environments. Each represents a potential entry point for attackers, yet manually testing them all is prohibitively time-consuming and expensive. 

The team identified several key requirements for their security scanning solution.

Architectural deep dive

OWASP ZAP in Azure

Rather than investing in expensive commercial security tools, the team opted to leverage OWASP ZAP
(Zed Attack Proxy) – a widely-respected open-source security testing tool – and orchestrate it through a custom Azure architecture. 

Core components 

The solution's architecture was deliberately kept minimal but powerful

Technical workflow 

1. Trigger 
   A developer or tester initiates a scan through Azure Pipelines, specifying: 
   1. Target URL (e.g., www.example.com) 
   2. Scan type (Web Page or API) 
2. Container provisioning 
   An Azure Container Instance is dynamically created running the OWASP ZAP Docker image 
3. Configuration injection
   Scan parameters are passed to the container, which configures ZAP to run either: 
   1. A passive scan (non-intrusive security checks) 
   2. An active scan (simulated attacks against vulnerabilities) 
   3. API-specific testing with relevant attack vectors 
4. Scan execution
   The container executes the security scan against the target endpoint 
5. Results processing 
   1. Scan findings are output in XML format 
   2. Results are parsed and stored in the Storage Account 
   3. Key metrics and findings are displayed in the pipeline output 
6. Resource cleanup:
   After scan completion (typically 10 minutes), the container is automatically terminated 

Advanced features 

To make the tool practical for everyday use, the team focused on developer experience — adding features that simplified adoption without compromising flexibility.

Scan retention when needed
By default, containers were auto-terminated after each scan to save on costs and resources. But for debugging or deeper inspection, users could opt to retain the container temporarily. As the developer put it: there was an option or checkbox where you could keep the container instance, for example, if you wanted to do some debugging and see more details or troubleshooting if something was not working as expected. 

Pipeline templating 

To lower the barrier to entry, the team built templated Azure Pipelines where users only needed to provide minimal input – such as the target URL and scan type. This made it easy for teams to integrate security scans into their CI/CD workflows without needing security expertise.

Multi-endpoint scanning

The next evolution 

After proving the concept with single-endpoint scanning, the team began work on a more sophisticated capability: scanning multiple endpoints in a single operation. 

This enhancement would allow security teams to perform comprehensive security posture assessments, generating consolidating reports that identify systemic issues across the application landscape. 

The implementation plan includes: 

1. Accepting an array of endpoints via pipeline parameters or a configuration file 
2. Spawning multiple container instances in parallel for distributed scanning 
3. Aggregating results into a unified security report 
4. Implementing severity-based filtering and prioritisation 
5. Integrating with security information and event management (SIEM) systems

Security considerations

When building a security testing tool, the team had to address several meta-security considerations. 

Preventing denial of service

Running aggressive scans against production systems could potentially trigger denial of service conditions. To mitigate this risk: 

• The tool was deliberately limited to non-production environments 

• Rate limiting was implemented within the OWASP ZAP configuration 

• Scan intensity parameters could be adjusted based on the target system's robustness 

Permissions and access control

The security scanning tool itself could become a security risk if improperly accessed. The team implemented tight access controls: 

• Azure RBAC (Role-Based Access Control) restricted pipeline access to authorised users 

• Scan results were protected with appropriate classification levels 

• All operations were logged for audit purposes 

Container security

The containerised nature of the solution introduced its own security considerations: 

• Base container images were regularly updated to address vulnerabilities 

• Containers ran with minimal required privileges 

• Network access was tightly controlled through Azure's networking features 

Measuring success

Metrics and outcomes 

The security scanning solution delivered several quantifiable benefits.

Technical lessons learned 

For organisations looking to implement similar security automation solutions, here are our technical insights: 

1. Containerisation is key
   "The containerised approach provides perfect isolation and resource efficiency. You're only paying for compute during the actual scan."
2. Template everything
   "By templatising the scanning pipeline, we reduced the barrier to entry for teams wanting to improve their security posture."
3. Start small, then expand
   "We proved the concept with simple, single-endpoint scans before building out the multi-endpoint capability. This iterative approach ensured we were building on a solid foundation."
4. Integrate with existing workflows
   "The solution works within developers' existing pipelines rather than forcing them to adopt new tools or processes."

Building internal security tools doesn't always require significant investment or commercial products. With thoughtful architecture and modern cloud services, organisations can create effective, scalable security testing capabilities that deliver enterprise-grade results at a fraction of the cost. 

The OWASP ZAP implementation described here demonstrates how pragmatic engineering can solve complex security challenges while maintaining the agility that modern development teams require. By combining open-source tools with cloud-native architecture, the team created a solution that scales with the organisation's needs while encouraging a security-first mindset across development teams. 

This article is part of a series examining DevOps solutions delivered by Pwrteams-built teams. Don't miss our related pieces on Azure Cost Optimisation and Front Door Consolidation from the same technical team. 

FAQ