In this blog I’m going to build on my previous posts on agile security, DevSecOps culture and managing vulnerabilities in open source libraries to talk about automating application security testing.
The Open Web Application Security Project (OWASP) regularly publishes their top 10 web application security risks, covering example attack scenarios and mitigation strategies. Injection flaws, cross-site scripting and broken authentication never fail to make the list.
Security teams traditionally addressed these vulnerabilities through regular, often manual, application security testing. They then analyse these scan reports and communicated the issues to the engineers requesting a fix. Although this method still has its use, agile software development and associated drive to deliver working software quickly might introduce tension between security and development teams. Manual scans take time and critical vulnerabilities can stay unpatched in production systems for weeks if not months waiting to be prioritised.
A strong DevSecOps culture can bring these teams closer together but traditional approaches to application security testing have to be adapted to fit in. Drawn-out monthly security scans with a multitude of false positives will only irritate your developers, while cutting corners doesn’t fair well with security specialists.
Conducting security tests in the CI/CD pipeline removes the special standing of vulnerability scanning and brings it closer to the familiar unit and integration tests, bridging the gap between development and security. The aim is to detect security issues in the pipeline rather than checking for them in production later.
The OWASP Zed Attack Proxy (ZAP) has a handy baseline scan feature that can help address this challenge. The tool is open source and is also available as a Docker container. It has other advanced functionality, including fuzzing and beyond but here we will focus on the baseline scan for basic security controls only. The main reason for this is speed. Developers need quick feedback and the baseline scan can usually run in less than a minute. It’s also non-intrusive so shouldn’t disrupt the workflow too much.
When integrating ZAP in the CI/CD workflow, the CI platform will retrieve the ZAP Docker container to run it agains the application container. The CI platform will then either approve or reject the change depending on the output of the scan.
So when you run the following command (with your own URL):
docker run owasp/zap2docker-weekly zap-baseline.py -t https://myexampleapp.com
you would expect to see an output like this:
Security alerts appear as warning by default and you can change pass and fail conditions in the config file. ZAP’s baseline scan is highly configurable and I encourage to check out its GitHub page for more details.