Add support to ignore misconfigurations for Terraform resources by resource/data address

[pseudomorph]

Description

As an example:

CRITICAL: Security group rule allows ingress from public internet.
═══════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════
Opening up ports to the public internet is generally to be avoided. You should restrict access to IP addresses or ranges that explicitly require it where possible.

See https://avd.aquasec.com/misconfig/avd-aws-0107
───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
 modules/example.tf:6
   via modules/example.tf:1-8 (aws_security_group_rule.bad-example)
───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
 1   resource "aws_security_group_rule" "bad-example" {
 2     type        = "ingress"
 3     from_port   = 443
 4     to_port     = 443
 5     protocol    = "tcp"
 6 [   cidr_blocks = ["0.0.0.0/0"]
 7     security_group_id = aws_security_group.example.id
 8   }

It would be useful to be able to ignore misconfigurations in Terraform based on resource address. Perhaps as so:

  - id: "AVD-AWS-0107"
    tf_addresses:
      - "modules/atlantis/atlantis.tf"

Target

None

Scanner

Misconfiguration

[simar7]

Wouldn't specifying the paths parameter handle this?

$ cat trivyignore.yaml

misconfigurations:
  - id: AVD-AWS-0107
    paths:
      - "modules/atlantis/atlantis.tf"

[pseudomorph]

there can be multiple instances of a resource type within a given file which have the same violation. It might be the case that only a specific one should be ignored, whereas, other instances do not make sense to ignore. Blanket ignoring all instances of a violation within a file doesn't account for such cases.

[simar7]

I see. Thanks for clarifying. What about ignoring inline? Just trying to understand if there are pain points today.

[pseudomorph]

Sure thing - Apologies, I wrote this quickly and left a bit of context out.

I'm working out a Terraform module monorepo design. I'd like to implement misconfiguration/vulnerability detection as part of this. However, I'd like to keep tight control over who has the ability to ignore violations. Leveraging the .trivyignore.yaml file could allow for targeted exceptions, while enabling tight controls by limiting codeowners of that specific file.

I suppose a related feature request to this, would be for adding a flag to disable ignoring inline, and only relying on the .trivyignore file.

My ultimate goal here, is to make development as frictionless as possible, when operating within certain bounds, but add a lot of friction for going against security best practices, etc.

[simar7]

Thanks. I understand the motivation you have now but still not seeing how the following would ignore individual resources on a per file basis from within the trivyignore:

  - id: "AVD-AWS-0107"
    tf_addresses:
      - "modules/atlantis/atlantis.tf"

My understanding of the above is that it implies to ignore "AVD-AWS-0107" within the atlantis.tf module. Which is pretty much the same as specifying paths as in this case there's no information to ignore one (or many, out of many) resources. The only time it would work would be the special case where the atlantis.tf only has one resource within it.

A further revision of something desired could look like the following:

  - id: "AVD-AWS-0107"
    paths:
      - module: "modules/atlantis/atlantis.tf"
      - resources: "foo", "bar"

Could ignore the foo and bar resource out of the module but leave baz to have rule applied. Doing so feels a little brittle and hard to read to me in practice. IMO it is best to have the context of the modifiers in the same file (or in proximity to) with what they have an effect on.

[pseudomorph]

I totally missed a typo in my original comment.

  - id: "AVD-AWS-0107"
    tf_addresses:
      - "modules/atlantis/atlantis.tf"

Should have been:

  - id: "AVD-AWS-0107"
    tf_addresses:
      - "aws_security_group_rule.bad-example"

Though, given a resource might have the same name within a module monorepo, greater specificify would be achieved through a combination of filepath and resource path - which is what your last suggestion would achieve.

Apologies again for missing that typo. I understand the confusion more clearly now.

---

Alternatively -- would expanding out paths as it exists make sense?

For instance:

  - id: "AVD-AWS-0107"
    paths:
      - "modules/atlantis/atlantis.tf:aws_security_group_rule.bad-example"

Where the structure of a path is {filepath}:{[resource-path,line-number,etc..]}, and previous behavior is preserved if only the file path is provided. Would increasing path specificity in this way be useful outside of the Terraform example?