doc/user/application_security/detect/roll_out_security_scanning.md
Plan your application security testing implementation in phases to ensure a smooth transition to a more secure development practice.
This guide helps you implement GitLab application security testing across your organization in phases. By starting with a pilot group and gradually expanding coverage, you can minimize disruption while maximizing security benefits. The phased approach allows your team to become familiar with application security testing tools and workflows before scaling to all projects.
Prerequisites:
This guide covers how to plan and execute a phased implementation of GitLab application security testing features, including configuration, vulnerability management, and prevention strategies. It assumes you want to gradually introduce application security testing to minimize disruption to existing workflows while securing your codebase.
The implementation consists of two main phases:
The pilot phase allows you to apply application security testing with minimal risk before a wider rollout.
Consider the following guidance before starting on the pilot phase:
The pilot phase helps you achieve several key objectives:
Implement application security testing without slowing development
During the pilot, application security testing results are available to developers in the UI, without blocking merge requests. This approach minimizes risk to projects outside the pilot's scope while collecting valuable data on your current security posture. In the rollout phase you should use a merge request approval policy to add an additional approval gate when vulnerabilities are detected in merge requests.
Establish scalable detection methods
Implement application security testing on pilot projects in a way that can be expanded to include all projects in the wider rollout scope. Focus on configurations that scale well and can be standardized across projects.
Test scan times
Test scan times on representative codebases and applications.
Simulate the vulnerability remediation workflow
Simulate detecting, triaging, analyzing, and remediating vulnerabilities in the developer workflows. Verify that engineers can act on findings.
Compare maintenance costs
Compare the maintenance of a single solution versus integrating multiple endpoint solutions. How well does this integrate into the IDE, merge request, and pipeline?
Developers in the pilot group will gain:
Security team members participating in the pilot will gain:
Proper planning ensures an effective pilot phase.
Define who is responsible for:
Carefully select which projects to include in the pilot phase.
Consider these factors when selecting pilot projects:
Introduce security application security testing in the following order. This balances value and ease of deployment.
With planning complete, begin implementing application security testing of your pilot projects.
Prerequisites:
For each project in scope:
For more details, see Security configuration.
Introduce developers to the tools that provide visibility into security findings.
Developers can view security findings directly in pipeline results.
Prerequisites:
To view pipeline results:
For more details, see View security scan results in pipelines.
The security widget provides visibility into vulnerabilities detected in merge request pipelines.
Prerequisites:
To view the security widget:
For more details, see View security scan results in merge requests.
Developers can view security findings directly in their IDE.
Prerequisites:
To view security findings in VS Code:
For more details, see GitLab for VS Code extension.
Establish a structured workflow for handling detected vulnerabilities.
The vulnerability management workflow consists of four key stages:
GitLab provides several features to streamline vulnerability triage:
For more details, see Triage.
Triage should include regular reviews of the vulnerability report with security stakeholders.
Streamline the remediation process with these GitLab features:
For more details, see Remediate.
You can use a GitLab issue to track the remediation work required for a vulnerability. Alternatively, you can use a Jira issue if that is your primary ticketing system.
For more details, see Linking a vulnerability to GitLab and Jira issues.
Implement features to prevent vulnerabilities from being introduced in the first place.
Use a merge request approval policy to add an extra approval requirement if the number and severity of vulnerabilities in a merge request exceeds a specific threshold. This allows an extra review from a member of the application security team, providing an extra level of scrutiny.
Prerequisites:
manage_security_policy_link permission.To configure approval policies to require security reviews:
For more details, see Security approvals in merge requests.
After a successful pilot, expand application security testing to all target projects.
Before starting on the rollout phase consider the following:
Application security testing tasks require specific roles or permissions. For each person taking part in the rollout phases, define their access according to the tasks they'll be performing.
admin_vulnerability permission can manage and triage
vulnerabilities.manage_security_policy_link permission can enforce policies
on groups and projects.For more details, see Roles and permissions.
The rollout phase aims to implement application security testing across all projects in scope, using the knowledge and experience gained during the pilot.
Review and update roles and responsibilities established during the pilot. The same team structure should work for the rollout, but you may need to add more team members as the scope expands.
Use policy features to efficiently scale your security implementation.
Use policy inheritance to maximize effectiveness while also minimizing the number of policies to be managed.
Consider the scenario in which you have a top-level group named Finance which contains subgroups A, B, and C. You want to run dependency scanning and secret detection on all projects in the Finance group. For each subgroup you want to run different sets of application security testing tools.
To achieve this goal, you could define 3 policies for the Finance group:
Only a single set of policies needs to be maintained but still provides the flexibility to suit the needs of different projects.
For more details, see Enforcement.
Implement consistent application security testing across multiple projects by using scan execution policies.
Prerequisites:
manage_security_policy_link permission, for
the groups in which application security testing is to be enabled.For more details, see Security policies.
Scale the rollout gradually, first to the pilot projects and incrementally to all target projects. When applying policies to all groups and projects, create awareness to all project stakeholders as this can impact changes in pipelines and merge request workflows. For example, notify stakeholders
Implement your security policies in phases:
For more details, see the policy design guidelines.