Back to Gitlabhq

Auto remediation

doc/user/application_security/remediate/auto_remediation.md

19.1.03.6 KB
Original Source

{{< details >}}

  • Tier: Ultimate
  • Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
  • Status: Experiment

{{< /details >}}

{{< history >}}

{{< /history >}}

Auto remediation automatically 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.

For the beta roadmap and planned improvements, see epic 18236.

Turn on auto remediation

Prerequisites:

To trigger vulnerability detection and auto remediation, run a pipeline. Auto remediation triggers automatically when vulnerabilities with available fixes are detected.

How auto remediation works

After each pipeline, GitLab checks dependency scan results for vulnerabilities with known fix versions. For each eligible vulnerability:

  1. GitLab determines the nearest non-breaking upgrade path (patch or minor version bump).
  2. A service account opens a merge request that updates the relevant manifest file.
  3. The merge request goes through your project's standard approval workflow.

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

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

Auto remediation supports the following package managers:

LanguagePackage ManagerFiles
RubyBundlerGemfile, Gemfile.lock
JavaMavenpom.xml
JavaGradlebuild.gradle, build.gradle.kts

Support for additional ecosystems is planned. For details, see epic 21643.

Known issues

During the experiment phase:

  • Open merge request limit: A maximum of three auto-remediation merge requests can be open per project. New merge requests are not created until existing ones are merged or closed.
  • Version bump scope: Only patch and minor version bumps are proposed. Major version upgrades, which may introduce breaking changes, are not attempted.
  • One vulnerability per pipeline run: Each pipeline run targets a single vulnerability with an available fix. Batching multiple fixes into one merge request is planned for beta.
  • No fix available: If no non-breaking fix version exists for a vulnerability, no merge request is created for that finding.