Enforce approval rules based on attributes

What does this MR do and why?

This enforces security policy approval rules based on vulnerability attributes. The attributes configuration was introduced with !123640 (merged). Possible attributes are false_positive and fix_available.

Example: Require approval only if vulnerability findings are not false positives and there is a fix_available

Database

This MR adds new scopes to ee/app/models/security/finding.rb. I ran an example query that uses the new scopes. Here is the result:

https://console.postgres.ai/gitlab/gitlab-production-tunnel-pg12/sessions/20224/commands/66232

Time: 4.330 ms
  - planning: 3.883 ms
  - execution: 0.447 ms
    - I/O read: 0.000 ms
    - I/O write: 0.000 ms

Shared buffers:
  - hits: 24 (~192.00 KiB) from the buffer pool
  - reads: 0 from the OS file cache, including disk I/O
  - dirtied: 0
  - writes: 0

How to set up and validate locally

1. Switch to the 399117-enforce-security-policy-vulnerability_attributes-rules branch.
2. Create a new policy
   1. Create a project
   2. Add a .gitlab-ci.yml with secret detection (See .gitlab-ci.yml with secret detection example).
   3. On the left sidebar, select Security & Compliance and Policies.
   4. Select New Policy.
   5. Select Scan result policy.
   6. For Name choose any name.
   7. For Rules choose "when Security Scan Secret Detection runs against the All protected branches and find(s). Any vulnerabilities that match all of the following criteria:".
   8. Select Add new criteria and New severity
   9. Choose Select all
   10. In Actions Select "Require 1 approval from:".
   11. Select any user that is not you.
   12. Switch to .yaml mode.
   13. Add attributes below vulnerability_states: [].

   vulnerability_attributes:
     false_positive: false
     fix_available: false

   14. Alternatively to steps 5 to 13, you can switch to .yaml mode and copy the Policy example below. And replace the user_approvers_ids with a valid user ID that has access to the project.
   15. Select Configure with a merge request.
   16. Merge the MR.
3. Produce an MR with a vulnerability finding.
   1. If you haven't already, set up a runner with docker.
   2. Go to the project page and select the Web IDE button.
   3. Create a new file called .env.
   4. Add the following line to the file AWS_TOKEN='AKIAZYONPI3G4JNCCWGA'.
   5. Commit the changes to a new branch and start an MR.
   6. The pipelines security tab should show one finding.
4. Verify the feature
   1. The MR should require an approval after the pipeline finishes.
   2. Go back to edit the policy and change false_positive to true.
   3. The MR should not require an approval anymore.
   4. Go back to edit the policy and change false_positive to false again.
   5. The MR should require an approval.
   6. Go back to edit the policy and change fix_available to true.
   7. The MR should not require an approval anymore.

`.gitlab-ci.yml` with secret detection

# .gitlab-ci.yml

include:
  - template: Jobs/Secret-Detection.gitlab-ci.yml
test-job:
  script:
  - echo "Test Job..."

Policy example

type: scan_result_policy
name: sdfsdf
description: ''
enabled: true
rules:
  - type: scan_finding
    branches: []
    scanners:
      - secret_detection
    vulnerabilities_allowed: 0
    severity_levels:
      - critical
      - high
      - medium
      - low
      - unknown
      - info
    vulnerability_states: []
    vulnerability_attributes:
      false_positive: false
      fix_available: false
actions:
  - type: require_approval
    approvals_required: 1
    user_approvers_ids:
      - 82

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.

Related to #399117 (closed)