Fix MR approval policy evaluation for chained MRs

What does this MR do and why?

In scenarios involving chained MRs or long-lived branches that merge periodically, the security policy evaluation and MR security widget may incorrectly report all vulnerabilities as new, even when they already exist on the target branch. This occurs because the merge-base commit of the MR doesn't have a pipeline in the context of the target branch.

The bug happens because the MR's mr.diff_base_sha or mr.diff_head_pipeline.target_sha does not have any pipelines, but mr.diff_start_sha would have a pipeline which points to the actual sha from which the MR was created.

References

Please include cross links to any resources that are relevant to this MR. This will give reviewers and future readers helpful context to give an efficient review of the changes introduced.

• #501445 (closed)

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.

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

Before	After

How to set up and validate locally

• Create a project and create a MR approval policy to require approval on newly detected vulnerabilities:

approval_policy:
  - name: Require approval for new vulns
    description: ''
    enabled: true
    rules:
      - type: scan_finding
        scanners: []
        vulnerabilities_allowed: 0
        severity_levels: []
        vulnerability_states: []
        branch_type: protected
    actions:
      - type: require_approval
        approvals_required: 1
        role_approvers:
          - maintainer
      - type: send_bot_message
        enabled: true
    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: open

• Create .gitlab-ci.yml that produces vulnerabilities:

include:
  - template: Jobs/Container-Scanning.gitlab-ci.yml
container_scanning:
  variables:
    CS_IMAGE: vulnerables/web-dvwa

• Create a branch feature-1 and update README and create MR. Make sure to uncheck Delete source branch when merge request is accepted. option

• Merge the MR after the pipeline is complete

• Update README in feature-1 and create a new MR again and verify that approval is not required