Scan result policy requiring MR approval when no pipelines have been run
Summary
A rule in Scan Result Policy will require approval on an MR where no pipelines have been run. It does not looks like this particular scenario is covered in the docs on example situations where scan result policies require additional approval.
Steps to reproduce
- In a project that does not make use of GitLab CI, create a New policy to require approval when
Secret Detection
finds more than1
Critical
vulnerability in any state in an open MR targetingAll protected branches
- Merge the policy and confirm it's active by browsing to Security & Compliance > Policies
- Open a new MR with a protected branch as the target branch
- Observe that the rule in the policy is applied: approval is required to merge the MR although the Secret Detection job did not run.
Example Project
The linked MR in the bcarranza/no-ci
project is in this state.
.yaml preview type: scan_result_policy name: Secret Scanning description: '' enabled: true rules: - type: scan_finding branches: [] scanners: - secret_detection vulnerabilities_allowed: 1 severity_levels: - critical vulnerability_states: - newly_detected - detected - confirmed - dismissed - resolved actions: - type: require_approval approvals_required: 1 user_approvers_ids: - 6049551 - 7272738
What is the current bug behavior?
The rule introduced by the policy is applied even though no vulnerabilities have been detected. (We have not even run a pipeline.)
What is the expected correct behavior?
Rules that require vulnerabilities to be identified should not be applied when a pipeline has not even been run.
The require_approval
action type should not come into play as the docs note:
This action sets an approval rule to be required when conditions are met for at least one rule in the defined policy.
However, none of the conditions for the policy have been met.
Relevant logs and/or screenshots
Output of checks
Results of GitLab environment info
Expand for output related to GitLab environment info
(For installations with omnibus-gitlab package run and paste the output of: `sudo gitlab-rake gitlab:env:info`) (For installations from source run and paste the output of: `sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)
Results of GitLab application Check
Expand for output related to the GitLab application check
(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:check SANITIZE=true
)(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true
)(we will only investigate if the tests are passing)
Possible fixes
Workarounds
Workarounds for this behavior include:
- Have the listed approvers Approve the MR
- Remove the scan result policy