Skip to content
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): Support symlinks in misconfiguration scanning #7456

Open
simar7 opened this issue Sep 6, 2024 Discussed in #7419 · 0 comments
Open

feat(misconf): Support symlinks in misconfiguration scanning #7456

simar7 opened this issue Sep 6, 2024 Discussed in #7419 · 0 comments
Labels
kind/feature Categorizes issue or PR as related to a new feature. scan/misconfiguration Issues relating to misconfiguration scanning

Comments

@simar7
Copy link
Member

simar7 commented Sep 6, 2024

This is part of a bigger discussion as to if Trivy should support on a global scanner level or not as seen here: #4184

Discussed in #7419

Originally posted by h-l-b August 29, 2024

Question

We are migrating from tfsec to trivy and trivy is not scanning most of the nested terraform modules in one of our projects - the number of config files detected is fewer than expected and expected misconfigurations are not flagged. The reason for this seems to be that they are called in a loop based on a variable defined in a symlinked file (simplified version of our project structure below)

main.tf in root module

module "networks" {
  source   = "../../modules/0_network"
  for_each = var.virtual_environments

  virtual_environment                   = each.key
}

virtual_environments is defined in the variables file, which is actually a symlink from the root module directory
variables.tf -> ../../shared/variables.tf

The actual value for virtual_environments for an environment is in a tfvars file which is passed in as an argument to the trivy config command.

If I replace the symlink to variables.tf with an actual variables.tf file with exactly the same content, then the number of config files detected is greater and ../../modules/0_network is actually scanned, so it looks like it is the symlink that is causing the issue. We use the symlink to a shared file because we have multiple layers in the project which use the same variables, so this way we only have to update them in one place. tfsec works fine with this.

I've found #4184 which says that symlinks are not supported, but it's from last year and was wondering if it is still the case, and if there are any plans to add support?

Target

Filesystem

Scanner

Misconfiguration

Output Format

None

Mode

None

Operating System

macOS Sonoma

Version

% trivy --version
Version: 0.51.2
Vulnerability DB:
  Version: 2
  UpdatedAt: 2024-06-07 12:13:50.7744497 +0000 UTC
  NextUpdate: 2024-06-07 18:13:50.774449409 +0000 UTC
  DownloadedAt: 2024-06-07 13:31:05.815831 +0000 UTC
Check Bundle:
  Digest: sha256:ef2d9ad4fce0f933b20a662004d7e55bf200987c180e7f2cd531af631f408bb3
  DownloadedAt: 2024-08-28 14:16:07.350996 +0000 UTC
@simar7 simar7 added kind/feature Categorizes issue or PR as related to a new feature. scan/misconfiguration Issues relating to misconfiguration scanning labels Sep 6, 2024
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
Projects
None yet
Development

No branches or pull requests

1 participant