### Problem to solve Requiring Docker-in-Docker (DinD) for security scanners causes [security, performance and setup concerns](https://gitlab.com/groups/gitlab-org/-/epics/971#why-get-rid-of-docker-in-docker) for many users. DinD is only required to be able to orchestrate the analyzers. One solution would be to port the code of the sast orchestrator directly into the runner. NB: SAST and Dependency scanning share a common library and the same orchestration model, [see Dependency Scanning issue](https://gitlab.com/gitlab-org/gitlab-ee/issues/12487) See https://gitlab.com/groups/gitlab-org/-/epics/971 for previous comments. ### Intended users - ~"Persona: DevOps Engineer" - ~"Persona: Software developer" ### Proposal As describe [here](https://gitlab.com/groups/gitlab-org/-/epics/971#note_155680650): Ideally, https://gitlab.com/gitlab-org/gitlab-ee/blob/master/lib/gitlab/ci/templates/Security/SAST.gitlab-ci.yml would just contain: ```yaml include: template: SAST-bandit.gitlab-ci.yml template: SAST-brakeman.gitlab-ci.yml template: SAST-gosec.gitlab-ci.yml [...] ``` So that we have only one SSOT and one single location to update for analyzers. Users who want to use specific analyzers can use the one-liner `include` directly. ### Tasks * [ ] Decide what to do with some variables not being used anymore, like https://gitlab.com/gitlab-org/security-products/sast#timeouts * [x] Port the report aggregation to the Rails backend (currently done in [common](https://gitlab.com/gitlab-org/security-products/analyzers/common); ported by #10857) * [x] Port the vulnerabilities deduplication to the Rails backend (currently done in [common](https://gitlab.com/gitlab-org/security-products/analyzers/common); ported by #10857) * [x] Port other features like "ignore paths" to the Rails backend (currently done in [common](https://gitlab.com/gitlab-org/security-products/analyzers/common) (refs #10030) * [ ] Explore improving the CI configuration with files detection https://gitlab.com/groups/gitlab-org/-/epics/971#note_200189550 * [ ] Decide on a plan for deprecating, and ultimately archiving the existing [SAST](https://gitlab.com/gitlab-org/security-products/sast) tool https://gitlab.com/groups/gitlab-org/-/epics/971#note_211694279 * [ ] Update the vendored templates * [ ] Update the documentation ### Documentation - [ ] Update https://docs.gitlab.com/ee/user/application_security/sast/index.html ### Testing - [ ] Update all related tests projects in https://gitlab.com/gitlab-org/security-products/tests ### What does success look like, and how can we measure that? There is no more orchestration layer for SAST, instead each analyzer has its own job configured by the corresponding vendored template. ### What is the type of buyer? ~"GitLab Ultimate" ### Links / references