doc/user/application_security/configuration/security_configuration_profiles.md
{{< details >}}
{{< /details >}}
{{< history >}}
security_scan_profiles_feature. Enabled by default.security_scan_profiles_dependency_scanning. Enabled by default.security_remediation_profiles. Enabled by default.{{< /history >}}
[!flag] The availability of this feature is controlled by a feature flag. For more information, see the history.
Security configuration profiles are centralized settings that define how and when security scanners run across your projects. Use security configuration profiles to manage security scanners across your organization efficiently. A profile-based approach applies best practices with minimal manual setup.
<i class="fa-youtube-play" aria-hidden="true"></i> For an overview, see Introducing security configuration profiles.
When you apply a profile to a group, it is applied to each individual project within that group. Profiles are not attached to the group itself, and there is no inheritance between profiles or subgroups.
Use default profiles to enable pre-configured security scanning within minutes and with minimal configuration.
To assess and manage your profiles, use the security inventory for your group as your central dashboard.
To view a high-level status (Enabled, Not Enabled, or Failed) of scanners in the group like SAST, dependency scanning, and secret detection:
To configure a specific project:
To save time, you can apply security settings to multiple projects at once:
GitLab provides default profiles that are preconfigured scanner settings so you can enable security scanning with minimal configuration.
When you apply the secret detection profile, you enable the recommended baseline protection for secrets across your entire development workflow. The profile activates the following scan triggers:
When you apply the SAST profile, you enable static application security testing across your projects using the recommended configuration. The profile activates the following scan triggers:
When you enable the dependency scanning profile, your project's dependencies are scanned for known vulnerabilities using the recommended configuration. The profile activates the following scan triggers:
When you enable the dependency scanning auto-remediation profile, GitLab opens merge requests that bump vulnerable dependencies to non-vulnerable versions. For more information about this capability, see dependency scanning auto-remediation.
Prerequisites:
security_remediation_profiles feature flag
must be enabled for the project's root namespace. This flag is enabled by default in GitLab 19.2.Use the GitLab CLI (glab) to attach the
profile to a project:
glab security config enable dependency_scanning_post_processing -R <project-path>
For example, to enable the profile for my-group/my-project:
glab security config enable dependency_scanning_post_processing -R my-group/my-project
To view technical details about the secret detection profile:
To apply profiles to projects that lack scanner coverage, use the scanner enablement wizard. The wizard identifies uncovered projects and lets you apply default or custom profiles across your group.
Use the GraphQL API to apply any security configuration profile, including profiles that
are not yet available in the UI. You can run these queries with the
interactive GraphQL explorer,
or by sending requests directly to the /api/graphql endpoint.
For more information about running queries, authentication, and pagination, see run GraphQL API queries and mutations.
Prerequisites:
To apply a security configuration profile:
query {
group(fullPath: "my-group") {
availableSecurityScanProfiles {
id
name
scanType
}
}
}
A default profile that is not yet saved returns a virtual ID based on its scan type.
For example: gid://gitlab/Security::ScanProfile/dependency_scanning_post_processing.
For more information, see the
Group.availableSecurityScanProfiles field.
securityScanProfileAttach mutation, using the virtual ID or
the real ID of the profile you want: mutation {
securityScanProfileAttach(input: {
securityScanProfileId: "gid://gitlab/Security::ScanProfile/dependency_scanning_post_processing",
projectIds: ["gid://gitlab/Project/123"]
}) {
errors
}
}
For more information, see the
securityScanProfileAttach mutation.
To choose where the profile applies, set one or both of these arguments:
projectIds: Applies the profile to specific projects.groupIds: Applies the profile to all projects in one or more groups.All specified projects and groups must belong to the same top-level group. A single mutation accepts a maximum of 100 IDs, counting project and group IDs together.
Check the errors field in the response to confirm that the profile was applied.
The system uses visual cues in the inventory to indicate whether your projects are protected:
Unlike pipeline-based scans, push protection does not have a last scan date because it runs in real time during the push process.
When working with security configuration profiles, you might encounter the following issues.
Push protection is event-based, not schedule-based. It intercepts secrets in real time during the git push process. Because it is active at the moment of the push command, there is no last scan date like you would expect with pipeline-based scanners.
This can occur when a project uses legacy settings while also being assigned a new profile.
To resolve this issue:
.gitlab-ci.yml file to rely solely on the profile-based configuration.[!note] The inventory tooltip is being refined to reflect the combined status of both legacy and profile-based settings.
If you're migrating from legacy scanner configuration to profile-based configuration, note the following differences:
Profile-based configuration is recommended for easier management and greater consistency across projects.