Since my third follow-up post on my Docker + OWASP ZAP-CLI + Jenkins work — most of which lies in my docker-zap GitHub repo, I’ve made both small and key improvements, which I’d like to highlight, here:
- fixed the hardcoded
sleep 20call, and instead use the provided
statusflag/state, so we only start running the ZAP-CLI when the daemon/API is ready (https://github.com/stephendonner/docker-zap/issues/1)
- instead of a statically-specified host in the shell script, we pass in a variable (with a default
TARGET_URLin the accompanying Jenkins job config, that is easily overridden by entering a new value in the build-job prompt (https://github.com/stephendonner/docker-zap/issues/4)
- I now use the provided
alertscommand to output a nice, easy-to-read table if there are found issues — complete with the following (https://github.com/stephendonner/docker-zap/issues/10):
- type of alert/issue
- CWE ID (Common Weakness Enumeration)
- because the aim in this particular instance’s use is to try to find Web-application vulnerabilities throughout development cycles (including post-release), I now invoke
ATTACK modeupon start-up of ZAP itself (https://github.com/stephendonner/docker-zap/issues/12)
- a minor addition, for clarity, is that I’ve added a separator between the ZAP-CLI’s output and the full, raw engine’s log (https://github.com/stephendonner/docker-zap/issues/13)
Here’s sample output: http://pastebin.com/bLmKkMws
And a high-level overview in my Docker-ZAP-CLI screencast.
I’m still anticipating wider adoption and integration of ZAP, whether that’s through my particular setup, or something else, so please feel free to contribute pull requests and ask/answer questions, etc., preferably through GitHub Issues.