✨ Add missing AWS runtime and CloudFormation check variants

[tas50]

Summary

Fills in missing variants across mondoo-aws-security.mql.yaml so checks run against the live AWS runtime and CloudFormation templates, not only Terraform assets. Started from the three checks flagged manually, then swept the policy with inspect-policies.py for other genuinely-addable variants.

New variants

Check	Added
route53-resolver-query-logging-enabled	aws runtime + cloudformation
datasync-task-cloudwatch-logging-encryption	cloudformation
ecr-no-public-access	cloudformation
eks-cluster-private-controlplane	cloudformation
cloudfront-sni-only	cloudformation
rds-cluster-parameter-group-ssl	cloudformation
eks-nodegroup-encrypted-volumes	cloudformation

Each new cloudformation variant lines up with an existing id: cloudformation remediation entry; route53-resolver and datasync also gained the matching CloudFormation remediation block.

Fixes pulled in along the way

• Removed a stale comment that claimed the provider doesn't expose Route 53 Resolver query log configs — it does (aws.route53.resolver.queryLogConfigAssociations), so the runtime variant is now real.
• Fixed two CloudFormation remediation property-name bugs found while verifying against the real CFN spec:
  • AWS::EKS::Cluster → ResourcesVpcConfig (was VpcConfig)
  • AWS::CloudFront::Distribution ViewerCertificate → SslSupportMethod (was SSLSupportMethod)
• Reworded all cnquery → mql in the # No runtime variant: comments, and removed a duplicate Kinesis Video comment.

Intentionally not added

These were flagged by the script but are genuinely not addable, and stay documented in-line:

• kinesis-video-stream-cmk-encryption (aws) — the mql aws.kinesis resource exposes only Data Streams/Firehose, not Kinesis Video.
• datasync-task-... (aws) — no DataSync resource in the provider.
• ssm-document-not-public (CFN) — document sharing isn't a CloudFormation property.
• ec2-snapshot-not-public (CFN) — no CloudFormation snapshot-sharing resource.
• ec2-launch-template-no-secrets (CFN) — UserData is base64-encoded in CloudFormation, so the secret-detection regexes can't match.
• cloudfront-trust-store-not-empty (CFN) — no corresponding CloudFormation resource type.

Many other "MISSING aws" rows from the script are false positives: the runtime variant exists under a resource-specific suffix (-distribution, -cluster) the script doesn't recognize.

Test plan

• cnspec policy lint content/mondoo-aws-security.mql.yaml → valid policy bundle (only pre-existing query-deprecated-symbol warnings remain).

🤖 Generated with Claude Code

[mondoo-code-review]

Well-structured addition of CloudFormation check variants and minor fixes; one check has a potential false-negative logic issue.

[github-actions]

Test Results

  1 files  ±0   44 suites  ±0   1m 24s ⏱️ -15s
854 tests ±0  853 ✅ ±0  1 💤 ±0  0 ❌ ±0 
855 runs  ±0  854 ✅ ±0  1 💤 ±0  0 ❌ ±0 

Results for commit 5ac05ff. ± Comparison against base commit 5c0d2f3.

♻️ This comment has been updated with latest results.

[tas50]

Addressed the review feedback in 2aa6c25:

• ECR Statement guard (ecr-no-public-access-cloudformation): added properties['RepositoryPolicyText']['Statement'] == empty || ahead of .none(...), so a repository policy with no Statement passes instead of evaluating .none() against a missing/null key.
• EKS node group launch-template scope: added a comment documenting that the CloudFormation variant inspects every launch template in the stack — matching the existing Terraform hcl/plan/state variants, which also scan all aws_launch_template resources. Narrowing to only EKS-referenced templates would require cross-resource correlation that none of the variants do, and would diverge from the runtime/Terraform behavior, so I documented the scope rather than changing it.
• CloudFront SslSupportMethod casing: confirmed — the MQL check uses properties['DistributionConfig']['ViewerCertificate']['SslSupportMethod'] (matching the CloudFormation property). The remaining SSLSupportMethod occurrences are in CLI/API --query strings, where the AWS API field genuinely is SSLSupportMethod; only the CloudFormation property name differs. No change needed there (thanks @tas50 for confirming).

cnspec policy lint remains clean.

[mondoo-code-review]

Well-structured addition of CloudFormation check variants and runtime checks with minor correctness concerns

[tas50]

/review

[mondoo-code-review]

Well-structured addition of CloudFormation check variants and bug fixes for AWS property names; one check only verifies logging presence but not the encryption requirement stated in its title.

