feat(terraform): add OpenTofu file extension support

[jswank]

Add support for OpenTofu file extensions (.tofu and .tofu.json) to enable scanning of OpenTofu infrastructure as code files.

Description

This PR adds detection support for OpenTofu file extensions (.tofu and .tofu.json). These files are functionally identical to Terraform files but use the OpenTofu extension, allowing Trivy to scan OpenTofu infrastructure as code files.

Checklist

• I've read the https://trivy.dev/latest/community/contribute/pr/ to this repository.
• I've followed the https://trivy.dev/latest/community/contribute/pr/#title in the PR title.
• I've added tests that prove my fix is effective or that my feature works.
• I've updated the https://github.com/aquasecurity/trivy/blob/main/docs with the relevant information (if needed).
• I've added usage information (if the PR introduces new options)
• I've included a "before" and "after" example to the description (if the PR is a user interface change).

Before/After Example

Before

OpenTofu (.tofu) files are not recognized as infrastructure as code files.

$ trivy config /path/to/directory/with/tofu/files
2025-04-16 INFO [misconfig] Misconfiguration scanning is enabled
2025-04-16 INFO Detected config files num=0

After

OpenTofu (.tofu) files are correctly detected and scanned for security issues.

$ trivy config /path/to/directory/with/tofu/files
2025-04-16 INFO [misconfig] Misconfiguration scanning is enabled
2025-04-16 INFO [terraform scanner] Scanning root module file_path="."
2025-04-16 INFO Detected config files num=2

[CLAassistant]

All committers have signed the CLA.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[Copilot]

Pull Request Overview

This PR adds support for OpenTofu file extensions to enable scanning of infrastructure as code files with .tofu and .tofu.json extensions.

• Updated parser logic to recognize tofu file extensions.
• Added test cases to confirm tofu file detection.
• Extended detection logic to include tofu extensions in file type determination.

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
pkg/iac/scanners/terraform/parser/parser.go	Updated file parsing to support .tofu and .tofu.json files.
pkg/iac/detection/detect_test.go	Added tests for tofu file handling with and without readers.
pkg/iac/detection/detect.go	Expanded extension checking to include tofu extensions.

[simar7]

Thanks for the PR @jswank - adding support for OpenTofu file extension would imply adding support for OpenTofu scanning as a whole. We haven't committed to doing that just yet - there is an open discussion for it #5069

Having said that, it might be time to do so since OpenTofu has been out for a some time now. There are a couple of issues that if added to OpenTofu will make it diverge from Terraform (and may require changes on our end as well) such as:

1. Direct support for conditional single-instance resources opentofu/opentofu#1306
2. Support OCI registries for provider and module distribution. opentofu/opentofu#308

cc @nikpivkin @itaysk WDYT?

[jswank]

Thanks for the response @simar7! It does seems like an important consideration for the project- you certainly don't want to imply support of OpenTofu-specific functionality unintentionally. Especially since some divergence in OpenTofu / Terraform capabilities has begun to occur in recent versions.

The use case I have is fairly limited: my organization has made the decision to standardize on OpenTofu and is in the process of converting existing Terraform IaC. In order to clearly signify where this conversion has happened, we are renaming .tf files to .tofu.

Would you be open to a PR which allowed for the TF (.tf vs .tofu) extension to be specified as a flag? This would simply make use of existing Terraform functionality against a differently targeted set of files, i.e. no suggestion of supporting (potentially) divergent OpenTofu features to Trivy users. Alternatively, is this something that could be reflected in documentation? Caveat emptor, YMMV, etc.

[nikpivkin]

Usually, in such cases, Trivy allows customizing file patterns via the file-patterns flag. However, this flag is not applicable if the parser works with several file extensions at once, because it becomes unclear which extension is overridden.

Having said that, it might be time to do so since OpenTofu has been out for a some time now.

If we decide to support OpenTofu, we will also need to implement support for features that exist exclusively in OpenTofu, and only enable them for files with the .tofu extension.

At this point, to my understanding and unless I'm missing something, OpenTofu does not contain any changes that could affect our current scanning goals. However, if we add support for the .tofu extension now, and OpenTofu introduces new features later, it may cause errors when scanning new configurations. On the other hand, for users who use both .tf and .tofu files at the same time, scanning only .tf will look incorrect and incomplete.

[wazy]

Usually, in such cases, Trivy allows customizing file patterns via the file-patterns flag. However, this flag is not applicable if the parser works with several file extensions at once, because it becomes unclear which extension is overridden.

Having said that, it might be time to do so since OpenTofu has been out for a some time now.

If we decide to support OpenTofu, we will also need to implement support for features that exist exclusively in OpenTofu, and only enable them for files with the .tofu extension.

At this point, to my understanding and unless I'm missing something, OpenTofu does not contain any changes that could affect our current scanning goals. However, if we add support for the .tofu extension now, and OpenTofu introduces new features later, it may cause errors when scanning new configurations. On the other hand, for users who use both .tf and .tofu files at the same time, scanning only .tf will look incorrect and incomplete.

My org is currently switching over to only .tofu files and would love to use trivy as before with .tf files so this would be great to have included. In the interim I attempted to do the following:

trivy config --file-patterns "hcl:.*.tofu" .

but am unsuccessful in getting that to work no matter what regex is used:

WARN [report] Supported files for scanner(s) not found. scanners=[misconfig]

@nikpivkin Am I missing something obvious or does that flag not work for the misconfig scanner?

[nikpivkin]

trivy config --file-patterns "hcl:.*.tofu"

This is not a valid pattern because the first section should specify one of the following scanners. This flag works for most IaC scanners, but not for Terraform. I left a comment above with an explanation.

[nikpivkin]

@simar7 I've left the comment. Wdyt? I think changing the filePatterns flag to allow specifying a subtype, such as terraform:hcl:.*.tofu or terraform:json:.*.json, might be unnecessary overhead since this need arises only for Terraform and so far for OpenTofu. Unlike Dockerfile, where custom extensions are common, I don't think many users will use custom extensions for Terraform.