feat(misconf): render causes for Terraform

[nikpivkin]

Description

This PR enriches the output by adding the evaluated block attributes that are causes of misconfiguration. A RenderedCause object with fields has been added to the JSON report:

• Raw - contains raw content,
• Highlighted - contains highlighted content.

Example:

./trivy conf main.tf
2024-11-01T17:19:19+06:00       INFO    [misconfig] Misconfiguration scanning is enabled
2024-11-01T17:19:19+06:00       INFO    [terraform scanner] Scanning root module        file_path="."
2024-11-01T17:19:19+06:00       INFO    Detected config files   num=2

main.tf (terraform)

Tests: 3 (SUCCESSES: 0, FAILURES: 3)
Failures: 3 (UNKNOWN: 0, LOW: 0, MEDIUM: 2, HIGH: 0, CRITICAL: 1)

AVD-AWS-0102 (CRITICAL): Network ACL rule allows access using ALL ports.
═══════════════════════════════════════════════════════════════════════════════════════════════════════════════════════
Ensure access to specific required ports is allowed, and nothing else.


See https://avd.aquasec.com/misconfig/aws-vpc-no-excessive-port-access
───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
 main.tf:37
   via main.tf:31-41 (aws_network_acl_rule.public_inbound[0])
───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
  31   resource "aws_network_acl_rule" "public_inbound" {
  32     network_acl_id = aws_network_acl.this.id
  33     count          = 2
  34     egress         = false
  35     rule_number    = var.public_inbound_acl_rules[count.index]["rule_number"]
  36     rule_action    = var.public_inbound_acl_rules[count.index]["rule_action"]
  37 [   protocol       = var.public_inbound_acl_rules[count.index]["protocol"]
  38     cidr_block     = lookup(var.public_inbound_acl_rules[count.index], "cidr_block", null)
  39     from_port      = lookup(var.public_inbound_acl_rules[count.index], "from_port", null)
  ..   
───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
Rendered cause:
───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
resource "aws_network_acl_rule" "public_inbound[0]" {
  protocol = "all"
}
───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────


AVD-AWS-0105 (MEDIUM): Network ACL rule allows ingress from public internet.
═══════════════════════════════════════════════════════════════════════════════════════════════════════════════════════
The Network Access Control List (NACL) function provide stateless filtering of ingress and
egress network traffic to AWS resources. It is recommended that no NACL allows
unrestricted ingress access to remote server administration ports, such as SSH to port 22
and RDP to port 3389.


See https://avd.aquasec.com/misconfig/aws-vpc-no-public-ingress-acl
───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
 main.tf:38
   via main.tf:31-41 (aws_network_acl_rule.public_inbound[1])
───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
  31   resource "aws_network_acl_rule" "public_inbound" {
  32     network_acl_id = aws_network_acl.this.id
  33     count          = 2
  34     egress         = false
  35     rule_number    = var.public_inbound_acl_rules[count.index]["rule_number"]
  36     rule_action    = var.public_inbound_acl_rules[count.index]["rule_action"]
  37     protocol       = var.public_inbound_acl_rules[count.index]["protocol"]
  38 [   cidr_block     = lookup(var.public_inbound_acl_rules[count.index], "cidr_block", null)
  39     from_port      = lookup(var.public_inbound_acl_rules[count.index], "from_port", null)
  ..   
───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
Rendered cause:
───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
resource "aws_network_acl_rule" "public_inbound[0]" {
  cidr_block = "0.0.0.0/0"
}
───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

Related issues

• Close feat(misconf): Filtering findings for Terraform modules based on attributes #7180

Checklist

• I've read the guidelines for contributing to this repository.
• I've followed the conventions in the PR title.
• I've added tests that prove my fix is effective or that my feature works.
• I've updated the documentation with the relevant information (if needed).
• I've added usage information (if the PR introduces new options)
• I've included a "before" and "after" example to the description (if the PR is a user interface change).

[simar7]

Looks good! but I wonder if we should put this behind a flag. It might be a bit too verbose to do as a default since essentially there could be several instances where output gets rendered. Maybe a misconfiguration specific boolean flag such as --render-causes where the default is false.

WDYT?

[nikpivkin]

Makes sense.

@aquasecurity/trivy Maybe there's a better term than Rendered cause? I'm open to any ideas you might have.

[nikpivkin]

@simar7 Should the render-causes flag accept a list of scanners just in case we add rendering for other types of configurations in the future? Usage: --render-causes=terraform

[simar7]

@simar7 Should the render-causes flag accept a list of scanners just in case we add rendering for other types of configurations in the future? Usage: --render-causes=terraform

Yeah makes sense to me.

[simar7]

Makes sense.

@aquasecurity/trivy Maybe there's a better term than Rendered cause? I'm open to any ideas you might have.

I'd say let's go with --render-causes=<list-of-scanners> for now unless we hear otherwise.

[itaysk]

maybe show-cause ?

[nikpivkin]

@itaysk Is the show-cause flag appropriate for this? And won't it confuse users, given that the table report already always includes a snippet of code with the cause, and the JSON report contains a “CauseMetadata” field?

[itaysk]

@nikpivkin yes, sorry I should have thorougly understood this before commenting. render-cause makes sense (small suggestion I think case is better than causes)

@simar7 isn't this what we discussed about Helm charts?

[simar7]

@simar7 isn't this what we discussed about Helm charts?

We'll still need to implement logic to preserve positions.