If your team has migrated — or is migrating — from Terraform to OpenTofu, you've probably asked yourself: does my security scanner still work?

It's a fair question. OpenTofu has been evolving fast since the fork from HashiCorp Terraform in late 2023. Version 1.8 brought provider-defined functions. Version 1.9 introduced tofu test improvements. By 1.11, the project was shipping its own file discovery with .tofu extensions, ephemeral resources, and client-side state encryption — features that simply don't exist in Terraform.

Most popular scanners were designed for Terraform's HCL. When you run them against OpenTofu-specific constructs, you get one of three outcomes: false negatives (issues silently missed), noisy false positives, or outright parse errors. None of those are good.

This article covers what an OpenTofu security scanner actually needs to do, how the current tools stack up, and why a purpose-built alternative deserves your attention.

Why OpenTofu Security Scanning Is a Different Problem

At the HCL level, OpenTofu and Terraform look nearly identical — and that's both reassuring and misleading.

The divergence isn't in syntax. It's in semantics and features:

• Ephemeral resources (introduced in OpenTofu 1.10) hold temporary credentials or sensitive values that are never persisted to state. A scanner that doesn't understand ephemeral resource semantics may flag them as "missing state encryption" — a false positive — or worse, may silently skip checking them entirely.
• .tofu file extension discovery — OpenTofu now supports .tofu files alongside .tf. Scanners that only glob for *.tf will miss entire modules written in .tofu files.
• Client-side state encryption — OpenTofu's built-in state encryption is a security feature, but scanners need to understand its configuration schema to avoid incorrectly flagging encrypted state configurations as misconfigured.
• check blocks — OpenTofu's validation check blocks can encode security assertions directly in your IaC. An aware scanner can read and reinforce these; an unaware one ignores them.

These aren't edge cases. They're the features teams adopt OpenTofu for. Your scanner needs to keep up.

The Current Landscape: What Tools Exist?

Checkov

Checkov (maintained by Palo Alto Networks) is the most comprehensive open-source IaC scanner by policy count — over 2,500 built-in rules as of early 2026. It performs graph-based analysis that catches cross-resource misconfigurations that attribute-only scanners miss.

OpenTofu support: Checkov parses HCL and has basic OpenTofu awareness, but its graph model was designed around Terraform's resource graph. Ephemeral resources and .tofu file discovery are not fully supported as of writing. Custom rule support is strong (Python or YAML), but the learning curve is steep.

Best for: Teams already deep in the Checkov ecosystem, or those needing maximum policy breadth on AWS/Azure/GCP.

Trivy (absorbed tfsec)

tfsec was the go-to standalone Terraform scanner for years. Aqua Security absorbed it into Trivy in 2024. The rule library carried over, and Trivy now covers container images, dependencies, secrets, and IaC in one tool — over 31,000 GitHub stars and growing.

OpenTofu support: Trivy scans HCL directories and supports OpenTofu to the extent that the HCL overlap covers. The merged tfsec rules are still Terraform-era rules. Secrets scanning is a genuine strength.

Best for: Teams that want a single scanner across their entire stack (images + IaC + deps). Accept that OpenTofu-specific constructs may not be fully analyzed.

Terrascan

Terrascan by Tenable uses OPA/Rego policies and supports multi-cloud targets. It's strong on compliance frameworks (CIS, NIST, PCI-DSS) and plugs into CI/CD cleanly.

OpenTofu support: Similar to Checkov — HCL-parsing foundation with no dedicated OpenTofu-specific construct handling. Multi-cloud coverage is a genuine strength.

Best for: Compliance-heavy environments that need Rego-based policy-as-code.

The Gap: Static Analysis + Secrets + Policy, Built for OpenTofu

Every tool above does something well. The problem is that they're all Terraform-first tools playing catch-up with OpenTofu — and none of them were built with the combined scope that modern DevSecOps teams actually need:

1. Static analysis — misconfiguration detection across all HCL constructs including OpenTofu-specific ones
2. Secrets detection — catching hardcoded API keys, tokens, passwords in .tf and .tofu files before they reach version control or state
3. Policy enforcement — custom rules your team defines, not just the vendor's baked-in checklist
4. CI/CD first design — not a CLI afterthought, but a tool built to live inside your pull request workflow

This is exactly what TFGuard was built to solve.

TFGuard: A Purpose-Built Security Scanner for Terraform and OpenTofu

TFGuard is a static analysis, policy enforcement, and secrets detection tool designed from the ground up for the modern IaC security workflow. It's not a Terraform tool with OpenTofu support bolted on — it's built to handle both, treating the HCL ecosystem as a first-class target.

