IaC Scanning should differentiate better between linting/quality and security

Problem

IaC scanning uses a ruleset that includes various categories. Not all of these categories are security-relevant; for example, "Best Practices" or "Build Process" arguments flag what are essentially code quality or linting concerns.

Mixing the two together makes it much harder for a security-minded customer to use IaC SAST findings in approval workflows and otherwise get a handle on the security concerns they should be paying attention to.

Proposal

Identify whether there are understandable, maintainable ways to split up the rules such that we focus on security-relevant rules in SAST IaC Scanning. This could be based on categories (preferable) or identification of individual rules (more difficult to maintain).

kics provides various options for controlling which rules ("queries") are excluded or included.

It would be reasonable for us to control the ruleset by maintaining an allowlist of intended rules. This would prevent us from surprising customers with new irrelevant rules, though it would require us to review new queries on a regular basis to decide whether to include them.

This is probably not a great idea for UX consistency, but we could even play with having the analyzer output quality results as a Code Quality report, and security results as a SAST report (same as today).

References

A customer (internal SFDC link, internal shared Slack link) reported that some results aren't useful from a security perspective. The kics analyzer:

includes things like marking what I'd consider to be stylistic issues in Terraform such as resource naming, which isn't really what I want from a security scanning tool.

kics also has secret detection rules, which further muddies the situation (see Disable secret detection in KICS SAST IAC scanner (#346181 - closed)).