Skip to content
Snippets Groups Projects

Deprecate build support on Dependency Scanning and CI based security scanning with Gemnasium

Open Epic created by John Crowley @johncrowley

Summary

In Discuss new UX for enabling Dependency Scanning... (gitlab#458920 - closed) we discussed the various approaches we might take to improve the user experience for enabling Dependency Scanning once the SBOM based Dependency Scanning capability will be achieved. The key outcomes of the discussion were:

  1. Deprecate and remove Dependency Scanning builds
  2. Create CI/CD Components for Dependency Scanning

Another important part of this plan is the removal of CI based security scanning with the Gemnasium analyzer and the focus on SBOM based security scanning as part of our default offering.

Deprecation of build support

To summarize, the strategy going forward is:

  • Use a Dependency Scanning analyzer to parse lockfiles or equivalent to generate an SBOM artifact
  • Rely on native SBOM generators to create an SBOM artifact to be provided to us
  • Rely on generic SBOM generators to create an SBOM artifact to be provided to us

This epic depends on delivery of the first item, which is tracked in Software composition analyzer for dependency gr... (&14484 - closed). The others will be pursued separately and likely after this is complete.

Adoption of CI/CD Components

The existing use of CI templates relies on rules that detect the project type in order to run the appropriate jobs.

This epic depends on the CI/CD Component that enables our new analyzer, which supports monorepos and doesn't require template rules to select the appropriate job because there's only one job with the default configuration. This work is tracked in Create Dependency Scanning CI/CD Component (gitlab#433267 - closed).

The CI/CD components have not deemed to be mature enough yet to support this transition. See Update Security template guidance to prefer com... (gitlab#489904)

Deprecation of CI based security scanning with Gemnasium analyzer

The new DS analyzer will only we responsible for generating an SBOM report artifact and no security scan will be done within the CI job. Instead, the Dependency Scanning feature will leverage the scanning capabilities developed for Continuous Vulnerability Scanning, which are executed within the rails platform.

This changes comes with important side-effects and feature removals that must be carefully reviewed by users. We will list them exhaustively as part of the deprecation announcement.

WIP list:

  • auto-remediation feature for yarn will not be available with the new analyzer and thus removed as of 18.0 unless we managed to replace it with a new implementation (&759) before that release.
  • DS scans of vendored JS libraries will not be available with the new analyzer and thus removed as of 18.0 unless we managed to replace it with a new implementatin (&7186) before that release.
  • DS security report will no longer be generated by the built in DS feature as of 18.0, impacting any existing workflow based on these CI artifact files, either to modify them before they get ingested in GitLab or to consume them in another CI job or an external vulnerability management system. The ability to download results via the UI is also lost. The suggested replacement approach is to use the GraphQL API. See Ensure the GraphQL API provides an acceptable U... (gitlab#512514 - closed) for ongoing validation.

:warning: Please note that this shift of paradigm is not removing the ability for GitLab to ingest Dependency Scanning security report artifact. Third party integrations can continue to leverage that capability but the built-in Dependency Scanning feature will be based on CycloneDX report artifacts instead.

Scope

This epic covers the necesary work to deprecate the existing features, and prepare our users for the transition to the new Dependency scanning by using SBOM feature.

This includes:

Migration plan

At a high-level, the current proposal to migrate users from Gemnasium to the SBOM generator involves leveraging the DS CI Templates (stable and latest).

  1. Understand if and how to support MR pipelines with the CI/CD component.
  2. Devise a way to guide users through the process of generating lock file(s) for their project.
    • The SBOM generator will not write a report for projects that require a build. We don't want the DS jobs to fail silently.
  3. Ensure the CI templates changes work with scan execution policies and pipeline execution policies.
  4. Modify the latest template to include the CI/CD component by %17.9 (but sooner is better).
  5. Overwrite the stable template with latest on %18.0.
  6. Consider whether we want to deprecate the CI template and remove them in 19.0 since, at this stage, it's mostly a wrapper around the CI/CD Component.
Edited by Olivier Gonzalez

Activity

Please register or sign in to reply