Code Protection Without YAML: How GitLab Scales Scanning

As organizations grow, manual configuration of security scanners for each project becomes an unmanageable task. GitLab 19.0 offers a solution: security configuration profiles that allow you to enable SAST, dependency scanning, and secret detection with a single click across all projects simultaneously, without needing to edit YAML files.

Why manual configuration doesn't scale

At the early stage, manual configuration works fine: one team, several repositories, one security engineer who knows everything by heart. But as the number of teams and projects grows, the model begins to fall apart. AI accelerates development speed, but security coverage lags even faster.

Typical and painful problems emerge. Teams copy scanning configurations from anywhere: SAST in a backend service runs with one set of rules, while in the frontend it runs with completely different ones. Dependency scanning is added to new projects but forgotten in old ones.

Someone edits .gitlab-ci.yml to fix a pipeline error and accidentally deletes the security scanner — no one notices until an incident occurs.

Without centralized management, it's impossible to ensure that all projects follow the same security policy. The security team is forced to manually check each project and chase configurations instead of focusing on analyzing real vulnerabilities.

What are configuration profiles

A configuration profile is a set of rules and triggers that determine how and when security scanners are launched. Instead of manually configuring .gitlab-ci.yml in each project, you create a profile once at the group level and apply it to all projects with a single action. GitLab provides ready-made profiles for three types of scanners:

• SAST (Static Application Security Testing) — finding vulnerabilities in application source code
• Dependency scanning — detecting vulnerabilities in used libraries and packages
• Secret detection — intercepting API keys, passwords, and tokens before they reach the repository

Each profile contains verified, recommended settings that align with industry best practices. This means you can enable comprehensive security scanning in minutes without writing a single line of YAML and without deep knowledge of each scanner.

How scanning triggers work

Scanning is launched automatically in three scenarios. First: when creating a merge request. The scanner shows only new vulnerabilities that appeared in this code, so the developer focuses on their own errors rather than getting distracted by old issues that existed before their pull request.

Second scenario: when changes are merged into the main branch. Then the security team sees the full picture of the entire codebase's security state and can track the progress of improvements. Third: secret detection works in real time.

If a developer tries to push an API key or password, the push is blocked at the git level before the secret reaches the repository and commit history. This eliminates situations where secrets end up in public history and require costly rotation.

From zero to full coverage in a few clicks

To get started, the security team navigates to the Security inventory section of their group, selects all projects (or specific ones), and applies default profiles through the Bulk Actions menu. GitLab immediately shows coverage status: a green bar means the scanner is fully active, a partial bar means not all triggers are working, a gray bar means the scanner hasn't been set up yet. Ready-made profiles will start working immediately. The first scan will launch on the next merge request or push to the main branch.

What this means

Organizations no longer need to choose between development speed and security. Configuration profiles allow scaling both simultaneously: teams deploy new code faster, but with the guarantee that all projects undergo the same set of critical security checks. This is especially important in large organizations where development happens in parallel across dozens or hundreds of projects simultaneously.