Closes #7212

Reason for Proposed Changes

• This query is meant to ensure all security groups that exist are used, but, currently, it only supports single values for security_group_id declarations inside modules. These modules support array based declaration of this sort : security_group_id = [aws_security_group.test.id] so the query should be adjusted to prevent FP due to lack of proper array case handling.
• After thorough analysis of the query´s logic itself i found it to have redundant policy declarations that did not align with other queries conventional, much more readable, logic.
• During testing, i realized a critical mistake in the contains policy use; basically the policy is written in a way that allows for easy FNs to occur in case , for example, a security resource is declared with the name "test" and then , when ensuring the use of this resource, we find something like "test_2". The "test_2" serves as confirmation of "test"´s usage due to only relying on a comparison that is equivalent to prefix matching.

Proposed Changes

• I expanded on the terraform-aws-modules/security-groups/aws case handling that was already there to allow the use of arrays; but also streamlined the needlessly large amount of policies from the original query to rely on a get_security_groups_if_exists policy instead, a policy that is very much alike the ones found in terraform.rego (library of common use case policies).

• Given that the current implementation does not account for trailing character of text when comparing group names, I have enforced the name that we are searching for to be encased in "." , in doing this i am assuming all use cases are as follows:

  • aws_security_group.our_resource_name.id

• This is corroborated by our list of tests, even if the id field is somehow given a different name as long as we are searching for a specific field inside that group this will ensure proper full name matching.

• Finally the negative and positive tests added are to ensure, respectively, that the currently unsupported arrays are handled properly and that a name with equivalent prefix that has trailing characters compared to the resource´s name does not prevent it form being flagged.

Note : I also could not help but notice how my new policy get_security_groups_if_exists is not catching every possible scenario for security_groups, but seen as though i do not have access to files that confirm the FPs that might arise from this i will leave it as is; given this changes it should be simple to add any case handling needed by updating the new policy.

I submit this contribution under the Apache-2.0 license.