-
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
docs(terraform): improve documentation for filtering by inline comments #6284
Conversation
In cases where trivy can detect comments of a specific format immediately adjacent to resource definitions, it is possible to filter/ignore findings from a single point of resource definition (in contrast to `.trivyignore`, which has a directory-wide scope on all of the files scanned). | ||
Trivy supports ignoring misconfigured resources by inline comments for Terraform configuration files only. | ||
|
||
In cases where Trivy can detect comments of a specific format immediately adjacent to resource definitions, it is possible to filter/ignore findings from a single point of resource definition (in contrast to `.trivyignore`, which has a directory-wide scope on all of the files scanned). The format for these comments is `trivy:ignore:<rule>` or `tfsec:ignore:<rule>` immediately following the format-specific line-comment [token](https://developer.hashicorp.com/terraform/language/syntax/configuration#comments). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In cases where Trivy can detect comments of a specific format immediately adjacent to resource definitions, it is possible to filter/ignore findings from a single point of resource definition (in contrast to `.trivyignore`, which has a directory-wide scope on all of the files scanned). The format for these comments is `trivy:ignore:<rule>` or `tfsec:ignore:<rule>` immediately following the format-specific line-comment [token](https://developer.hashicorp.com/terraform/language/syntax/configuration#comments). | |
In cases where Trivy can detect comments of a specific format immediately adjacent to resource definitions, it is possible to ignore findings from a single source of resource definition (in contrast to `.trivyignore`, which has a directory-wide scope on all of the files scanned). The format for these comments is `trivy:ignore:<rule>` immediately following the format-specific line-comment [token](https://developer.hashicorp.com/terraform/language/syntax/configuration#comments). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done 857f334
|
||
The format for these comments is `trivy:ignore:<Vulnerability ID>` immediately following the format-specific line-comment token. | ||
You can add multiple ignores on the same comment line. | ||
The ignore rule must contain one of the possible check IDs that can be found in its metadata: ID, short code or alias. The `id` from metadata is not case sensitive, you can specify `AVD-AWS-0089` or `avd-aws-0089` and it will work the same way. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The ignore rule must contain one of the possible check IDs that can be found in its metadata: ID, short code or alias. The `id` from metadata is not case sensitive, you can specify `AVD-AWS-0089` or `avd-aws-0089` and it will work the same way. | |
The ignore rule must contain one of the possible check IDs that can be found in its metadata: ID, short code or alias. The `id` from metadata is not case sensitive, you can specify `AVD-AWS-0089` or `avd-aws-0089` as it's case insensitive. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done 857f334
!!! tip | ||
Long ID is preferred because it is a readable format. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While it's more readable, I would argue that it's more error prone so I'm not sure if we should suggest users to use it over something like AVD ID.
!!! tip | |
Long ID is preferred because it is a readable format. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done 857f334
Description
The documentation lacked information on all the options for filtering by inline comments
Checklist