Reorganize existing Secure features documentation
### Problem to solve
Documentation for Secure features is suboptimal and not easy to find/consume. For example, the reports are only mentioned in the merge request documentation, but it also mentions the pipeline view report.
We should also add use cases and complete flows how to use those features.
### Proposal
Reconsider documentation for Secure features in a holistic way and make it a first class entry in our documentation website.
We'll move all the Secure docs under the same roof `doc/user/security/`.
<details>
<summary>Directory structure before and after.</summary>
**Before**
```
├── ci
| ├── examples
| ├── code_climate.md
| ├── code_quality.md
| ├── container_scanning.md
| ├── dast.md
| ├── dependency_scanning.md
| ├── license_management.md
| ├── sast.md
| ├── sast_docker.md
├── user
| ├── group
| ├── security_dashboard.md
| ├── project
| ├── merge_requests
| │ ├── code_quality.md
| │ ├── code_quality_diff.md
| │ ├── container_scanning.md
| │ ├── dast.md
| │ ├── dependency_scanning.md
| │ ├── license_management.md
| │ ├── sast.md
| │ ├── sast_docker.md
| ├── security_dashboard.md
```
**After**
```
├── user
| ├── security
| | ├── container_scanning/index.md
| | ├── dast/index.md
| | ├── dependency_scanning/index.md
| | ├── index.md
| | ├── license_management/index.md
| | ├── sast/index.md
| | └── security_dashboard/index.md
```
</details>
### What does success look like, and how can we measure that?
People will find documentation useful :)
## Todo list
The plan is to first copy all Secure documentation under the new roof, and then redirect the old docs to the new ones.
### Phase one
Copy existing docs to their new location (check once an MR is ready):
1. [x] **Container scanning** https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/10649
1. [x] **Dependency scanning** https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/10724
1. [x] **DAST** https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/10712
1. [x] **License Management** https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/10732
1. [x] **SAST** https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/10623
1. [x] **Security dashboard** https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/10797
1. [x] **General content** `user/project/merge_requests/#interacting-with-security-reports-ultimate` > `doc/user/security/index.md` https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/10797
<details>
<summary>All pages should have the following structure</summary>
````md
## Overview
If you are using [GitLab CI/CD](../../../ci/README.md), you can analyze your source code for known
vulnerabilities using Static Application Security Testing (NAME).
You can take advantage of NAME by either [including the CI job](#configuration) in
your existing `.gitlab-ci.yml` file or by implicitly using
[Auto NAME](../../../topics/autodevops/index.md#auto-sast-ultimate)
that is provided by [Auto DevOps](../../../topics/autodevops/index.md).
GitLab checks the NAME report, compares the found vulnerabilities between the
source and target branches, and shows the information right on the merge request.
## Use cases
## Requirements
To run a NAME job, you need GitLab Runner with the
[`docker`](https://docs.gitlab.com/runner/executors/docker.html#use-docker-in-docker-with-privileged-mode) or
[`kubernetes`](https://docs.gitlab.com/runner/install/kubernetes.html#running-privileged-containers-for-the-runners)
executor running in privileged mode. If you're using the shared Runners on GitLab.com,
this is enabled by default.
## Configuring NAME
To enable NAME in your project, you need to define a job in your `.gitlab-ci.yml` file that generates the
[NAME report artifact](../../../ci/yaml/README.md#artifactsreportssast-ultimate).
This can be done in two ways:
- Including the provided NAME `.gitlab-ci.yml` template (recommended)
- Manually specifying the job definition
### Including the provided template
NOTE: **Note:**
The CI/CD NAME template is supported on GitLab 11.9 and later versions.
For earlier versions, use the [manual job definition](#manual-job-definition).
A CI/CD [NAME template](https://gitlab.com/gitlab-org/gitlab-ee/blob/master/lib/gitlab/ci/templates/Security/NAME.gitlab-ci.yml)
with the default NAME job definition is provided as a part of your GitLab
installation which you can [include](../../../ci/yaml/README.md#includetemplate)
in your `.gitlab-ci.yml` file.
To enable NAME, add a new job to `.gitlab-ci.yml` by including the NAME template:
```yaml
include:
template: NAME.gitlab-ci.yml
```
The above example will create a `sast` job in your CI/CD pipeline
and scan your project's source code for possible vulnerabilities. The report will be saved as a
[NAME report artifact](../../../ci/yaml/README.md#artifactsreportssast-ultimate)
that you can later download and analyze.
Due to implementation limitations we always take the latest NAME artifact available.
Behind the scenes, the [GitLab SAST Docker image](https://gitlab.com/gitlab-org/security-products/sast)
is used to detect the languages/frameworks and in turn runs the matching scan tools.
#### Customizing the NAME settings
#### Overriding the NAME template
If you want to override the job definition (for example, change properties like
`variables` or `dependencies`), you need to declare a `dependency_scanning` job
after the template inclusion and specify any additional keys under it. For example:
### Manual job definition for GitLab 11.5 and later
CAUTION: **Caution:**
The job definition shown below is supported on GitLab 11.5 and later versions.
However, if you're using GitLab 11.9+, it's recommended to use
[the provided NAME template](#including-the-provided-template).
GitLab Runner 11.5 or later is also required. For earlier versions, you can use
the [deprecated job definition](#deprecated-job-definition).
If you are using GitLab prior to 11.9, you can define the NAME job manually in
your `.gitlab-ci.yml`:
### Manual job definition for GitLab 11.4 and earlier (deprecated)
CAUTION: **Deprecated:**
Before GitLab 11.5, the NAME job and artifact had to be named specifically
to automatically extract report data and show it in the merge request widget.
While these old job definitions are still maintained, they have been deprecated
and may be removed in the next major release, GitLab 12.0. You are strongly
advised to update your current `.gitlab-ci.yml` configuration to reflect that change.
For GitLab 11.4 and earlier, the job should look like:
````
</details>
### Phase two
- [x] Add redirects and deprecate old docs https://gitlab.com/gitlab-org/gitlab-ee/issues/11109
epic