doc/user/application_security/get-started-security.md
Identify and remediate vulnerabilities in your application's source code. Integrate security testing into the software development lifecycle by automatically scanning your code for potential security issues.
You can scan various programming languages and frameworks, and detect vulnerabilities like SQL injection, cross-site scripting (XSS), and insecure dependencies. The results of the security scans are displayed in the GitLab UI, where you can review and address them.
These features can also be integrated with other GitLab features like merge requests and pipelines to ensure that security is a priority throughout the development process.
<i class="fa-youtube-play" aria-hidden="true"></i> For an overview, see Adopting GitLab application security
<i class="fa-youtube-play" aria-hidden="true"></i> View an interactive reading and how-to demo playlist
This process is part of a larger workflow:
Secret detection scans your repository to help prevent your secrets from being exposed. It works with all programming languages.
Dependency scanning analyzes your application's dependencies for known vulnerabilities. It works with certain languages and package managers.
For more information, see:
If it's your first time setting up GitLab security scanning, you should start with a single project. The project should:
To identify leaked secrets and vulnerable packages in the project, create a merge request that enables secret detection and dependency scanning.
This merge request updates your .gitlab-ci.yml file, so that the scans
run as part of your project's CI/CD pipeline.
As part of this MR, you can change settings to accommodate your project's layout or configuration. For example, you might exclude a directory of third-party code.
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. Then, merge requests will highlight any 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.
For more information, see:
Let your team get comfortable with viewing security findings in merge requests and the vulnerability report.
Establish a vulnerability triage workflow. Consider creating labels and issue boards to help manage issues created from vulnerabilities. With issue boards, all stakeholders have a common view of all issues and can track remediation progress.
Monitor the Security Dashboard trends to gauge success in remediating existing vulnerabilities and preventing the introduction of new ones.
For more information, see:
Enforce scheduled security scanning jobs by using a scan execution policy.
These scheduled jobs run independently from any other security scans you
might have defined in a compliance framework pipeline or in the project's .gitlab-ci.yml file.
Scheduled scans are most useful for projects or important branches with low development activity and where pipeline scans are infrequent.
For more information, see:
To enforce required scan types and ensure separation of duties between security and engineering, use scan execution policies.
To limit new vulnerabilities from being merged into your default branch, create a merge request approval policy.
After you've gotten familiar with how scanning works, you can then choose to:
For more information, see:
Over time, you want to ensure new vulnerabilities are not introduced.
For more information, see: