Across the industry, every CI/CD platform faces the same challenge: As organizations grow, manually configuring scanners to run across every pipeline definition file isn't scalable. AI is accelerating how fast teams ship code, and with this comes more projects, more pipelines, and more surface area to secure. What starts as a deliberate security decision becomes inherited configuration that nobody owns, coverage that was never backfilled, and gaps that are invisible until they aren't.
Security teams need to apply scanners at scale, not chase scanner coverage project by project with manual YAML files. A security configuration profile is a centralized setting in the UI where security teams can define how and when security scanners run across your projects, without manually configuring scanners across pipeline definition files. With GitLab 19.0, teams can use security configuration profiles to enable static application security testing (SAST), dependency scanning, and secret detection scanners across every project from day one.
Watch this video demonstration of security configuration profiles and then read more below.
At a small scale, manually enabling scanner configuration per project is workable. One team, a handful of repositories, a security engineer who knows where everything lives. The model gets harder to maintain as organizations add teams and projects, and AI is making the gap between code velocity and security coverage wider every day.
The drift shows up in common ways. Teams copy scanner configuration from whatever source is handy, so SAST ends up running with one ruleset in the backend service and another in the frontend. Dependency scanning gets added to new projects but never backfilled to older ones. Someone updates a .gitlab-ci.yml file to fix a pipeline issue and a scanner gets dropped along the way.
Without a centralized view, individual decisions about scanner coverage rarely add up to a consistent security posture across an organization.
A security configuration profile is a centralized group of settings that defines how and when a security scanner runs across your projects. Instead of configuring SAST, secret detection, or dependency scanning individually in each project's .gitlab-ci.yml, you define a profile once at the group level and apply it to as many projects as you need in one action.
GitLab ships default profiles for each scanner: preconfigured settings that reflect recommended practice, so you can get scanning running across your projects in minutes without writing a line of YAML. For full technical details, see the security configuration profiles documentation.
Each default profile activates a set of scan triggers that define when scanning runs. For SAST and dependency scanning, two triggers apply.
Merge request pipelines. A scan runs automatically each time new commits are pushed to a branch with an open merge request. Results are scoped to vulnerabilities introduced by that merge request, so developers get focused, actionable feedback without noise from pre-existing issues.
Branch pipelines (default branch only). A scan runs automatically when changes are merged or pushed to the default branch, giving your security team a complete picture of your default branch's security posture at all times.
Secret detection includes both of those triggers and adds a third: push protection. Rather than waiting for a pipeline to run, push protection intercepts secrets in real time during the git push process and blocks the push before the secret ever enters your codebase. Because it's event-based rather than pipeline-based, there's no scan date attached to it in the security inventory.
Here are four real-world scenarios where security configuration profiles can be impactful.
Standardizing coverage across a large group
A platform security team manages hundreds of projects spread across dozens of subgroups. The security inventory gives them a single view of scanner coverage across every project, including which are running SAST, which aren't, and which have failed scans. From that dashboard, the team selects all projects and applies the default profiles in a bulk action. Every project now runs SAST, secret detection, and dependency scanning on merge request and branch pipelines, without a single .gitlab-ci.yml edit.
Catching a code-level vulnerability before it ships
A developer on a fast-moving team introduces an insecure deserialization pattern while building a new API endpoint. It's not malicious, just a mistake made under time pressure. With the SAST profile applied, a scan runs automatically when the team pushes commits to their merge request branch. The vulnerability is flagged before the merge request is approved, when it takes one developer an hour to fix rather than days of incident response after the fact.
Catching a compromised dependency before it reaches production
A developer updates a dependency in their lockfile. The new version of a widely-used package has been compromised and carries a malicious payload. Dependency scanning runs automatically on the merge request pipeline and flags the compromised version before the branch is merged. The developer is notified at the point of the change, not after the package has been installed across build servers and production environments.
Catching secrets before they land
A developer accidentally includes an API key in a commit while debugging a pipeline issue. It's a common mistake, and on a busy team it can go unnoticed for days. With the secret detection profile applied, push protection intercepts the push in real time and blocks it before the secret reaches the repository. The developer gets immediate feedback at the point of the mistake, with no security report, no incident ticket, and no credential rotation required.
Security configuration profiles are now available on GitLab Ultimate for GitLab.com, GitLab Self-Managed, and GitLab Dedicated instances. To apply default profiles across your projects:
To review coverage status after applying profiles, return to the security inventory and check the Tool Coverage column. A solid green bar indicates the scanner is fully active. A partial bar means some triggers are active but others are not. A gray bar means the scanner is not yet configured.
To view the full technical details of any profile, including its scan triggers and current status, select the profile name from the security inventory.
If your projects have existing scanner configuration in .gitlab-ci.yml, note that profile-based configuration and legacy configuration can coexist, but the security inventory tooltip may not reflect the combined status accurately during the transition. For the most accurate view of your current profile state, check the Security Configuration page for the individual project. For more, see the security configuration profiles documentation.
Not yet on GitLab Ultimate? Start a free trial and get SAST, secret detection, and dependency scanning running across your projects in minutes.
What is a security configuration profile?
A security configuration profile is a centralized set of settings that defines how and when a security scanner runs across your projects. Instead of configuring scanners manually in each project's .gitlab-ci.yml, you apply a profile once and it covers every project in the group.
Which scanners have default profiles in GitLab 19.0?
GitLab 19.0 completes the first set of default profiles, adding dependency scanning alongside the secret detection profile (expanding since 18.9) and the SAST profile introduced in 18.11. Each profile activates a recommended set of scan triggers with no manual configuration required.
What scan triggers does each profile activate?
The secret detection profile activates three triggers: push protection, merge request pipelines, and branch pipelines targeting the default branch. The SAST and dependency scanning profiles activate two triggers: merge request pipelines and branch pipelines targeting the default branch.
Do profiles replace my existing .gitlab-ci.yml scanner configuration?
Not automatically. Profile-based and legacy configurations can coexist. If you want to rely solely on profile-based configuration, remove the relevant scanner configuration from your .gitlab-ci.yml files. The Security Configuration page for each project reflects the most accurate current state during any transition.
What GitLab tier is required?
Security configuration profiles are available on GitLab Ultimate, across GitLab.com, GitLab Self-Managed, and GitLab Dedicated instances.
Can I apply a profile to individual projects rather than an entire group?
Yes. From the security inventory, you can manage scanner coverage for individual projects by selecting the vertical ellipsis next to the project and choosing Manage tool coverage.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。