Consider multiple target branch pipelines for license policy

What does this MR do and why?

This MR updates the logic of selecting the target branch pipeline for license approval policies to consider multiple related pipelines and select the pipeline that has SBOM reports. Currently, we take the latest 10 pipelines in the target branch and select the first pipeline that has the SBOM reports. But, when a not-so-busy project has scheduled pipelines that do not produce SBOM reports, the 10 pipelines will not have a SBOM report and therefore enforce incorrect approvals in MR.

This change uses Security::RelatedPipelinesFinder to consider multiple target branch pipelines and select the pipeline with SBOM reports. For approval policy of scan_finding type, we compare results from multiple pipelines as the findings are persisted in security_findings table, but the license findings are not persisted in the database for all pipelines yet, so we cannot compare the results from multiple pipelines for license approval policy.

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Screenshot

Before	After

How to set up and validate locally

• Enable License scanning in GDK
• Create a project with .gitlab-ci.yml that runs dependency scanning job and make the job not run for scheduled pipeline:

include:
  - template: Security/Dependency-Scanning.gitlab-ci.yml

dummy_job:
  script: exit 0

gemnasium-dependency_scanning:
  rules:
    - if: $CI_PIPELINE_SOURCE == "schedule"
      when: never
    - if: $CI_PIPELINE_SOURCE == "push"

• Create Gemfile.lock file with this content:

GEM

PLATFORMS
  arm64-darwin-22

DEPENDENCIES

BUNDLED WITH
   2.4.21

• Verify that the pipeline has dependency_scanning job and does not produce any licenses
• Create a license approval policy to require approval on newly detected license (MIT License):

name: Newly detected licenses
description: ''
enabled: true
actions:
- type: require_approval
  approvals_required: 1
  role_approvers:
  - maintainer
- type: send_bot_message
  enabled: true
rules:
- type: license_finding
  match_on_inclusion_license: true
  license_types:
  - MIT License
  license_states:
  - newly_detected
  branch_type: protected
approval_settings:
  block_branch_modification: true
  prevent_pushing_and_force_pushing: true
  prevent_approval_by_author: true
  prevent_approval_by_commit_author: true
  remove_approvals_with_new_commit: true
  require_password_to_approve: false
fallback_behavior:
  fail: closed

• Create a pipeline schedule from Build -> Pipeline Schedules and execute the schedule (click Run pipeline schedule button) for 10+ times
• Now create 2 MRs:
  • Update README.md
  • Add a dependency with MIT License

GEM
  remote: https://rubygems.org/
  specs:
    rack (3.0.4.1)

PLATFORMS
  arm64-darwin-22

DEPENDENCIES
  rack

BUNDLED WITH
   2.4.22

• Verify that approval is required for the MR that introduced a dependency and approval is not required for MR that updates README. Also verify the bot comment with the correct pipelines

Addresses #455760 (closed)