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 20
call, and instead use the providedstatus
flag/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_URL
in 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
alerts
command 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
- risk
- CWE ID (Common Weakness Enumeration)
- URL
- 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 mode
upon 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.
Thanks!
No comments yet
Post a comment