What TFGuard Does

Static Analysis TFGuard scans your .tf and .tofu files for misconfigurations — open security groups, public S3 buckets, missing encryption, overly permissive IAM policies, and hundreds of other common issues. The analysis is resource-aware, understanding not just attribute values but relationships between resources.

Secrets Detection This is where most IaC scanners fall short. TFGuard scans for hardcoded credentials, API keys, tokens, and passwords directly in your infrastructure code — before they get committed, before they land in your .tfstate, and before they end up in a breach. The detector covers common patterns across AWS, GCP, Azure, and generic secret formats.

Policy Enforcement TFGuard lets you define your organization's own rules — not just use vendor defaults. Write policies for your tagging standards, naming conventions, allowed instance types, required encryption configurations, and anything else your security team mandates. These policies enforce as code, version-controlled alongside your infrastructure.

CI/CD Native TFGuard integrates directly into GitHub Actions, GitLab CI, and other pipelines. It's designed to run on every pull request that touches .tf or .tofu files, produce machine-readable output, and fail the build when critical issues are found — before a single resource gets provisioned.

A Quick Example

Running TFGuard against an OpenTofu module is a single command:

tfguard scan ./infrastructure/

Output is clean, actionable, and points directly to the line that needs fixing:

[CRITICAL] aws_security_group.web — ingress open to 0.0.0.0/0 on port 22 (main.tf:18)
[HIGH]     aws_s3_bucket.data — server-side encryption not configured (storage.tf:44)
[MEDIUM]   aws_iam_role.app — no permission boundary attached (iam.tf:91)
[SECRET]   aws_db_instance.primary — hardcoded password detected (database.tf:12)

No noise. No 200-line JSON blobs. Just the findings your team can act on.

For CI/CD, a GitHub Actions step looks like this:

- name: TFGuard Security Scan
  uses: tfguard/tfguard-action@v1
  with:
    path: ./infrastructure
    fail_on: HIGH,CRITICAL,SECRET

Practical: Setting Up an OpenTofu Security Scan in CI

Whether you use TFGuard or another tool, here's the pattern that works:

1. Scan on Every PR That Touches IaC

on:
  pull_request:
    paths:
      - '**.tf'
      - '**.tofu'
      - '**.tfvars'

Scoping to IaC file changes avoids unnecessary scan runs and keeps your pipeline fast.

2. Scan the Plan, Not Just the Source

Source-level HCL scanning catches most issues, but plan-file scanning is higher fidelity — it reflects exactly what OpenTofu intends to create, including computed values that aren't visible in raw HCL.

tofu plan -out=tfplan
tofu show -json tfplan > plan.json
tfguard scan --plan plan.json

3. Handle Suppressions Explicitly

Every scanner will produce some false positives. Suppress them in code with a reason, not silently:

# tfguard:ignore:SG-001 — intentionally public; CloudFront origin validated at WAF
resource "aws_security_group" "cdn_origin" {
  ...
}

Suppressions without reasons become security debt no one understands six months later.

4. Fail Hard on Secrets, Soft on Warnings

Treat secrets detection as a hard block — a PR with a hardcoded credential should never merge, full stop. Treat medium-severity misconfigurations as warnings on existing projects while you remediate the backlog.

The Real Cost of Skipping This

Misconfiguration is not an abstract risk. The 2024 Datadog State of Cloud Security report found that one in four AWS organizations had at least one publicly exposed S3 bucket. The 2024 Verizon DBIR found that misconfiguration accounted for a growing share of breaches involving cloud assets.

These aren't sophisticated attacks. They're missing blocks in .tf files — the exact thing a scanner catches in milliseconds at PR time.

The fix is thirty seconds of configuration in your pipeline. The incident investigation is months of your team's time, potential regulatory exposure, and customer trust that's hard to rebuild.

Getting Started with TFGuard

TFGuard is purpose-built for teams running Terraform and OpenTofu who want security scanning, secrets detection, and policy enforcement in a single tool — without the overhead of a heavyweight platform or the limitations of tools that treat OpenTofu as an afterthought.

👉 Try it at tfguard.com

The documentation covers installation, CI/CD integration, writing custom policies, and the full rule reference. It takes about fifteen minutes to go from zero to scanning on every pull request.

Your OpenTofu modules define your cloud. A security scanner defines whether that cloud is safe. The two should work together — from day one.

Have questions about setting up OpenTofu security scanning in your pipeline? Drop a comment below.

Tags: OpenTofu Terraform DevSecOps IaC Security Cloud Security Infrastructure as Code CI/CD Security Scanning