Get started with GitLab application security

DETAILS: Tier: Ultimate Offering: SaaS, Self-managed

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 introduce you to GitLab application security tools incrementally. You can choose to enable features in a different order, or skip features that don't apply to your specific needs. You should start with:

• Secret Detection, which works with all programming languages and creates understandable results.
• Dependency Scanning, which finds known vulnerabilities in the dependencies your code uses.

If it's your first time setting up GitLab security scanning, you should start with a single project. After you've gotten familiar with how scanning works, you can then choose to:

• Follow the same steps to enable scanning in more projects.
• Enforce scanning across more of your projects at once.

Recommended steps

1. Choose a project to enable and test security features. Consider choosing a project:
   • That uses your organization's typical programming languages and technologies, because some scanning features work differently across languages.
   • Where you can try out new settings, like required approvals, without interrupting your team's daily work. You could create a copy of a higher-traffic project for testing, or select a project that's not as busy.
2. Create a merge request to enable Secret Detection and enable Dependency Scanning to identify any leaked secrets and vulnerable packages in that project.
   • Security scanners run in your project's CI/CD pipelines. Creating a merge request to update your .gitlab-ci.yml helps you check how the scanners work with your project before they start running in every pipeline. In the merge request, you can change relevant Secret Detection settings or Dependency Scanning settings to accommodate your project's layout or configuration. For example, you might choose to exclude a directory of third-party code from scanning.
   • After you merge this MR to your default branch, the system creates a baseline scan. This scan identifies which vulnerabilities already exist on the default branch so merge requests can highlight only newly-introduced problems. Without a baseline scan, merge requests display every vulnerability in the branch, even if the vulnerability already exists on the default branch.
3. Let your team get comfortable with viewing security findings in merge requests and the vulnerability report.
4. 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.
5. Monitor the Security Dashboard trends to gauge success in remediating existing vulnerabilities and preventing the introduction of new ones.
6. 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.
7. Create a merge request approval policy to limit new vulnerabilities from being merged into your default branch.
8. Enable other scan types such as SAST, DAST, Fuzz testing, or Container Scanning.
9. Use Compliance Pipelines or Scan Execution Policies to enforce required scan types and ensure separation of duties between security and engineering.
10. Consider enabling Review Apps to allow for DAST and Web API fuzzing on ephemeral test environments.
11. Enable operational container scanning to scan container images in your production cluster for security vulnerabilities.