Skip to content

Announce the deprecation of build support and CI based security scanning with Gemnasium

This issue focuses on announcing the change. For the broader context please refer to the parent epic: Deprecate build support on Dependency Scanning ... (&14146 - closed)

Deprecation Summary

Warning

ADDENDUM: Based on customer feedback, we have decided to postpone the breaking changes and maintain the existing Gemnasium analyer as the default in the current Dependency-Scanning CI/CD template. We will also reinstate the generation of the Dependency Scanning report artifact for the Generally Available release of the new Dependency Scanning analyzer and the Dependency Scanning using SBOM feature. Users will instead be given the oppportunity to migrate to the new feature at their pace and we're now targeting the removal of Gemnasium in 19.0: https://docs.gitlab.com/update/deprecations/?removal_milestone=19.0#dependency-scanning-upgrades-to-the-gitlab-sbom-vulnerability-scanner

The Dependency Scanning feature is upgrading to the GitLab SBOM Vulnerability Scanner. As part of this change, the Gemnasium analyzer (previously used in CI pipelines) is deprecated in GitLab 17.9 and reaches end of support in GitLab 18.0. It is replaced with the new Dependency Scanning analyzer that focuses on detecting dependencies and their relationships (dependency graph). This upgrade represents a fundamental shift: instead of performing security analysis within CI pipelines, the new system uses GitLab's built-in SBOM Vulnerability Scanner, which is already employed by Continuous Vulnerability Scanning.

Due to the significant changes and feature removals this upgrade introduces, it will not be implemented automatically. While some breaking changes will take effect in GitLab 18.0, existing CI jobs using the Gemnasium analyzer will continue to function by default to prevent disruption to CI configurations.

Please review the fully detailed changes below and consult the migration guide to assist you with the transition.

  • When using the Dependency Scanning CI template (Dependency-Scanning.gitlab-ci.yml), the existing CI jobs based on the Gemnasium analyzer will continue to be used by default. The new Dependency Scanning analyzer will run by default only for newly supported languages and package managers that are not already covered by the Gemnasium analyzer. You can also opt-in to fully migrate to the new Dependency Scanning analyzer and use for all supported projects.
  • To transition to Dependency Scanning with SBOM, the security scan results generated by the Gemansium analyzer will no longer be uploaded to the GitLab platform as a Dependency Scanning security report artifact. Instead, Dependency Scanning results will be generated within the GitLab platform, using the GitLab SBOM Vulnerability Scanner, and based on the CycloneDX SBOM report artifact generated in the CI pipeline. As a result, any workflows that rely on modifying security scan results before uploading them to the GitLab platform will be impacted. However, the Dependency Scanning JSON report will continue to be produced by the Gemnasium analyzer and exported as a standard job artifact so that any workflow that consumes this report in a succeeding CI job will continue to work. Please note that further improvements made to the GitLab SBOM Vulnerability Scanner will not be reflected in this JSON report. Since the new Dependency Scanning analyzer does not generate any security report, when migrating users must use the (Pipeline.securityReportFindings resource) of the GraphQL API to programmatically consume security scan results. The ability to download security scan results via the UI in this format for the GitLab Dependency Scanning feature is also removed in GitLab 18.0. The Dependency Scanning security report artifact itself is not deprecated and GitLab will continue to support these reports for third party integrations.
  • The Gemnasium analyzer project is deprecated, as well as the corresponding container images (all tags and variants): gemnasium, gemnasium-maven, gemnasium-python. These images will not be removed from the GitLab container registry but they are no longer supported with GitLab 18.0 and above.
  • The following CI/CD variables associated with the Gemnasium analyzer are also deprecated. While these variables will continue to work when using the Gemnasium analyzer, they will not be effective after migrating to the new Dependency Scanning analyzer. If a variable is also used in another context, the deprecation only applies to the Dependency Scanning feature (e.g. GOOS and GOARCH are not specific to the Dependency Scanning feature). DS_EXCLUDED_ANALYZERS, DS_GRADLE_RESOLUTION_POLICY, DS_IMAGE_SUFFIX, DS_JAVA_VERSION, DS_PIP_DEPENDENCY_PATH, DS_PIP_VERSION, DS_REMEDIATE_TIMEOUT, DS_REMEDIATE, GEMNASIUM_DB_LOCAL_PATH, GEMNASIUM_DB_REF_NAME, GEMNASIUM_DB_REMOTE_URL, GEMNASIUM_DB_UPDATE_DISABLED, GEMNASIUM_LIBRARY_SCAN_ENABLED, GOARCH, GOFLAGS, GOOS, GOPRIVATE, GRADLE_CLI_OPTS, GRADLE_PLUGIN_INIT_PATH, MAVEN_CLI_OPTS, PIP_EXTRA_INDEX_URL, PIP_INDEX_URL, PIPENV_PYPI_MIRROR, SBT_CLI_OPTS.
  • The following CI/CD components are deprecated and reach end of support in GitLab 18.0: Android, Rust, Swift, Cocoapods. These are replaced by the main Dependency Scanning CI/CD component that covers all supported languages and package managers.
  • The Resolve a vulnerability feature for Yarn projects is deprecated in GitLab 17.9 and reaches end of support in GitLab 18.0. While this functionality will continue to work when using the Gemnasium analyzer, it will not be available after migrating to the new Dependency Scanning analyzer. See the corresponding deprecation announcement for more details.
  • The Dependency Scanning for JavaScript vendored libraries feature is deprecated in GitLab 17.9 and reaches end of support in GitLab 18.0. While this functionality will continue to work when using the Gemnasium analyzer, it will not be available after migrating to the new Dependency Scanning analyzer. See the corresponding deprecation announcement for more details.

