debian-mirror-gitlab/doc/user/application_security/get-started-security.md

stage	group	info
DevSecOps	Technical writing	To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments

Get started with GitLab application security (ULTIMATE)

For an overview, see Adopting GitLab application security.

The following steps will 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.

1. 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 your default branch. This creates a baseline scan of your default 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 will 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.

2. Let your team get comfortable with vulnerability reports and establish a vulnerability triage workflow.

3. 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.

4. Use scheduled pipelines to regularly scan important branches such as default or those used for maintenance releases.

   • Running regular dependency and container scans will 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.

5. Create a scan result policy to limit new vulnerabilities from being merged into your default branch.

6. Monitor the Security Dashboard trends to gauge success in remediating existing vulnerabilities and preventing the introduction of new ones.

7. Enable other scan types such as SAST, DAST, Fuzz testing, or Container Scanning.

8. Use Compliance Pipelines or Scan Execution Policies to enforce required scan types and ensure separation of duties between security and engineering.

9. Consider enabling Review Apps to allow for DAST and Web API fuzzing on ephemeral test environments.

10. Enable operational container scanning to scan container images in your production cluster for security vulnerabilities.