Deprecation issue for enabling GitLab Advanced SAST by default

Understanding this change

Does this change impact you?

This change only impacts GitLab Ultimate; this change does not impact GitLab Premium.

The steps for users on a SaaS platform (GitLab.com, GitLab Dedicated) and for self-managed to check whether they will be impacted are:

  1. Check if you are using one of our SAST CI/CD templates (SAST.gitlab-ci.yml or SAST.latest.gitlab-ci.yml) in your projects.
  2. You can do this by inspecting the GitLab CI configuration for a project manually or with the Advanced Search Deprecations tool
  3. Confirm if the project uses any of the languages that are supported by GitLab Advanced SAST
  4. Check if you have already set the CI/CD variable GITLAB_ADVANCED_SAST_ENABLED to either true or false at the project, group or instance level or in a scan execution policy

GitLab projects with Ultimate that use languages supported by Advanced SAST are impacted unless GITLAB_ADVANCED_SAST_ENABLED has been set elsewhere.

What does impact from this change look like?

If you are impacted by this change, you will notice that SAST scanning might take longer to complete due to the more comprehensive scanning performed by Advanced SAST. Additionally, you may see different results in your SAST scans as the Advanced SAST scanner uses a new ruleset and takes over coverage for supported languages.

An automated process will migrate results from previous scanners after the first scan on each project's default branch, if they're still detected.

⚠️ On GitLab.com, this will occur during window 1 (April 21 - 23, 2025 from 09:00 UTC to 22:00 UTC) – before the release of GitLab 18.0.

How to prepare for this change?

The steps for users on a SaaS platform (GitLab.com, GitLab Dedicated) and for self-managed to prepare for this change are:

  1. Review your project's existing SAST scanning configuration and results
  2. Test GitLab Advanced SAST on your projects before the change by setting the CI/CD variable GITLAB_ADVANCED_SAST_ENABLED to true

You can disable GitLab Advanced SAST by setting the CI/CD variable GITLAB_ADVANCED_SAST_ENABLED to false at the project, group, or instance level or in a scan execution policy. Learn more about CI/CD variable precedence in the docs.

GitLab customers with an active subscriptions can reach out to GitLab Support when encountering problems with the guidance above.

Deprecation Summary

In GitLab %18.0, the behavior of the gitlab-advanced-sast and semgrep-sast jobs are changed as follows:

  • Old behaviour:

    • By default, the gitlab-advanced-sast job is not executed.
    • The gitlab-advanced-sast job can be executed if GITLAB_ADVANCED_SAST_ENABLED is set to true or 1

  • New behaviour in 18.0:

    • By default, the gitlab-advanced-sast job is executed
    • The gitlab-advanced-sast job can be disabled if GITLAB_ADVANCED_SAST_ENABLED is set to false or 0

The following templates are affected:

Documentation

Product Usage

The GITLAB_ADVANCED_SAST_ENABLED variable was initially introduced by Advanced SAST GA - Disabled by default and when... (#474094 - closed) • Dean Agron, Ron Vider+ • 17.3 in order reduce disrupting existing behavior by allowing customers to opt-in to the gitlab-advanced-sast scanning feature.

We now wish to update the GITLAB_ADVANCED_SAST_ENABLED variable so we execute the gitlab-advanced-sast scanner by default as part of %18.0, and allow users to disable the scanner by explicitly setting GITLAB_ADVANCED_SAST_ENABLED: false.

Breaking Change?

Yes. Scan results will be different, since gitlab-advanced-sast takes precedence over semgrep.

Affected Customers

  • GitLab.com
  • Self-managed
  • Dedicated

Deprecation Milestone

%17.9

Planned Removal Milestone

%18.0

Links

Checklists

Timeline

Rollout Plan

DRIs:

The change will be rolled-out with the GitLab %18.0 release. It's already available from %17.3 .

There's no feature flag for this change, however, behaviour can be disabled by setting GITLAB_ADVANCED_SAST_ENABLED: false.

Communication Plan

DRIs:

Add links to the relevant merge requests.

  • As soon as possible, but no later than the third milestone preceding the major release (for example, given the following release schedule: 17.8, 17.9, 17.10, 17.11, 18.0 – 17.9 is the third milestone preceding the major release):
  • On the major milestone:
    • The deprecated item has been removed.
    • If the removal of the deprecated item is a breaking change, the merge request is labeled breaking change.
    • Document the migration plan for users, clearly outlining the actions they need to take to mitigate the impact of the breaking change.

Development

DRIs:

  • Engineers: @adamcohen

  • Engineering Manager: @thiagocsf

  • Measure usage of the impacted product feature

    • Evaluate metrics across GitLab.com, Self-Managed, Dedicated
    • add issue link
    • list any metrics and/or dashboards

  • Create tooling for customers to manually migrate their data or workflows

    • add issue link

  • Build mechanism for users to manually enable the breaking change ahead of time

    • add issue link

  • Automate the migration for those who do not take any manual steps (ensure the automation can be reverted)

    • add issue link

  • Develop rollout plan of breaking change on GitLab.com

    • add feature flag rollout issue

  • Dogfood the changes on GitLab.com or a Self-Managed test instance

    • add issue link

  • (Optional) Create UI controls for instance admins to disable the breaking change, providing flexibility to Self-Managed / Dedicated customers. Optional as this depends on the breaking change.

    • add issue link

Approvals

  • Product Manager @PM
  • Engineering Manager @EM
  • Senior Engineering Manager / Director @senior-eng-leader
  • Group / Director of Product Management @senior-product-leader

Mentions (as applicable)

  • Product Designer @ProductDesigner
  • Tech Writer @TW
  • Software Engineering in Test @SET
  • Any other stable counterparts based on the product categories:
    • Add Sales/CS counterpart or mention @timtams
    • Add Support counterpart or mention @gitlab-com/support/managers
    • Add Marketing counterpart or mention @cfoster3

Labels

  • This issue is labeled deprecation, and with the relevant ~devops::, ~group::, and ~Category: labels.
  • This issue is labeled breaking change if the removal of the deprecated item will be a breaking change.

References

Edited by Brie Carranza