Scan result policy MR approval are not enforced correctly when pipeline contains manual security job
Summary
When an MR pipeline has manual security scan job, the scan result policy does not enforce approval since the security scan results are not present. When the manual job is triggered and complete, the approvals are not enforced even when the pipeline detects vulnerabilities that fails the policy condition.
Steps to reproduce
- Create project, and create a new branch and make this branch a protected branch.
- Add a scan result policy that requires approval when new vulnerabilities are detected:
name: SRP
description: ''
enabled: true
actions:
- type: require_approval
approvals_required: 1
group_approvers_ids:
- 15017953
rules:
- type: scan_finding
scanners:
- dependency_scanning
- sast
vulnerabilities_allowed: 0
severity_levels:
- critical
- high
- medium
vulnerability_states: []
branch_type: protected
- Add
.gitlab-ci.yml
file to the new branch you created in Step 1 and make one of the security scan as manual:
semgrep-sast:
stage: test
script:
- cp gl-sast-report_no_vulnerabilities.json gl-sast-report.json
artifacts:
paths:
- gl-sast-report.json
reports:
sast:
- gl-sast-report.json
gemnasium-maven-dependency_scanning:
stage: test
when: manual
script:
- cp gl-dependency-scanning-report_no_findings.json gl-dependency-scanning-report.json
artifacts:
paths:
- gl-dependency-scanning-report.json
reports:
dependency_scanning:
- gl-dependency-scanning-report.json
Add these files to the project:
gl-sast-report_no_vulnerabilities.json
gl-dependency-scanning-report_no_findings.json
- Commit the changes to the branch and create a new MR.
- Once the MR pipeline runs, it will find no vulnerabilities and the Approvals will be optional.
- Edit the
.gitlab-ci.yml
and also add the attached files to introduce somedast
vulnerabilities:
semgrep-sast:
stage: test
script:
- cp gl-sast-report_no_vulnerabilities.json gl-sast-report.json
artifacts:
paths:
- gl-sast-report.json
reports:
sast:
- gl-sast-report.json
gemnasium-maven-dependency_scanning:
stage: test
when: manual
script:
- cp gl-dependency-scanning-report_with_findings.json gl-dependency-scanning-report.json
artifacts:
paths:
- gl-dependency-scanning-report.json
reports:
dependency_scanning:
- gl-dependency-scanning-report.json
gl-dependency-scanning-report_with_findings.json
- Commit the changes to the branch.
- After the pipeline passes, trigger the manual job and verify dependency_scanning has found new vulnerabilities; however MR approval for the scan result policy shows optional and MR can be merged.
Example Project
https://gitlab.com/gitlab-org/govern/security-policies/sashis-test-group/test-419789
What is the current bug behavior?
MR approval is optional even though the scan configured in the scan result policy found new vulnerabilities that match criteria.
What is the expected correct behavior?
MR approval should be required when new vulnerabilities are found for manual job
Relevant logs and/or screenshots
Output of checks
This bug happens on GitLab.com /label reproduced on GitLab.com
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)