feat(aws): Add check for malicious AMI detection

[simar7]

AVD-AWS-0344 (LOW): AWS AMI data source should specify owners to ensure AMIs come from trusted sources
═══════════════════════════════════════════════════════════════════════════════════════
AWS AMI data source should specify owners to avoid using unverified AMIs.
The owners field helps ensure you're using AMIs from known and trusted sources.


See https://avd.aquasec.com/misconfig/avd-aws-0344
───────────────────────────────────────────────────────────────────────────────────────
 bad.tf:6-12
───────────────────────────────────────────────────────────────────────────────────────
   6 ┌ data "aws_ami" "example_ami" {
   7 │   most_recent = true
   8 │   filter {
   9 │     name   = "name"
  10 │     values = ["my-custom-ami"] 
  11 │   }
  12 └ }
─────────

Related PRs:

• feat(misconf): Add support for aws_ami trivy#8499

[nikpivkin]

We need to find a way for Trivy to skip checks that it doesn't support. If we release a new check whose input is validated by a schema (e.g. cloud), old versions of Trivy will get an error when trying to compile such a check. Although Trivy will skip checks with compile-time errors, if the error limit is reached (currently 10), Trivy will terminate. Alternatively, we can add a compatibility field to the checkout metadata and check the version of Trivy, but this will not work if Trivy is not officially built.

[simar7]

Although Trivy will skip checks with compile-time errors, if the error limit is reached (currently 10), Trivy will terminate.

Although not perfect, we should not have any checks in production that aren't compilable. As far as the limit is concerned, I think we could bump it up to a high number so that we don't run into an issue where this limit becomes the limiting factor for people to upgrade to a newer Trivy release.

Having said that there are two options on the table:

Distinguishing compiler failures vs incompatible checks

Today we don't have any mechanism to do this as demonstrated in this PR. One way as you suggested could be to add a compatibility field but this will force us to track each check with each Trivy release that it will correspond to. IOW we would have to know which Trivy release the support for will be added for the particular check that we are writing.

Schema-less checks

This might be the opportunity to remove schema completely from our checks. It would not let us type check but also not bind us to a particular schema where cases like this PR can occur. The checks would simply not evaluate as the fields would be unknown.

[nikpivkin]

Need to update the check since the schema in Trivy has been changed.