Add feature flag to toggle Continuous Vulnerability Scans for Container Scanning
Proposal
As discussed here, in order to err on the side of caution, we should add a feature flag to toggle Continuous Vulnerability Scans for Container Scanning.
Possible solutions
Choose one of the following solutions:
-
Update Gitlab::VulnerabilityScanning::ContainerScanning::AffectedVersionRangeMatcher#affected? to return
false
unless the feature flag is enabled:diff --git a/ee/lib/gitlab/vulnerability_scanning/container_scanning/affected_version_range_matcher.rb b/ee/lib/gitlab/vulnerability_scanning/container_scanning/affected_version_range_matcher.rb index 69a239f92328..f1cb63bd6d52 100644 --- a/ee/lib/gitlab/vulnerability_scanning/container_scanning/affected_version_range_matcher.rb +++ b/ee/lib/gitlab/vulnerability_scanning/container_scanning/affected_version_range_matcher.rb @@ -15,6 +15,8 @@ def initialize(purl_type:, range:, version:, distro:, source:) end def affected? + return false unless Feature.enabled?(:container_scanning_continuous_vulnerability_scans) + return false unless distro_matches? # a wildcard range means that all versions are affected
However, since the
Gitlab::VulnerabilityScanning::ContainerScanning::AffectedVersionRangeMatcher
class doesn't have access to theproject
, we can't toggle this feature flag on a per-project basis, which doesn't work for us. -
Update Security::VulnerabilityScanning::CreateVulnerabilityService#finding_maps to skip projects where the feature flag is disabled:
diff --git a/ee/app/services/security/vulnerability_scanning/create_vulnerability_service.rb b/ee/app/services/security/vulnerability_scanning/create_vulnerability_service.rb index bb8b86abbf77..97d25fcbc6de 100644 --- a/ee/app/services/security/vulnerability_scanning/create_vulnerability_service.rb +++ b/ee/app/services/security/vulnerability_scanning/create_vulnerability_service.rb @@ -76,6 +76,8 @@ def finding_maps finding = finding_for_affected_component(affected_component) next if finding.nil? + next unless Feature.enabled?(:container_scanning_continuous_vulnerability_scans, affected_component.project) + track_upsert_for_project_id(affected_component.project.id) scanner_id = scanner_for_project(affected_component.project).id
Pros & cons: It's granular and allows an incremental rollout but at the cost of extra checks. See #435435 (comment 1698421704)
-
Add the toggle to Sbom::PossiblyAffectedOccurrencesFinder#execute_in_batches, similar to how this was done in Only include sbom_occurrences with CVS enabled (!131454 - merged) • Adam Cohen • 16.4, however, we can't use a named scope because the
Feature.enabled?
method needs to be executed against each project. -
Publish an advisory if the flag corresponding to the advisory source is enabled. See #435435 (comment 1698421704)
- Advisory source is Trivy DB and
container_scanning_continuous_vulnerability_scans
is enabled. - Advisory source is GLAD and
dependency_scanning_on_advisory_ingestion
is enabled.
- Advisory source is Trivy DB and
Implementation Plan
The plan is based on the proposal N1.
-
Create a new feature flag
container_scanning_continuous_vulnerability_scans
of beta type. -
In Gitlab::VulnerabilityScanning::ContainerScanning::AffectedVersionRangeMatcher#affected? add a check for this flag:
def affected? return false if Feature.disabled?(:container_scanning_continuous_vulnerability_scans) return false unless distro_matches? # a wildcard range means that all versions are affected return true if range == '*' SemverDialects::VersionChecker.version_sat?(purl_type, version, range) end
-
Add tests for
Gitlab::VulnerabilityScanning::ContainerScanning::AffectedVersionRangeMatcher#affected?
to test this behaviour.