Get rid of the Docker-in-Docker requirement for security products

Almost all of our Security Products require privileged runners, with the docker-in-docker executor. This is a security issue for a vast number of customers, and it limits the adoption of our security features. Not only docker-in-docker is problematic for the setup, but it also prevents the runners from caching the images. The content of the docker-in-docker container is lost after the job run, and only docker:stable is cached.

This issue is the starting point to discuss how we can get rid of this requirement.

First of all, it's necessary to remind why we're using dind: We are supporting a large variety of languages and frameworks for ~sast and ~"dependency scanning". It's easier and more efficient to isolate the different analyzers. SAST will behave as an orchestrator only, detecting the languages in the scanned project, and running the corresponding analyzers. That way, we don't download the Java stack when we scan a python project for example.

SAST & Dependency Scanning

Docker-in-docker is only required to be able to orchestrate the analyzers. One solution would be to port the code of the sast and dependency scanning orchestrator directly into the runner.

Most of the discussions will surely be about this section.

Container Scanning

The current job definition is only using dind because we have 2 linked containers: https://gitlab.com/gitlab-org/gitlab-ee/blob/master/lib/gitlab/ci/templates/Security/Container-Scanning.gitlab-ci.yml

I don't see any reason why we can't use a gitlab-runner service:

    - docker run -d --name db arminc/clair-db:latest
    - docker run -p 6060:6060 --link db:postgres -d --name clair --restart on-failure arminc/clair-local-scan:v2.0.6

The rest of the script can (and should) be in a Dockerfile to create a container_scanning image.

Update: unable to use arminc/clair-db:latest and arminc/clair-local-scan:v2.0.6 as services because current version of GitLab Runner does not link service containers to each other, details below.

DAST

DAST is only requiring dind since 11.9, and the introduction of the vendored templates: https://docs.gitlab.com/ee/ci/examples/dast.html#prerequisites

We can probably get rid of https://gitlab.com/gitlab-org/gitlab-ee/blob/master/lib/gitlab/ci/templates/Security/DAST.gitlab-ci.yml#L35 to pass the variables directly to the dast image.

License Management

is not involved in this discussion (placeholder to mention we didn't forget it).

/cc @bikebilly @twoodham