Dependency scanning auto-remediation

Dependency scanning auto-remediation opens a merge request to bump a vulnerable dependency to a non-vulnerable version when one is available. A service account creates the merge request without any human input, which then goes through the standard review and approval process.

In beta, dependency scanning auto-remediation supports two independently configurable capabilities:

• Dependency version bumps: GitLab opens merge requests that update the vulnerable dependency.
• Agentic breaking-change resolution: When a version bump causes a pipeline failure due to a breaking change, GitLab Duo attempts to resolve it. For more information, see enable agentic breaking-change resolution.

For the generally available roadmap, see epic 19244.

Security configuration profiles also support this flow. To turn on and configure the flow across multiple projects and groups at once, use the automated triage and remediation profile.

Turn on dependency scanning auto-remediation

Prerequisites:

• Dependency scanning must be enabled and producing results.
• The project must use a supported package manager.
• A dependency scanning auto-remediation profile must be attached to the project. For instructions, see dependency scanning auto-remediation profile.
• The runner must accept untagged jobs. GitLab generates the auto-remediation job without tags, and does not use the project’s .gitlab-ci.yml configuration for it, so default:tags does not apply.
• The runner must allow privileged mode. The auto-remediation job uses a docker:28-dind service. For more information, see use Docker to build Docker images.
• The runner must be able to pull the auto-remediation orchestrator image from registry.gitlab.com and the docker:28-dind image.

To trigger vulnerability detection and auto-remediation, run a pipeline. Dependency scanning auto-remediation triggers automatically when GitLab detects vulnerabilities with available fixes.

How dependency version bumps work

The dependency scanning auto-remediation profile controls this behavior. With the default profile:

• Severity threshold: GitLab remediates vulnerabilities at or above high severity.
• Cooldown period: GitLab excludes fix versions released in the last seven days.
• Upgrade policy: GitLab proposes only patch and minor version bumps, unless agentic breaking-change resolution is enabled.
• Open merge request limit: A maximum of 10 auto-remediation merge requests can be open per project at a time. GitLab does not create new merge requests until existing ones are merged or closed.

After each pipeline, GitLab checks dependency scan results against these values. For each eligible vulnerability:

1. GitLab determines the nearest non-breaking upgrade path.
2. A service account opens a merge request that updates the relevant manifest file.
3. GitLab assigns an active Maintainer of the project as a reviewer. If no active Maintainer exists, the merge request stays open without a reviewer.
4. The merge request goes through your project’s standard approval workflow.

During beta, GitLab processes three vulnerabilities at a time, starting with the highest severity finding.

Enable agentic breaking-change resolution

When a version bump causes a pipeline failure because of a breaking change, GitLab Duo can attempt to resolve the breaking change automatically. This capability is separate from the dependency version bump capability and has its own toggle.

Prerequisites:

• You must have GitLab Duo available for the project.

To enable agentic breaking-change resolution, use the Projects API to set duo_dependency_bump_breaking_changes_enabled to true for the project.

Configure scheduler concurrency

Administrators can limit how many auto-remediation scheduler jobs run concurrently across the Sidekiq fleet. Use the security_update_scheduler_max_concurrency application setting to set the cap. The default is 30, and the value is capped at 200. Set the value to 0 to pause scheduling.

Supported package managers

Dependency scanning auto-remediation supports the following package managers:

Support for additional ecosystems is proposed in epic 19244.

For .NET, dependency scanning only detects NuGet dependencies from a committed packages.lock.json. Projects without one produce no NuGet findings, so auto-remediation has nothing to act on. To generate the lock file, set RestorePackagesWithLockFile in your project file and commit the result.

Service account permissions

The first time dependency scanning auto-remediation runs on a project, GitLab creates a service account for the project named GitLab Dependency Management. GitLab reuses this account for every subsequent auto-remediation merge request on the project, so each project has exactly one.

GitLab adds the service account to the project as a Guest member. This membership makes the account a member of the project, but grants no other permission. A dedicated internal role then grants the account the following abilities:

• Clone the repository.
• Push a branch.
• Create and update merge requests.
• Create pipelines.

This internal role, not the Guest membership, bounds what the account can do. The account holds no broader role because the design grants these abilities directly and narrowly, instead of giving an automated account the Developer role on every project that turns the feature on. For the full rationale behind this design, see ADR 003: Single service account model.

Pipelines on auto-remediation merge requests run as this service account. If a job needs permissions beyond what that role grants, the job fails, even though the same pipeline succeeds when a person with the Developer role runs it. For example:

• Pushing a container image to the project container registry requires the Developer role. Pulling an existing image from the project container registry works with the service account’s permissions.
• Reading the project package registry requires the Reporter role.

A project that uses Auto DevOps hits the container registry case, because the Auto DevOps build job pushes an image.

To let these jobs run, a user with at least the Maintainer role can grant the service account the Developer role on the project. For instructions, see auto-remediation pipeline jobs fail with permission errors.

Known issues

During the beta phase:

• Cooldown period: GitLab does not propose a fix version released in the last seven days, to reduce the risk of remediating to a version that is later found to be broken or malicious.
• Version bump scope: Only patch and minor version bumps are proposed. Major version upgrades, which are more likely to introduce breaking changes, are not attempted unless agentic breaking-change resolution is enabled.
• One vulnerability per pipeline run: Each pipeline run targets a single vulnerability with an available fix. Batching multiple fixes into one merge request is proposed in epic 19244.
• No fix available: If no non-breaking fix version exists for a vulnerability, no merge request is created for that finding.
• Merge request creation depends on a successful pipeline. GitLab creates the dependency-management/<dependency>-<major-version>.x branch before it runs the auto-remediation pipeline on that branch, and creates the merge request only after that pipeline succeeds. A dependency-management/ branch that has no merge request and no commit that changes a manifest file indicates that the pipeline did not succeed. Check the status of the pipeline on that branch.

Troubleshooting

Auto-remediation pipeline jobs fail with permission errors

Pipeline jobs on auto-remediation merge requests run as the GitLab Dependency Management service account, which gets its abilities from an internal role rather than from the Guest role it also holds. This internal role does not cover everything a project pipeline might need. For more information, see service account permissions. A job that needs permissions beyond what that role grants fails, even though the same job succeeds when a person with the Developer role runs it. The error differs by job. For example, a job that pushes an image to the project container registry receives a denial, and a job that reads the project package registry receives a 403 error.

To work around this issue, a user with at least the Maintainer role can grant the service account the Developer role for the project:

1. In the left sidebar, select Search or go to and find your project.
2. Select Manage > Members.
3. Find the GitLab Dependency Management member.
4. Change its role to Developer.

This action grants the service account the full Developer role on the project. Make this change only if your pipeline needs it. The change applies only to this project. It persists, so subsequent auto-remediation merge requests on the project get pipelines that work. Re-run the failed pipeline to pick up the change.