## Summary In https://gitlab.com/gitlab-org/gitlab/-/issues/458920+ we discussed the various approaches we might take to improve the user experience for enabling Dependency Scanning once the [SBOM based Dependency Scanning capability](https://gitlab.com/groups/gitlab-org/-/epics/8026) will be achieved. The [key outcomes](https://gitlab.com/gitlab-org/gitlab/-/issues/458920#note_1937894099) 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 https://gitlab.com/groups/gitlab-org/-/epics/14484+. 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 https://gitlab.com/gitlab-org/gitlab/-/issues/433267+.~~ The CI/CD components have not deemed to be mature enough yet to support this transition. See https://gitlab.com/gitlab-org/gitlab/-/issues/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 (https://gitlab.com/groups/gitlab-org/-/epics/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 (https://gitlab.com/groups/gitlab-org/-/epics/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](https://docs.gitlab.com/ee/user/application_security/detect/security_scan_results.html#all-tiers) is also lost. The suggested replacement approach is to use the GraphQL API. See https://gitlab.com/gitlab-org/gitlab/-/issues/512514+ 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](https://docs.gitlab.com/ee/ci/yaml/artifacts_reports.html#artifactsreportsdependency_scanning). 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](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/dependency_scanning_sbom/) feature. This includes: - Identify and announce the deprecated features - Define the migration plan from Gemnasium to SBOM generator (i.e. the "new DS analyzer") - Identify gaps and decide if they need to be addressed before the deprecation announcement (in %"17.9" at most), or the removal (in %"18.0") tracked in https://gitlab.com/groups/gitlab-org/-/epics/15727+ ### Migration plan At a high-level, the current proposal to migrate users from [Gemnasium](https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium) to the [SBOM generator](https://gitlab.com/gitlab-org/security-products/analyzers/dependency-scanning) involves leveraging the DS CI Templates ([stable](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Dependency-Scanning.gitlab-ci.yml) and [latest](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Dependency-Scanning.latest.gitlab-ci.yml)). 1. Understand if and how to support MR pipelines with the [CI/CD component](https://gitlab.com/gitlab-org/gitlab/-/issues/433267). - The `latest` CI template is the de-facto support for MR pipelines for DS (related: https://gitlab.com/gitlab-org/gitlab/-/issues/410880+). While we are allowed to make breaking-changes to this template, we should an effort to provide an alternative. 1. 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. 1. Ensure the CI templates changes work with [scan execution policies](https://docs.gitlab.com/ee/user/application_security/policies/scan_execution_policies.html) and [pipeline execution policies](https://docs.gitlab.com/ee/user/application_security/policies/pipeline_execution_policies.html). - There's no need to include [compliance pipelines](https://docs.gitlab.com/ee/user/group/compliance_pipelines.html) as they were deprecated in %17.3 and are being removed in %18.0. 1. Modify the `latest` template to include the CI/CD component by %17.9 (but sooner is better). 1. Overwrite the `stable` template with `latest` on %18.0. 1. 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.