## Why Get Rid of Docker-in-Docker Almost all of our [Security Products](https://docs.gitlab.com/ee/user/project/merge_requests/#security-reports-ultimate) require privileged runners, with the [docker-in-docker executor](https://docs.gitlab.com/runner/executors/docker.html#use-docker-in-docker-with-privileged-mode). 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 gitlab-ee~3712019 and gitlab-ee~6703392. 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. Note: License Management is not involved in this discussion, as it doesn't require dind. ## Possible Approaches 1. Improve the CI configuration with files detection - [discussion](https://gitlab.com/groups/gitlab-org/-/epics/971#note_213540344) 2. ~~Improve the CI configuration with changes detection - [discussion](https://gitlab.com/groups/gitlab-org/-/epics/971#note_213540535)~~ 3. ~~Set up a detection job that writes files based on the languages of the repository and then run individual analyzers/scanners based on those files - [discussion](https://gitlab.com/groups/gitlab-org/-/epics/971#note_213540769)~~ 4. Set up a detection job that sets a variable based on the languages of the repository and then run individual analyzers/scanners based on that variable - [discussion](https://gitlab.com/groups/gitlab-org/-/epics/971#note_213541000) 5. ~~Change the SAST and Dependency Scanning jobs so that they kick off new pipelines - [discussion](https://gitlab.com/groups/gitlab-org/-/epics/971#note_213541157)~~ 6. ~~Run every analyzer, knowing that the analyzers that are not applicable to the repository will fail (quickly) - [discussion](https://gitlab.com/groups/gitlab-org/-/epics/971#note_213548849)~~ 7. ~~Feedback loop, make jobs disable themselves - [discussion](https://gitlab.com/groups/gitlab-org/-/epics/971#note_214564573)~~ Approaches updated to indicate which approaches we are no longer currently considering in any form. We have implemented approach 4. with https://gitlab.com/gitlab-org/gitlab/merge_requests/16487 for SAST. Now that https://gitlab.com/gitlab-org/gitlab/issues/24021 has landed with https://gitlab.com/gitlab-org/gitlab/merge_requests/16574, we can move forward with approach 1. for both SAST and Dependency Scanning.