DEV Community: DiffSense

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

DiffSense — Mon, 23 Mar 2026 20:58:07 +0000

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"]
  }
}

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\"] } }"}'

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
}

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"
}

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\" }"}'

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."
}

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.

Using LLMs to do security analysis at the git diff level — what works, what doesn't, and why structured output matters

DiffSense — Sun, 22 Mar 2026 04:15:33 +0000

I've been experimenting with piping raw git diff output into LLMs for automated security review, and I wanted to share what I've learned because some of the results surprised me.

The problem that started this

A teammate refactored a SQL query from string concatenation to an f-string. The diff looked like an improvement:

-    query = "SELECT * FROM users WHERE id = " + user_id
+    query = f"SELECT * FROM users WHERE id = {user_id}"

Three reviewers approved it. It looked cleaner. But the vulnerability was identical — both are injection vectors. The cosmetic improvement actually made it harder to catch because it looked like the dev was modernizing the code.

This is the kind of thing that made me think: can an LLM reliably detect that a diff looks like a fix but isn't?

The architecture

I built a FastAPI service that accepts a raw diff string and returns structured JSON with severity-classified security and quality issues. Here are the key design decisions I made and why.

Why diffs and not full files?

Full-file analysis is what SAST tools already do well. Diffs are interesting because they capture intent — what the developer was trying to change. An LLM can reason about the gap between what a change appears to do and what it actually does. That's the niche.

Why structured JSON output instead of free text?

Because the output needs to be machine-consumable. If you want to post a PR comment, block a merge, or feed results into a dashboard, you need parseable severity levels and categories — not a paragraph of prose.

The API has three endpoints:

POST /review — returns security and quality issues with severity levels
POST /commit-message — generates a Conventional Commits message from the diff
POST /changelog — generates a Keep a Changelog formatted entry

Here's what the /review endpoint returns for the SQL injection example above:

{
  "security_issues": [
    {
      "severity": "CRITICAL",
      "description": "SQL query built with f-string interpolation is vulnerable to SQL injection. Use parameterized queries.",
      "line_hint": "f\"SELECT * FROM users WHERE id = {user_id}\""
    }
  ],
  "quality_issues": [
    {
      "severity": "MEDIUM",
      "description": "Refactored from concatenation to f-string but the core vulnerability remains. This is a cosmetic change, not a security fix."
    }
  ],
  "summary": "Critical: SQL injection persists after refactor. The change is cosmetic."
}

Each issue has a severity (CRITICAL, HIGH, MEDIUM, LOW, INFO), a description, and a line hint pointing to the relevant code. The separation between security and quality issues lets you handle them differently in your pipeline — maybe security issues block the merge, but quality issues are just warnings.

Why DeepSeek instead of GPT-4?

Cost. DeepSeek runs at roughly $0.0004 per request, which makes it viable to offer a free tier that's actually usable. I haven't done a rigorous side-by-side comparison, but anecdotally GPT-4 catches more subtle logic bugs while DeepSeek handles pattern-based security issues (injection, XSS, hardcoded secrets) well enough for a first-pass filter.

Why truncate diffs to 8,000 characters?

Two reasons: (1) sending very large diffs produces worse analysis — the model loses focus when there's too much context, and (2) if your diff is that large, an automated tool probably isn't the right first step. The truncation is automatic — the API takes whatever you send and clips it if needed.

What it handles well

Based on my testing so far, it reliably flags:

SQL injection (concatenation, f-strings, format strings)
XSS via unsanitized DOM insertion (innerHTML, template literals)
Hardcoded secrets and API keys in source code
Command injection (shell=True, os.system)

The most interesting behavior is what I call the "cosmetic refactor" pattern — when a diff looks like it's fixing something but the underlying vulnerability is unchanged. The LLM seems to handle this well because it's reasoning about what changed rather than just scanning for dangerous patterns.

What it doesn't catch (and probably can't)

Being honest about the limitations:

Business logic flaws — the model has no context about what your app is supposed to do
Race conditions — diffs don't contain concurrency context
Dependency vulnerabilities — it only sees your code changes, not your supply chain
Subtle type confusion bugs — LLMs aren't compilers
Anything requiring full codebase context — the model only sees the diff, not the file it belongs to

This means it won't catch a vulnerability that's introduced by the interaction between the changed code and existing code it can't see.

Where it fits in a pipeline

This is a pre-review filter, not a SAST replacement. Think of it as a layer that catches the obvious stuff before a human reviewer spends their time on it.

Some ways you could use it:

Pre-commit hook: run git diff --cached through /review before allowing a commit
CI/CD gate: call /review in a GitHub Action and post results as a PR comment
Changelog automation: call /changelog on merge to auto-update CHANGELOG.md
Commit message generation: pipe your staged diff through /commit-message to stop writing "fix stuff"

Here's what a basic integration looks like:

DIFF=$(git diff HEAD~1)
curl -X POST https://diffsense.p.rapidapi.com/review \
  -H "Content-Type: application/json" \
  -H "X-RapidAPI-Key: YOUR_KEY" \
  -d "{\"diff\": \"$DIFF\"}"

Or in Python:

import requests

diff = open("my.patch").read()
response = requests.post(
    "https://diffsense.p.rapidapi.com/review",
    headers={
        "Content-Type": "application/json",
        "X-RapidAPI-Key": "YOUR_KEY"
    },
    json={"diff": diff}
)
print(response.json())

The bigger insight

The most valuable thing I've learned building this: LLMs are better at analyzing changes than analyzing code. A diff is a narrative — "someone tried to do X" — and LLMs are good at narratives. Static code is just structure, and traditional tools handle structure better.

That's why I think diff-level analysis is a genuine niche, not just "yet another AI code review tool." It's not competing with SAST — it's covering a different surface.

Try it / read the code

The implementation is open source if you want to look at the FastAPI structure or the prompt engineering: github.com/diffsense/diffsense-api

There's also a hosted version on RapidAPI with a free tier (50 requests/month): rapidapi.com/terrycrews99/api/diffsense

I'm actively developing this and would genuinely appreciate feedback — what patterns would you want caught at the diff level? What would make this useful enough to add to your pipeline?