Add business_unit scope to security policies

What does this MR do and why?

This change adds support for scoping security policies using security attributes from the business_unit category.

Previously, security policies could be scoped to specific projects, groups, and compliance frameworks. Now policies can also be configured to include or exclude projects based on their business_unit classification (such as "Engineering").

This addition is similar to the work we did in !228920 (merged), and !229939 (merged). This MR also includes the refactoring suggested in this comment from the MR !229939 (merged).

To avoid making this MR bigger, the policy re-sync trigger for policies using security attributes from the business_unit security category will be added in !232384 (merged).

Database queries

SELECT
    "security_categories"."template_type",
    "security_attributes"."id"
FROM
    "security_attributes"
    INNER JOIN "project_to_security_attributes" ON "security_attributes"."id" = "project_to_security_attributes"."security_attribute_id"
    INNER JOIN "security_categories" ON "security_categories"."id" = "security_attributes"."security_category_id"
WHERE
    "project_to_security_attributes"."project_id" = 80550984
    AND "security_attributes"."deleted_at" IS NULL
    AND "security_categories"."deleted_at" IS NULL
LIMIT 1000

https://postgres.ai/console/gitlab/gitlab-production-sec/sessions/51211/commands/151552

References

Related to: #596631 (closed)

How to set up and validate locally

1. Create a new group
2. Go to Secure > Security Configuration
3. Click in Business Unit
4. Click in Create attribute
5. Add a name(e.g Engineering) and description(e.g Engineering Applications)
6. Click in Add attribute
7. Click in Save changes
8. Create a new project
9. Add a .gitlab-ci.yml file with the content:

include:
- template: Jobs/SAST.gitlab-ci.yml

10. Go to Secure > Security Configuration
11. Select Security attributes
12. Click on Edit project security attributes
13. Select the Application security attribute created in step 6(e.g Engineering)
14. Click in save changes
15. Go back to the group created in step 1
16. Go to Secure > Policies
17. Click on New policy
18. Select Merge request approval policy
19. Create a policy to block new vulnerabilities on Finance projects
20. Get the security_attribute id

category = Security::Category.where(template_type: "business_unit", namespace: Group.last)
Security::Attribute.where(security_category: category).where(name: "Engineering").first

21. Create a policy like

approval_policy:
  - name: Test
    description: ''
    enabled: true
    rules:
      - type: scan_finding
        branches: []
        vulnerabilities_allowed: 0
        severity_levels: []
        vulnerability_states: []
        scanners:
          - type: sast
            vulnerabilities_allowed: 0
            severity_levels:
              - critical
              - high
            vulnerability_states:
              - new_needs_triage
            vulnerability_attributes:
              false_positive: false
    policy_scope:
      business_unit:
        including:
          - id: <security_attribute_id>
    actions:
      - type: require_approval
        approvals_required: 1
        role_approvers:
          - developer

22. Click on Create new project with the new policy
23. Merge the MR to add the policy
24. Go back to the project created in step 8
25. Create a MR adding the file vuln.rb with the content

class RunScript
  def run_script
    system("cat #{params[:path]}") 
  end
end

26. Verify the MR is blocked
27. Create another project
28. Add a .gitlab-ci.yml file with the content:

include:
- template: Jobs/SAST.gitlab-ci.yml

29. Create a MR with the same vuln.rb and verify the MR is not blocked.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.