Backport of 'Map sast_iac scanner to sast in approval policy rules'

What does this MR do and why?

Backports !267407 (merged) to 19-4-stable-ee.

Approval policies that list sast_iac under a scan_finding rule's scanners never get an approval rule. The policy schema accepts the value, but ApprovalProjectRule only accepts security report types, so the whole scanners list fails validation and no approval rule is created. The failure is only logged at debug level, so the policy silently does nothing. The fix maps sast_iac to sast (the report type IaC scanning uses) when the rule is read, and removes duplicate scanners.

Original issue: #637971 (severity 2, bug::functional).

Why backport: the bug leaves affected approval policies unenforced with no visible error, and there is no workaround short of editing the policy. The change is small (Reviewable LOC 14 plus specs), has no feature flag and no migrations.

Cherry-pick: git cherry-pick -x -m1 63301495fdcb412c190dc43be452993ac2eb5679. One trivial conflict in ee/lib/security/scan_result_policies/rule.rb: on master the new normalize_scanner_type method sits next to dependency_filter, which does not exist on this branch. I kept only normalize_scanner_type. The rest of the diff applied as-is.

Policies that were already affected need resyncSecurityPolicies after the fix is deployed.

MR acceptance checklist

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

  • This MR is backporting a bug fix, documentation update, or spec fix, previously merged in the default branch.
  • The MR that fixed the bug on the default branch has been deployed to GitLab.com (not applicable for documentation or spec changes).
  • The MR title is descriptive (e.g. "Backport of 'title of default branch MR'"). This is important, since the title will be copied to the patch blog post.
  • Required labels have been applied to this merge request
  • This MR has been approved by a maintainer (only one approval is required).
  • Ensure the E2E Omnibus GitLab EE pipeline (triggered by thee2e:test-on-omnibus-ee job) has succeeded. If it has failed (or shows warnings), investigate the failures. If you determine the failures are unrelated, you may proceed. If you need assistance investigating, request help in the #s_developer_experience Slack channel to confirm the failures are unrelated to the merge request.

Note to the merge request author and maintainer

If you have questions about the patch release process, please:

Merge request reports

Loading
Loading