Detach admin_vulnerability from read_vulnerabiliy

What does this MR do and why?

It detaches admin_vulnerabilities from simple read_security_resource and read_vulnerability. This is a preparation for custom roles, when a certain role can read vulnerabilities but not admin them.

Before this change, enabling read_security_resource enables both read_vulnerability and admin_vulnerability.

This was ok for static roles as developer can both read and admin (= change status) vulnerabilities. But with custom roles, we want that a role can enable only read_vulnerability.

With the current implementation, whenever a custom role enables read_vulnerability it also enables read_security_resource (that is needed for proper loading of associated objects) which leads to enabling admin_vulnerability through mentioned rule.

Screenshots or screen recordings

Users without permissions to change the status

Users with permissions to change the status

How to set up and validate locally

Prerequisity - create a custom role and assign it to a user

1. Enable feature flag Feature.enable(:custom_roles_vulnerability)
2. Creates a personal access token with the API scope.
3. Pick a group with at least one project (project), pick a user who is member of this project (gues access level) - user
4. Check if a user can access the vulnerability page of the project (eg. https://gdk.test:3443/flightjs/Flight/-/security/vulnerability_report), they should not be able to access it
5. Create a custom role using the API: https://docs.gitlab.com/ee/api/member_roles.html#add-a-member-role-to-a-group
   • curl --request POST --header "Content-Type: application/json" --header "Authorization: Bearer $YOUR_ACCESS_TOKEN" --data '{"base_access_level" : 10, "read_vulnerability" : true}' "https://gdk.test:3443/api/v4/groups/$YOUR_GROUP_ID/member_roles"
   • You can also test with base_access_level = 10 which should not work (minimal base access level is reporter)
6. Associates the member with the role using the Group and Project Members API endpoint
   • curl --request PUT --header "Content-Type: application/json" --header "Authorization: Bearer $YOUR_ACCESS_TOKEN" --data '{"member_role_id": '$MEMBER_ROLE_ID', "access_level": 10}' "https://example.gitlab.com/api/v4/projects/$ID/members/$GUEST_USER_ID"

Workflow test

• pick a project
• go to a vulnerabilities page (eg. http://localhost:3000/flightjs/Flight/-/security/vulnerability_report)
• open a vulnerability detail (eg. http://localhost:3000/flightjs/Flight/-/security/vulnerabilities/196)
• change its status
  • with a user with at least developer access to the project and - this should work
  • with a with assigne custom role that enables read_vulnerabilities - this should not work

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.