⚠️ This announcement must be done at most in %17.9.

Documentation

Product Usage

Describe why deprecation of this feature is necessary, ideally with dashboards/metrics that show product usage. add links to the documentation

This change is critical to the evolution of our Dependency Scanning transition toward SBOM based scanning capabilities. This support the expansion to cover a lot more projects by relying on SBOM as an input document and extendng Dependency Scanning to other workflows beyond the CI pipeline while reducing the maintenance burden for the Composition Analysis team.

Breaking Change?

Yes

Affected Customers

  • GitLab.com
  • Self-managed
  • Dedicated

Internal note

GitLab Ultimate

Deprecation Milestone

17.9

Planned Removal Milestone

18.0

Links

Checklists

Timeline

Rollout Plan

DRIs:

  • Engineers: @gonzoyumo
  • Describe rollout plans on GitLab.com
    • During 17.9, and at the latest on 2025-02-14, the Dependency-Scanning.latest.gitlab-ci.yml CI template will be updated to switch to using the new DS analyzer and enable the new behavior.
      • All GitLab.com customers will immediately start using it as soon as the deployement is done. There is no partial rollout for the CI template.
      • Self-managed customers will only be impacted when upgrading their instance
      • Projects using the "stable" CI template Dependency-Scanning.gitlab-ci.yml are NOT impacted.
  • Determine how to migrate users still using the existing functionality
    • Users of the "stable" CI template Dependency-Scanning.gitlab-ci.yml will be migrated to the new behavior in 18.0, when such template will be updated.
  • Document ways to migrate with the tooling available
    • A dedicated migration guide is being added to the documentation with !175029 (merged)
  • Automate any users who have not yet migrated, but ensure it's a two-way door decision
    • The change of the CI template include the addition of a new ENV var LEGACY_DEPENDENCY_SCANNING, that can be used to revert to the old behavior.
Communication Plan

DRIs:

Please 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: 14.8, 14.9, 14.10, 15.0 – 14.8 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.
      • Add link

Development

DRIs:

  • Engineers: @gonzoyumo
  • Measure usage of the impacted product feature
    • Evaluate metrics across GitLab.com, Self-Managed, Dedicated
    • add issue link
    • list any metrics and/or dashboards - Scan Metrics - Specifically, gemnasium-maven and gemnasium-python
  • Create tooling for customers to manually migrate their data or workflows
    • There is no tooling for migration.
    • The CI template will migrate the underlying analyzer automatically in 18.0. Any CI configuration adjustement required after that change will have to be done manually.
    • Users can opt-in to use the new implementation by setting a CI/CD variable starting 17.9
    • Tool for identification of affected projects: Build-support-detection-helper
  • Build mechanism for users to manually enable the breaking change ahead of time
    • Users can use the latest template starting 17.9 to switch to the new behavior.
  • Automate the migration for those who do not take any manual steps (ensure the automation can be reverted)
    • There is no tooling for migration. The CI template will migrate the underlying analyzer automatically. Any CI configuration adjustment required after that change will have to be done manually.
  • Develop rollout plan of breaking change on GitLab.com
  • Dogfood the changes on GitLab.com or a Self-Managed test instance
  • Announce deprecation in Engineering Week-in-Review (internal link) and Support Week-in-Review
  • (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

Mentions (as applicable)

  • Product Designer @ProductDesigner
  • Tech Writer @TW
  • Software Engineering in Test @SET
  • Any other stablecounterparts 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.
Edited by Olivier Gonzalez