-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(misconf): Filtering findings for Terraform modules based on attributes #7180
Labels
kind/feature
Categorizes issue or PR as related to a new feature.
scan/misconfiguration
Issues relating to misconfiguration scanning
Milestone
Comments
simar7
added
kind/feature
Categorizes issue or PR as related to a new feature.
scan/misconfiguration
Issues relating to misconfiguration scanning
labels
Jul 17, 2024
@simar7 I'll divide this into 3 tasks.
|
6 tasks
The first point has already been implemented. What about 2 and 3? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
kind/feature
Categorizes issue or PR as related to a new feature.
scan/misconfiguration
Issues relating to misconfiguration scanning
TODO:
for_each
orcount
variables. This would allow to target specific resources such as described in the example below.Discussed in #7157
Originally posted by acdha July 12, 2024
Description
Like many people, I use the
terraform-aws-modules/vpc/aws
module and that module creates a variety of resources using large lists for things like ACLs:This creates a problem on every project when using Trivy because you'll get findings for the resources created using
count
orfor_each
blocks inside the module based on those lists:(this also repeats for AVD-AWS-102, etc.)
I think Trivy needs explicit support for filtering things like this safely. The current design for attribute filtering does not support indexed resources (as every input to that module uses) and since these rules are usually false-positives (most people use AWS to host public applications so they'll need to support ingress HTTP, HTTPS, ICMP for Path MTU discovery, etc.), it's really tempting to just toss
#trivy:ignore:avd-aws-0102 trivy:ignore:avd-aws-0105
into that file — greatly increasing the odds of Trivy not catching an actual security problem when someone adds another rule – and even if indexed access were possible, it'd be risky because the indexes are not stable (e.g. in my example above, some of the rules come from a different module which has common firewall rules and an update could easily shift all of the index numbers).Since Trivy has full knowledge of the resources created in a module, it seems like it should be possible to have some way to use that hierarchy to select a resource which would otherwise not be in scope at this point:
I don't love that syntax and it seems like it might be preferable to say that complex filtering has to be done in a
.trivyignore.yaml
file where it could look more like this:One other thought which came out of this is that the error messages could be improved somewhat to list the attributes of the resource in question. When you have large lists being fed into a loop it'd be really nice to be able to see
cidr_block=0.0.0.0/0 from_port=22 to_port=22
so you could easily know which source definitely it refers to rather than having to count them.Target
None
Scanner
Misconfiguration
The text was updated successfully, but these errors were encountered: