DEV Community

DiffSense
DiffSense

Posted on

Catch Terraform Security Issues Before They Hit Production — With a Single API Call

#infrastructureascode #security #devops #terraform

tags: terraform, devsecops, security, iac

You've just pushed a Terraform change. The plan looks clean. The apply succeeds. Three weeks later, someone runs a routine audit and finds your EC2 instance has been exposed to the entire internet since day one — because a security group was accidentally left wide open.

This is not a hypothetical. It's a pattern that shows up repeatedly in post-mortems, and it almost always comes down to the same root cause: nobody checked the HCL before it shipped.

TerraGuard is a REST API that does exactly that check — static analysis of Terraform code for security misconfigurations and hardcoded secrets, with no tooling to install and no pipeline plugins to configure.

What TerraGuard Does

TerraGuard exposes two analysis endpoints:

  • POST /analyze — scans HCL for security misconfigurations (open ingress rules, overly permissive IAM policies, unencrypted storage, etc.)
  • POST /secrets — detects hardcoded credentials, API keys, passwords, and tokens in Terraform resource definitions

Both endpoints accept a simple JSON payload {"hcl": "<your terraform code>"} and return structured findings with severity levels, affected resources, and concrete remediation steps.

The API is available on RapidAPI and requires no local installation. You can integrate it into any HTTP-capable environment — CI runners, pre-commit hooks, custom tooling, or a PR review bot.

Real Use Case: Security Group Misconfiguration

Here is a Terraform resource that gets written more often than it should:

resource "aws_security_group" "web" {
  ingress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}
Enter fullscreen mode Exit fullscreen mode

Protocol -1 means all traffic. Ports 0-0 means all ports. CIDR 0.0.0.0/0 means the entire internet. This security group grants unrestricted inbound access from anywhere to anything.

Send it to TerraGuard:

curl -X POST https://terraguard.p.rapidapi.com/analyze \
  -H "Content-Type: application/json" \
  -H "X-RapidAPI-Key: YOUR_API_KEY" \
  -d '{"hcl": "resource \"aws_security_group\" \"web\" { ingress { from_port = 0 to_port = 0 protocol = \"-1\" cidr_blocks = [\"0.0.0.0/0\"] } }"}'
Enter fullscreen mode Exit fullscreen mode

Response:

{
  "summary": "Security group allows unrestricted inbound traffic from any IP, posing a critical network exposure risk.",
  "risk_level": "CRITICAL",
  "issues": [
    {
      "severity": "CRITICAL",
      "category": "NETWORK",
      "title": "Overly Permissive Security Group Ingress",
      "description": "The security group ingress rule allows all traffic (protocol '-1', ports 0-0) from any IP address (0.0.0.0/0), effectively exposing the associated resource to the entire internet without restriction.",
      "resource": "aws_security_group.web",
      "recommendation": "Restrict ingress rules to specific, necessary ports and protocols, and limit source CIDR blocks to trusted IP ranges (e.g., corporate VPN or specific services)."
    }
  ],
  "passed_checks": [],
  "total_issues": 1
}
Enter fullscreen mode Exit fullscreen mode

Severity, category, affected resource, and a specific fix — all in one response.

Real Example: Hardcoded Secrets

The second class of Terraform mistakes that regularly causes incidents is hardcoded credentials. Someone writes a quick prototype, the password ends up in the HCL, the HCL gets committed, and now the credential is in git history permanently.

resource "aws_db_instance" "db" {
  password = "MySuperSecret123"
  username = "admin"
}
Enter fullscreen mode Exit fullscreen mode

Send it to POST /secrets:

curl -X POST https://terraguard.p.rapidapi.com/secrets \
  -H "Content-Type: application/json" \
  -H "X-RapidAPI-Key: YOUR_API_KEY" \
  -d '{"hcl": "resource \"aws_db_instance\" \"db\" { password = \"MySuperSecret123\" username = \"admin\" }"}'
Enter fullscreen mode Exit fullscreen mode

Response:

{
  "secrets_found": true,
  "risk_level": "CRITICAL",
  "findings": [
    {
      "severity": "CRITICAL",
      "type": "PASSWORD",
      "description": "Hardcoded database password 'MySuperSecret123' found in aws_db_instance resource",
      "location": "aws_db_instance.db.password",
      "recommendation": "Replace with variable reference (var.db_password), AWS Secrets Manager, or SSM Parameter Store"
    }
  ],
  "total_findings": 1,
  "remediation_summary": "Move all secrets to environment variables or a secrets manager."
}
Enter fullscreen mode Exit fullscreen mode

Where to Plug This In

CI/CD Pipelines

Run both endpoints as a step before terraform plan. If risk_level is CRITICAL or total_issues is greater than zero, fail the pipeline. The structured JSON response makes it straightforward to write that condition in any scripting language or pipeline DSL.

Pre-Commit Hooks

Use a tool like pre-commit with a custom script that extracts staged .tf files, sends them to TerraGuard, and blocks the commit if findings are returned. Developers get feedback before the code ever leaves their machine.

Pull Request Reviews

Integrate TerraGuard into your PR bot workflow. When a PR contains changes to .tf files, automatically post the analysis results as a comment. Reviewers see the security posture of the change alongside the diff — no context switching required.

This pairs naturally with diff-level analysis. If you're already using DiffSense to analyze what changed between commits, you can use TerraGuard to analyze the security implications of those changes in parallel. DiffSense tells you what changed; TerraGuard tells you whether what changed is safe.

Getting Started

TerraGuard is available on RapidAPI:

https://rapidapi.com/terrycrews99/api/terraguard

  • Free tier: 30 requests/month — enough to evaluate it in a real workflow
  • No SDK or CLI required — any HTTP client works
  • Endpoints: POST /analyze, POST /secrets, GET /health

The Broader Point

Static analysis for Terraform is not a new idea — tools like tfsec, checkov, and terrascan exist and are worth knowing. The difference with an API-first approach is composability. You can call TerraGuard from anywhere that can make an HTTP request: a GitHub Action, a Slack bot, a custom dashboard, a VS Code extension, a Jupyter notebook running an infrastructure audit. There's no local runtime dependency to manage across different environments.

If your team is already thinking about security at the code review and CI level — and you should be — adding a TerraGuard call to your Terraform workflow is a low-friction way to get structured, actionable findings without rearchitecting your toolchain.

Catch the open security groups before they ship. It's one API call.

Top comments (0)