Support inline code for warning after a certain date

[dvasdekis]

Description

We would like Trivy to kick up a warning after a certain date, for known vulnerabilities that are being worked on, but don't yet have a fix. We would like to define this using inline comments, like #trivy:warnafter:20250101 (or similar)

The context is that we are using Trivy to scan a large Terraform repository. Terraform has custom module support, and Trivy isn't yet smart enough to detect issues in custom modules where we use variables to optionally select 'turning on' the feature with the vulnerability.

As an example, we might have a resource inside a module like the below:

module "storage" {
  storage_account_name = "foo"
  allow_vulerable_feature = true
  }

and then the underlying resource definition within the module is like:

resource "azurerm_storage_account" "some-account" {
  name                            = var.storage_account_name
  ...
  #trivy:ignore:azure-vulnerable-feature
  vulnerable_feature = var.allow_vulerable_feature ? true : false
  }

We want to be able to set a timeout on a line like the below in the module reference:

module "storage" {
  storage_account_name = "foo"
  # We are currently migrating storage accounts to the new auth method which will be completed by 1st Jan 2025, allowing for us to disable vulerable_feature. Below should be false after this date.
  #trivy:warnafter:20250101
  allow_vulerable_feature = true
  }

Target

None

Scanner

Vulnerability

[nikpivkin]

Hi @dvasdekis !

Trivy supports the ability to specify an expiry date for an ignore rule:

#trivy:ignore:aws-s3-enable-logging:exp:2024-03-10
resource "aws_s3_bucket" "example" {
  bucket = "test"
}

Or do you need to specify an expiry date beyond the ignore rule declaration?

[dvasdekis]

Hi @nikpivkin , thank you for your reply! We love Trivy :)

Because Trivy can't yet interpret the variables and detect if the flag creating the security problem is used or not, we need to have this ability to specify an expiry outside of the ignore rule.

This feature would be superseded when Trivy has support for interpreting how Terraform modules impact the security of the underlying deployed resources (but that's way more complicated to implement).

[simar7]

Thanks @dvasdekis for the idea but this will require some work as you said today Trivy today works on checks that are directly mapped to their underlying resources (e.g. a check for an S3 bucket) rather than the variables it uses. A variable could be used anywhere and even reused across different resources.