Policy scoping should only enforce against projects with a compliance framework label within the group or sub-group where defined
Description
Within the following test subgroup, https://gitlab.com/haven-group/omega-capital, I came across an unexpected behavior for policy scoping. As I'm creating policies at the sub-group level, the intent is to apply the scopes to projects in the sub-group with a given compliance framework label. However, I noticed a policy being enforced on a merge request that was not defined here.
Here's the example merge request. See the "LACA" policy.
This wasn't created in the sub-group, rather, it was created in a different subgroup, https://gitlab.com/haven-group/jaynestown. The "Basic Approval Policy targeting "Web Application Security" Compliance Framework" policy is another one that is created in Jaynestown.
See the YAML for Jaynestown - Security policy project
---
scan_result_policy:
- name: License Approval Policy (LACA)
description: This security policy enforces license compliance based on our LACA
team's requirements.
enabled: true
rules:
- type: license_finding
match_on_inclusion: true
license_types:
- BSD-2-Clause Plus Patent License
- Amazon Digital Services License
- Apache License 2.0
- Apache 2.0
- Adobe Postscript AFM License
- BSD 1-Clause License
- BSD 2-Clause "Simplified" License
- BSD 2-Clause FreeBSD License
- BSD 2-Clause NetBSD License
- BSD 2-Clause with views sentence
- Boost Software License 1.0
- DSDP License
- Educational Community License v1.0
- Educational Community License v2.0
- ImageMagick License
- ISC License
- ISC
- Linux Kernel Variant of OpenIB.org license
- MIT
- MIT License
- Microsoft Public License
- Mulan Permissive Software License, Version 1
- Mup License
- PostgreSQL License
- Spencer License 99
- Universal Permissive License v1.0
- Xerox License
- BSD Zero Clause License
- Academic Free License v1.1
- Academic Free License v1.2
- Academic Free License v2.0
- Academic Free License v2.1
- Academic Free License v3.0
- AMD's plpa_map.c License
- Apple MIT License
- Academy of Motion Picture Arts and Sciences BSD
- ANTLR Software Rights Notice
- Apache License 1.0
- Apache License 1.1
- Artistic License 2.0
- Bahyph License
- Barr License
- BSD 3-Clause "New" or "Revised" License
- BSD 3-Clause Clear License
- BSD 3-Clause No Nuclear License
- BSD 3-Clause No Nuclear License 2014
- BSD 3-Clause No Nuclear Warranty
- BSD 3-Clause Open MPI variant
- BSD 4-Clause "Original" or "Old" License
- BSD Source Code Attribution
- Lawrence Berkeley National Labs BSD variant license
- bzip2 and libbzip2 License v1.0.5
- bzip2 and libbzip2 License v1.0.6
- Creative Commons Zero v1.0 Universal
- CNRI Jython License
- CNRI Python License
- CNRI Python Open Source GPL Compatible License Agreement
- Cube License
- curl License
- eGenix.com Public License 1.1.0
- Entessa Public License v1.0
- Freetype Project License
- IBM PowerPC Initialization and Boot Software
- ICU License
- Info-ZIP License
- Intel Open Source License
- JasPer License
- libpng License
- PNG Reference Library version 2
- libtiff License
- LaTeX Project Public License v1.3c
- MIT No Attribution
- Enlightenment License (e16)
- CMU License
- enna License
- feh License
- MIT +no-false-attribs license
- Matrix Template Library License
- Mulan Permissive Software License, Version 2
- Multics License
- Naumen Public License
- University of Illinois/NCSA Open Source License
- Net-SNMP License
- NetCDF license
- NTP License
- Open LDAP Public License 2.2.2
- Open LDAP Public License v2.0 (or possibly 2.0A and 2.0B)
- Open LDAP Public License v2.0.1
- Open LDAP Public License v2.1
- Open LDAP Public License v2.2
- Open LDAP Public License v2.2.1
- Open LDAP Public License v2.3
- Open LDAP Public License v2.4
- Open LDAP Public License v2.5
- Open LDAP Public License v2.6
- Open LDAP Public License v2.7
- Open LDAP Public License v2.8
- Open Market License
- OpenSSL License
- PHP License v3.0
- PHP License v3.01
- Plexus Classworlds License
- Python Software Foundation License 2.0
- Python License 2.0
- Ruby License
- Saxpath License
- SGI Free Software License B v2.0
- Standard ML of New Jersey License
- Scheme Widget Library (SWL) Software License Agreement
- TCL/TK License
- TCP Wrappers License
- Unicode License Agreement - Data Files and Software (2015)
- Unicode License Agreement - Data Files and Software (2016)
- The Unlicense
- Vovida Software License v1.0
- W3C Software Notice and License (2002-12-31)
- X11 License
- XFree86 License 1.1
- X.Net License
- XPP License
- zlib License
- Zlib
- zlib/libpng License with Acknowledgement
- Zope Public License 2.0
- Zope Public License 2.1
license_states:
- newly_detected
branch_type: default
actions:
- type: require_approval
approvals_required: 0
user_approvers_ids:
- 12519240
approval_settings:
block_protected_branch_modification:
enabled: true
- name: Basic Approval Policy targeting "Web Application Security" Compliance Framework
description: Requires 1 approval from any role (Owner, Maintainer, Developer)
enabled: true
policy_scope:
compliance_frameworks:
- id: 3357
rules:
- type: any_merge_request
branch_type: default
commits: any
actions:
- type: require_approval
approvals_required: 1
role_approvers:
- developer
- maintainer
- owner
approval_settings:
block_branch_modification: false
prevent_pushing_and_force_pushing: false
prevent_approval_by_author: false
prevent_approval_by_commit_author: false
remove_approvals_with_new_commit: false
require_password_to_approve: false
Note: I've shared the info above from my demo group but will be working to create a demo and will remove this conflict by removing the scoping in policies I had listed in Jaynestown, so I have a clean demo.
Reproduce
- Create two subgroups
- Create policies within the two subgroups that enforce against the same compliance framework label
- Observe that any projects in the group with the label are enforced (when instead the enforcement should filter to only projects within the same subgroup)
Expected Behavior
Policies should be enforced down the tree view, so policies at any group are enforced against all subgroups/projects under it.Policies created at the sub-group are then enforced down to any sub-groups / projects underneath it. The exception may be that a project can link up to any security policy project directly. So, in this case, there isn't a link to the security policy project containing the LACA policy, and the policy is created under a different subgroup. This is not desirable as for our customers, if policies are created within different sub-groups, they could be intended to be enforced only within their business unit, and different groups could accidentally impact others.
What's interesting is that my understanding with policies is that a link is required between the group, subgroup, or project and the SPP. In this case, a link should be created between a single subgroup and the projects. The scope should then only apply to projects with the subgroup as the SPP is linked to the subgroup. It appears the label is taking precedence in the scope in spite of the SPP linking.