DAST scanning for about.gitlab.com

I have opened this issue coming from this discussion, https://gitlab.slack.com/archives/C0AR2KW4B/p1542808300926200.

@rebecca complained that:

DAST on www-gitlab-com again taking ~37 mins, entire pipeline over 1 hour total :crying:

And I must say that I agree, because DAST essentially takes longer than the rest of the entire pipeline. The biggest problem to me is, that this long running pipeline disproportionally affects people "who do not care" about DAST, they just want their content published in the handbook/blog, that is static 99.99% and most changes just affect one single page.

I don't know what @gitlab-com/gl-security thinks about the actual impact/usefulness of our DAST scanning on about.gitlab.com, but @dappelt voiced that it might not make sense for static web pages.

Solution approach

To be frank: DAST did not work properly, probably for weeks, if not even months, until I have fixed it with 9c605106. Nobody bat an eye or even found out it didn't work. Now it works, but it actively hinders people from their work efficiently and it wastes resources without adding too much value. So I'd say, we should disable the job completely (for now), until we can speed up the execution time.

Maybe as a compromise we could add a job, that only runs once a day or so with scheduled CI jobs. I know that this is not ideal, and that we should tanuki-feed our own software and it's features, but until we have gone and improved things this seems like a good compromise.