Ignore security_auto_triage bugs in Triage report

What does this MR do and why?

Do not report issues labelled ~security_auto_triage in the weekly triage report.

Issues with this label are automatically created by a process related to FedRAMP compliance, and are outside the scope of the weekly triage report.

Including these issues in the triage report makes it less useful due to noise. Additionally, the Product Manager isn't involved in the FedRAMP vulnerability process but has to filter through the issues in the Triage Report.

Example: https://gitlab.com/gitlab-org/quality/triage-reports/-/issues/14779#unscheduled-bug-non-customer

A similar decision was made in https://gitlab.com/gitlab-org/gitlab/-/issues/425843#note_1567683142, where issues with risk treatmentoperational requirement are ignored in Sisense dashboards.

Expected impact & dry-runs

These are strongly recommended to assist reviewers and reduce the time to merge your change.

See https://gitlab.com/gitlab-org/quality/triage-ops/-/tree/master/doc/scheduled#testing-policies-with-a-dry-run on how to perform dry-runs for new policies.

See https://gitlab.com/gitlab-org/quality/triage-ops/-/blob/master/doc/reactive/best_practices.md#use-the-sandbox-to-test-new-processors on how to make sure a new processor can be tested.

Action items

• If adding environment variables for reactive processors, update config/triage-web.yaml and .gitlab/ci/triage-web.yml
• (If applicable) Add documentation to the handbook pages for Triage Operations =>
• (If applicable) Identify the affected groups and how to communicate to them:
  • /cc @person_or_group =>
  • Relevant Slack channels =>
  • Engineering week-in-review