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 (clickRun 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)