Get started with GitLab application security
For an overview, see Adopting GitLab application security. For an interactive reading and how-to demo playlist, see Get Started With GitLab Application Security Playlist
The following steps help you get the most from GitLab application security tools. These steps are a recommended order of operations. You can choose to implement capabilities in a different order or omit features that do not apply to your specific needs.
-
Enable Secret Detection and Dependency Scanning to identify any leaked secrets and vulnerable packages in your codebase.
- For all security scanners, enable them by updating your
.gitlab-ci.yml
directly on yourdefault
branch. This creates a baseline scan of yourdefault
branch, which is necessary for feature branch scans to be compared against. This allows merge requests to display only newly-introduced vulnerabilities. Otherwise, merge requests display every vulnerability in the branch, regardless of whether it was introduced by a change in the branch. - If you are after simplicity, enable only Secret Detection first. It only has one analyzer, no build requirements, and relatively simple findings: is this a secret or not?
- It is good practice to enable Dependency Scanning early so you can start identifying existing vulnerable packages in your codebase.
- For all security scanners, enable them by updating your
- Let your team get comfortable with vulnerability reports and establish a vulnerability triage workflow.
- Consider creating labels and issue boards to help manage issues created from vulnerabilities. Issue boards allow all stakeholders to have a common view of all issues and track remediation progress.
- Enforce scheduled security scanning jobs by using a scan execution policy.
- These scheduled jobs run independently from any other security scans you may have defined in a compliance framework pipeline or in the project’s
.gitlab-ci.yml
file. - Running regular dependency and container scans surface newly-discovered vulnerabilities that already exist in your repository.
- Scheduled scans are most useful for projects or important branches with low development activity where pipeline scans are infrequent.
- These scheduled jobs run independently from any other security scans you may have defined in a compliance framework pipeline or in the project’s
- Create a scan result policy to limit new vulnerabilities from being merged
into your
default
branch. - Monitor the Security Dashboard trends to gauge success in remediating existing vulnerabilities and preventing the introduction of new ones.
- Enable other scan types such as SAST, DAST, Fuzz testing, or Container Scanning.
- Use Compliance Pipelines or Scan Execution Policies to enforce required scan types and ensure separation of duties between security and engineering.
- Consider enabling Review Apps to allow for DAST and Web API fuzzing on ephemeral test environments.
- Enable operational container scanning to scan container images in your production cluster for security vulnerabilities.