Add configuration options to disable SBOM based features (CVS)

Release notes

Problem to solve

As we move from CI based security scans to SBOM based security scans in the rails platform, there is no opportunity for users to disable some features based on the SBOM content.

Indeed, as soon as a compatible SBOM report artifact is provided via a CI job, it will automatically enable several features:

• License Scanning of CycloneDX files
• Dependency list (Group level and Project level)
• Continuous Vulnerability Scanning (scan when a new Advisory is published)
  • for Dependency Scanning package types
  • for Container Scanning package types
  • for Container Scanning for the Container Registry
• Security Scanning of SBOM files (Similar to the legacy Dependency Scanning and Container Scanning)
  • for Dependency Scanning package types (Application packages)
  • for Container Scanning package types (Operating System packages)

Though, some customers might want only some of these features enabled for their project. For instance, a user might want the Dependency List to be populated but they have their own Dependency Scanning solution and provide security report artifact to populate the Vulnerability Management system. Currently, there is no possibility to disable the built-in Dependency Scanning feature when ingesting the SBOM report, nor the Continuous Vulnerability Scanning. These features might not follow the configuration that the customer has done for its provided DS solution and thus create vulnerabilities they don't want.

Proposal

In the Security Configuration page we should add new toggles to allow for a granular enablement of the features. Following our working by default philosophy, the toggles default value should be "enabled". Here is a list of toggles we could add:

1. CVS on SBOM changes for DS purl types
2. CVS on SBOM changes for CS purl types
3. CVS on advisory changes for DS purl types
4. CVS on advisory changes for CS purl types
5. License Scanning

TBD:

• is it worth distinguishing CS and DS purl types in CVS related features?
• is it relevant to add a toggle for the dependency list as it?

Intended users

Feature Usage Metrics

Does this feature require an audit event?

added Category:Software Composition Analysis Enterprise Edition GitLab Ultimate SCA:Dependency Scanning backend devopssecure featureenhancement groupcomposition analysis sectionsec typefeature labels

mentioned in epic gitlab-org#11219

@johncrowley FYI should this be something to consider for the removal of gemnasium?

@gonzoyumo - I do think this is a relevant feature (thank you for creating the issue). What are your thoughts on doing this as a follow on post-removal of Gemnasium?

@johncrowley the removal (not the deprecation) will happen in %18.0 so I would suggest we do it before. But I would not consider this on the critical path for the deprecation, therefore I did not add it to &14146

@gonzoyumo - that sounds good. I agree with that approach where we keep our eye on the prize of deprecation and then turn our attention to these types of issues.

@gonzoyumo how about having a follow-up epic for deprecation? We can slot it there.

/cc @johncrowley

@tkopel sure. I've added Transition to Dependency Scanning with SBOM for... (&15727) to track work related to the removal and have marked this issue as a blocker.

This way we can clearly distinguish what's related to the deprecation (17.9 at most) and the actual removal (18.0).

changed milestone to %Backlog

marked this issue as blocking gitlab-org#15727

@johncrowley this issue encapsulates all suggested configuration options for rails side scanning. I think this ought to make its way onto our roadmap. Probably as an epic where we add various configuration options as the time goes.

100% agree here @tkopel - lets figure out when we can slot this in.

@johncrowley @gonzoyumo added to the roadmap review

mentioned in issue #501443

@smeadzinger - for visibility.

Thank you for the tag John! @johncrowley and @smeadzinger discussed in 1:1 on Nov 12. Summary - we want to give users the ability to configure scanners as much as they need to, and at the same time, we want to reduce complexity as much as possible when we can. Are options 1 and 2 above needed? Or are only options 3-5 needed? If a dependency has changed, and an SBOM has changed, shouldn't new vulnerabilities be detected as the SBOM itself is different?

cc: @or-gal and @mfangman it sounds like groupsecurity platform management will want to collaborate with groupcomposition analysis on this issue as we get closer to 18.0.

Are options 1 and 2 above needed? Or are only options 3-5 needed? If a dependency has changed, and an SBOM has changed, shouldn't new vulnerabilities be detected as the SBOM itself is different?

@smeadzinger to answer this question we can ask ourselves if we want to enforce the execution of Dependency Scanning and Container Scanning on SBOM changes for all ultimate users who generate an SBOM report? If we don't, then we need to offer them the ability to disable the feature.

The key aspect is that with our shift to SBOM based features, users don't necessarily enable them by taking a specific action on their project (unlike explicitely including a CI/CD component in their project). As soon as an SBOM report is provided, all SBOM based features are automatically activated. This is great for our "working by default" product principle, but I think we also need to accomodate users who do not want these features.

What if a customer's security team has not approved our security scanners (for whatever reason) and requires the company to run different security tools? With the CI based scanners they can remove corresponding CI jobs but they have no control over SBOM based feature happening in the rails application. The alternative for them would be to simply stop uploading an SBOM report which also disables other features they might want (Dependency Management, License Scanning, etc.)

NB: we don't mention explicitely the ability to disable a feature as being a requirement in our product principle, yet generally the features of a project can be toggled in its settings: https://docs.gitlab.com/ee/user/project/settings.

changed the description

mentioned in issue #477593

A large GitLab Ultimate customer would be interested in this feature. ZD link - internal only.

Feedback and questions from this customer

- Priority: ~customer priority:: Medium
- Why interested: Because vulnerabilities injected by GitLab is not necessarily the one we want to focus on. We want to be able to manage all vulnerabilities
- Problem they are trying to solve: Option to enabling/disabling vulnerabilities from Dependency list. Or option for us to manage those vulnerabilities.
- Current solution for this problem: We dismissed all the vulnerabilities from GitLab SBOM vulnerability scanner
- Impact to the customer of not having this: Difficulties in managing vulnerabilities
- Questions:
  - ETA of the feature?
  - Any workaround in the meanwhile?

I noted that this issue is currently in the backlog and referenced as blocking

• GitLab Epic &15727 which is scheduled to start Mar 15 2025.

added customer label