Skip to content

Compare most recent SBOM pipeline for license approval policies

What does this MR do and why?

Scan result policies compare pipelines to detect license violations. Licenses are detected by Dependency Scanning (DS) jobs, which emit an SBOM, from which licenses are inferred. Currently, the comparison logic might use a pipeline for comparison which lacks a DS job, and hence an SBOM, for example if the most recently run pipeline was scheduled by a scan execution policy, but specifies scanners other than DS.

This MR changes the comparison pipeline logic to be in line with the one currently in use by the MR widget (see #427863).

How to set up and validate locally

  • Enable license scanning

  • Create a new project

  • Commit the following .gitlab-ci.yml:

    include:
      - template: Security/Dependency-Scanning.gitlab-ci.yml
  • Commit the following Gemfile.lock:

    GEM
      specs:
        rack (3.0.4.1)
    
    PLATFORMS
      arm64-darwin-22
    
    DEPENDENCIES
      rack
    
    BUNDLED WITH
       2.4.21
  • Navigate to Secure > Policies and create the following scan result policy:

    type: scan_result_policy
    name: Deny MIT
    enabled: true
    rules:
      - type: license_finding
        match_on_inclusion: true
        license_types:
          - MIT License
        license_states:
          - detected
        branch_type: protected
    actions:
      - type: require_approval
        approvals_required: 1
        user_approvers_ids:
          - 1
          - <substitute>
  • Navigate to Secure > Policies and create the following scan execution policy:

    type: scan_execution_policy
    name: Secret Detection
    description: ''
    enabled: true
    rules:
      - type: schedule
        cadence: 0 0 * * *
        branch_type: protected
    actions:
      - scan: secret_detection
  • Execute the schedule:

    project = Project.find(ID)
    schedule = Security::OrchestrationPolicyRuleSchedule.last
    Security::ScanExecutionPolicies::RuleScheduleWorker.new.perform(project.id, project.owner.id, schedule.id)
    Security::SyncLicenseScanningRulesService.execute(project.all_pipelines.last)
  • Open an MR targeting the default branch which adds a new file. Verify the MR requires approval.

Validate merged result pipelines

  • Enable license scanning

  • Create a new project

  • Commit the following .gitlab-ci.yml:

    include:
      - template: Security/Dependency-Scanning.gitlab-ci.yml
  • Commit the following Gemfile.lock:

    GEM
      remote: https://rubygems.org/
      specs:
    
    PLATFORMS
      arm64-darwin-22
    
    DEPENDENCIES
    
    BUNDLED WITH
       2.4.22
  • Navigate to Secure > Policies and create the following scan result policy (note the newly_detected):

    type: scan_result_policy
    name: Deny MIT
    enabled: true
    rules:
      - type: license_finding
        match_on_inclusion: true
        license_types:
          - MIT License
        license_states:
          - newly_detected
        branch_type: protected
    actions:
      - type: require_approval
        approvals_required: 1
        user_approvers_ids:
          - 1
          - <substitute>
  • Open an MR that updates Gemfile.lock to:

    GEM
      remote: https://rubygems.org/
      specs:
        rack (3.0.4.1)
    
    PLATFORMS
      arm64-darwin-22
    
    DEPENDENCIES
      rack
    
    BUNDLED WITH
       2.4.22
  • Cherry-pick the MR commit onto the target branch.

  • Enable merged result pipelines

  • Commit the following .gitlab-ci.yml to the MR branch:

    include:
      - template: Jobs/Dependency-Scanning.latest.gitlab-ci.yml
        rules:
          - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
    
    dummy_job:
      script: exit 0
  • Verify that the MR does not require approval.

Database

The query from !133118 (merged) is reused: https://console.postgres.ai/gitlab/gitlab-production-ci/sessions/24710/commands/78588

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Related to #419569 (closed)

Edited by Dominic Bauer

Merge request reports

Loading