behavior of branches clause in scan finding rules is not as documented - unprotected branches get guarded
Summary
A customer contacting Support to report that merge requests to unprotected branches were triggering branches: []
scan_finding policies. GitLab team members can find out more in the ticket
the documentation have been revised a couple of times, and now states that branches
specifies:
Applicable only to protected target branches. An empty array, [], applies the rule to all protected target branches.
Steps to reproduce
To follow. I will run through this in a new project.
-
create a group, example:
mygroup
in GitLab to contain the test project and policy project -
create repo locally. Initialize it with CI config. Push default branch to GitLab.
mkdir somedirectory cd somedirectory git init . cat > .gitlab-ci.yml <<EOF include: - template: Jobs/Dependency-Scanning.gitlab-ci.yml EOF git add .gitlab-ci.yml git commit -a -m 'init' git remote add origin <remote> git push -u origin HEAD
where is one of:
git@gitlab.example.com:mygroup/testproject.git https://gitlab.example.com/mygroup/testproject.git
-
Create the scan policy.
-
Security & Compliance > Policies
-
New policy
-
Scan result policy: Select policy
-
yaml mode
-
substitute a valid user for
johndoe_
-
ensure the user has access to the group and has developer or greater permissions.
type: scan_result_policy name: 'my policy' description: 'require approval for vulnerabilities' enabled: true rules: - type: scan_finding branches: [] scanners: [] vulnerabilities_allowed: 0 severity_levels: - critical - high - medium - low vulnerability_states: - newly_detected - detected - confirmed actions: - type: require_approval approvals_required: 1 user_approvers: - johndoe_
-
merge
-
note:
severity_levels
andvulnerability_states
set like this to ensure
-
-
settings > repository > protected branches - confirm the default branch (likely
main
ormaster
) is protected -
create an unprotected branch
git checkout -b play git push -u origin HEAD
-
create a feature branch; push it and open a MR to the default branch.
-
Note reference to master - change this to
main
if that's your default branch
git checkout -b vulns # # copy package.json and yarn.lock from https://gitlab.com/gitlab-examples/security/yarn-vulnerabilities # git add package.json yarn.lock git commit -a -m 'add vulns' ## master in next line! git push -o merge_request.create -o merge_request.target=master \ -o merge_request.title="merge vulns to protected branch" \ -o merge_request.description="merge vulns to protected branch" \ -u origin HEAD
-
Note reference to master - change this to
-
create a feature branch; push it and open a MR to the unprotected branch.
git checkout -b vulns2play git push -o merge_request.create -o merge_request.target=play \ -o merge_request.title="merge vulns to unprotected branch" \ -o merge_request.description="merge vulns to unprotected branch" \ -u origin HEAD
-
MR to protected branch:
-
MR to unprotected branch:
Example Project
Detailed instructions provided to reproduce this. I didn't realise that the source project for the vulnerabilities wasn't public .. if there's an example we can use that's public, I can push it to gitlab.com.
What is the current bug behavior?
Merges to unprotected branches are triggering scan result policies.
What is the expected correct behavior?
Merges to unprotected branches should not trigger scan result policies.
Relevant logs and/or screenshots
Output of checks
15.5