[mondoo-code-review]

Well-structured addition of CloudFormation check variants and runtime checks with minor issues in the CloudFront SNI check and a naming inconsistency.

[mondoo-code-review]

Well-structured addition of CloudFormation check variants and runtime checks with minor correctness concerns

[mondoo-code-review]

Well-structured addition of CloudFormation check variants and AWS runtime checks with minor correctness concerns

[mondoo-code-review]

Well-structured PR adding CloudFormation check variants and fixing property names; one check title mismatch and a minor logic concern worth noting.

[mondoo-code-review]

Well-structured addition of CloudFormation check variants and AWS runtime checks with minor correctness concerns

[mondoo-code-review]

Well-structured addition of CloudFormation check variants and AWS runtime checks with minor correctness concerns

Additional findings (file/line not in diff):

• 🔵 content/mondoo-aws-security.mql.yaml:48549 — The CloudFormation DataSync task check only verifies CloudWatchLogGroupArn != empty but the check title says "logging encryption". Unlike the Terraform variant which can cross-reference the log group's KMS key, this CloudFormation variant doesn't verify the referenced log group actually uses a CMK. Consider adding a comment noting this limitation, or cross-checking AWS::Logs::LogGroup resources for KmsKeyId.

[mondoo-code-review]

Well-structured addition of CloudFormation check variants and AWS runtime checks with minor correctness concerns

[mondoo-code-review]

Well-structured addition of CloudFormation check variants and AWS runtime checks with minor issues

Additional findings (file/line not in diff):

• 🔵 content/mondoo-aws-security.mql.yaml:67700 — The Route 53 Resolver runtime check uses a string-join trick ("," + ... + ",") to avoid substring false positives. This is clever but fragile — if VPC IDs ever contain commas or if the API returns unexpected whitespace, it could break. Consider adding a brief inline comment explaining this assumption (that VPC IDs are always vpc-xxxx format with no commas/spaces).
• 🔵 content/mondoo-aws-security.mql.yaml:48977 — The EKS nodegroup encrypted volumes CloudFormation check flags all AWS::EC2::LaunchTemplate resources, not just those referenced by EKS node groups. The comment explains this intentional design, which is good. Just noting that this is a broader scope than the check title implies — users may get unexpected findings for non-EKS launch templates.

[mondoo-code-review]

Well-structured PR adding CloudFormation check variants and a Route 53 runtime check, with minor correctness concerns

[mondoo-code-review]

Well-structured addition of CloudFormation check variants and minor fixes; one check only verifies logging presence but not encryption as the title promises.

[mondoo-code-review]

Well-structured addition of CloudFormation check variants and bug fixes; one check name doesn't match its stated purpose.

[mondoo-code-review]

Well-structured addition of CloudFormation check variants and bug fixes for AWS security policies

[mondoo-code-review]

Well-structured addition of CloudFormation check variants and runtime queries with minor correctness concerns

[mondoo-code-review]

🟡 warning — The remediation example changed SSLSupportMethod to SslSupportMethod, and the new check at line 52583 uses SslSupportMethod. The actual CloudFormation property name is SslSupportMethod, so this fix is correct — just flagging that this is a breaking change to the remediation docs for anyone who copy-pasted the old example.

[mondoo-code-review]

🔵 suggestion — The ECR public-access check passes when RepositoryPolicyText is empty OR Statement is empty. This means a repository with no policy at all is considered compliant, which is the right default. However, the comment notes that string-form policies "pass through unevaluated" — this is a silent false-negative. Consider adding a guard that fails if RepositoryPolicyText is a non-empty value but Statement is absent (i.e., it's likely a string), so users get a warning rather than a silent pass.

[mondoo-code-review]

🔵 suggestion — The EKS nodegroup encrypted volumes CloudFormation check requires BlockDeviceMappings != empty, meaning a launch template that omits BlockDeviceMappings entirely will fail. Some launch templates legitimately rely on AMI-default block device mappings. If the intent is to only flag templates that have explicit unencrypted mappings, consider making BlockDeviceMappings != empty part of a filter rather than a failure condition, or document that omission is intentionally treated as non-compliant.

[mondoo-code-review]

🔵 suggestion — The new Route 53 runtime check aws.vpcs.all(id.in(loggedVpcIds)) requires every VPC to have an active query log association. This is a strict posture — default VPCs or utility VPCs that carry no workloads will cause failures. This may be intentional, but worth documenting or noting in the check description so users understand the scope.