### Summary When implementing a policy, such as a [Scan Execution Policy](https://docs.gitlab.com/user/application_security/policies/scan_execution_policies/), you can select projects to be excluded from the project scope. When this policy is defined at a sub-group level, the exclusion dropdown will populate projects from the top-level group. This includes projects that will not be applicable to the policy scope: In path `flightjs/test`:  This example shows three projects which are not in the `flightjs/test` group path, and should not be considered for the policy scope. ### Steps to reproduce 1. Create a subgroup with projects. 2. Create projects in the top-level group. 3. Attempt to create a Scan Execution Policy. 4. Under `Policy Scope`, select an exclusion list with `except projects`, and review the dropdown. ### What is the current *bug* behavior? Projects outside the scope of the policy are presented ### What is the expected *correct* behavior? Only projects within the subgroup path should be displayed. ### Possible fixes I discussed this with @kenneth during a pairing call. They helped to identify that this may have been occurring as a result of [this merge request](https://gitlab.com/gitlab-org/gitlab/-/commit/4341efde8d8f3f485d0a8d003b577b8db9000b61) where the logic was changed. Within this file specifically (`ee/app/assets/javascripts/security_orchestration/components/shared/group_projects_dropdown.vue`)[https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/assets/javascripts/security_orchestration/components/shared/group_projects_dropdown.vue?ref_type=heads#L158], we can see a reference to the path variable being defined as the full group path, likely of the parent. <!-- If you don't have /label privileges, follow up with an issue comment of `@gitlab-bot label ~"type::bug"` -->