Advice when using Zap in CI

[Robin M]

We are integrating Zap in CI running scans against candidate releases on TeamCity. Our process is

- Seed Zap using Selenium/FF

- Spider with Zap

- Ascan site root with Zap

- Publish report and fail the build if new alert count is higher than previous alert count

The active scan currently takes a very long time (> 5 hours) when pointed at the root node, so the agent running the build will be occupied for that time, making Zap difficult to use in CI.

I have tried the things suggested here https://blog.mozilla.org/security/2013/07/10/how-to-speed-up-owasp-zap-scans/ however scan time is still an issue.

There are roughly 50 subnodes detected by Selenium in the initial seeding, is this likely to increase scan time dramatically? We have not yet tweaked the scanner rules, so this maybe the next thing to look at. Any other advice for reducing the active scan time?

[Simon Bennetts]

Unfortunately by its very nature automated scanning of web apps takes a significant amount of time.
We're trying to test apps as thoroughly as possible, that means we have to send a lot of requests.

The blog post you pointed to is still a good starting point, but there are some more recent changes that may help.

If you know what technology your app uses (and hopefully you do;) then define a context for your app and define the tech it uses: https://github.com/zaproxy/zap-core-help/wiki/HelpUiDialogsSessionContexts#technology
Tests that are specific to a tech that you dont use will not be run.
Theres no point looking for LDAP issues if you're not using LDAP :)

Does you app have any data driven content?
If so then you can now configure ZAP to understand it: https://github.com/zaproxy/zap-core-help/wiki/HelpStartConceptsDdc

We also have statistics which show how long each of the scan rules took.
You can see this displayed in out wavsep tests. eg http://zapbot.github.io/zap-mgmt-scripts/reports/wavsep-1.5-weekly-All-M-M.html - the pie charts and table towards the end of the file.

How are you seeding with Senenium - is this using the ZAP Ajax Spider or your own regressions tests?
And how many nodes does the traditional spider find?

If you want a quick scan then try the ZAP Baseline scan: https://github.com/zaproxy/zaproxy/wiki/ZAP-Baseline-Scan
This only spiders for minutes (by default 1) and only does passive scanning.
Obviously it will find less problems that the scan you are currently performing.

Cheers,

Simon

[Robin M]

We are using Selenium to login and browse the site in order to populate the tree in Zap, which seems the best approach to teach Zap about the website, and to authenticate requests. When using the Ajax spider the site seems to repeatedly make the same requests, so I have stuck with spider/ascan.

Regarding data driven nodes, few are found by the spider and I do not see instances being repeated, though I have marked a few in the context following your recommendation. Part of the difficulty of debugging this is the feedback loops are so long for each commit..

The traditional spider finds 405 uri's in total when scanning the base node, perhaps this is too many to run an ascan against in a single scan? We are really looking to gain assurance that a code change has not exposed new security issues, not whether each build is completely secure.

Robin

[kingthorin+owaspzap]

Do your selenium tests cover only the change?

[Robin M]

They perform a cursory browse of the site, which does not vary between scans. This way we hope to create a baseline, so any code change introducing new alerts could be identified.

Browsing too deeply with Selenium increases scan time dramatically, so we could potentially move to something that only drives zap towards the change made in the code. Does this sound reasonable?