DEV Community: suhteevah

Your Terraform Is Probably Insecure — Here Are 90 Patterns to Check

suhteevah — Fri, 20 Feb 2026 17:18:19 +0000

Cloud misconfigurations were responsible for 15% of all initial attack vectors in data breaches last year. Not zero-days. Not sophisticated exploits. Misconfigurations. Public S3 buckets, overprivileged IAM roles, security groups that allow the entire internet to SSH in.

The infrastructure-as-code revolution was supposed to fix this — codify your infrastructure, review it like application code, catch mistakes in PRs. But terraform plan tells you what will change. It does not tell you if what you're deploying is secure.

I built CloudGuard to close that gap. 90 security patterns for Terraform and CloudFormation files. Here's what it checks and why.

1. Public S3 Buckets and Storage Access

# The pattern — public-read ACL with no block
resource "aws_s3_bucket" "assets" {
  bucket = "company-assets"
  acl    = "public-read"  # Anyone on the internet can read this
}

# The fix — block public access explicitly
resource "aws_s3_bucket" "assets" {
  bucket = "company-assets"
}

resource "aws_s3_bucket_public_access_block" "assets" {
  bucket = aws_s3_bucket.assets.id

  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

Why it still happens: marketing wants a public assets bucket, someone copies a Terraform example that defaults to public, the bucket policy is complex and nobody reads it carefully.

CloudGuard rule S3-001 catches public-read ACL on buckets. S3-004 flags missing S3 Block Public Access configuration. S3-008 detects bucket policies allowing wildcard principals.

2. Wildcard IAM Policies

# The pattern — full admin access to everything
resource "aws_iam_policy" "admin" {
  name = "ci-pipeline-policy"

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect   = "Allow"
      Action   = "*"       # Every AWS action
      Resource = "*"       # On every resource
    }]
  })
}

# The fix — scope to specific actions and resources
resource "aws_iam_policy" "ci_deploy" {
  name = "ci-pipeline-policy"

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect   = "Allow"
      Action   = ["s3:PutObject", "s3:GetObject"]
      Resource = "arn:aws:s3:::my-deploy-bucket/*"
    }]
  })
}

"I'll scope it down later." You won't. Or: "It's just for the CI pipeline." Until the CI credentials leak.

CloudGuard rule IM-001 catches wildcard Action in IAM policies. IM-003 flags wildcard Resource. IM-007 detects IAM roles with wildcard trust policies.

3. Open Security Groups

# The pattern — SSH open to the entire internet
resource "aws_security_group" "web" {
  name = "web-server"

  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]  # The entire internet can SSH in
  }
}

# The fix — restrict to specific CIDR blocks
resource "aws_security_group" "web" {
  name = "web-server"

  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["10.0.0.0/8"]  # VPN/internal only
  }
}

"I need to SSH in from home." Use a bastion host or AWS SSM Session Manager. Never expose SSH directly to the internet.

CloudGuard rule SG-001 catches security groups allowing 0.0.0.0/0 ingress. SG-004 flags database ports open to the internet.

4. Unencrypted Storage and Databases

# The pattern — RDS without encryption (Terraform default)
resource "aws_db_instance" "main" {
  engine         = "postgres"
  instance_class = "db.t3.micro"
  # storage_encrypted is false by default
}

# The fix — always encrypt
resource "aws_db_instance" "main" {
  engine            = "postgres"
  instance_class    = "db.t3.micro"
  storage_encrypted = true
  kms_key_id        = aws_kms_key.rds.arn
}

Most Terraform resources don't enable encryption by default. If you don't explicitly set it, it's off. There's almost no performance penalty for encryption at rest.

CloudGuard rule EC-001 catches RDS without encryption at rest. EC-004 flags unencrypted EBS volumes. EC-012 detects missing KMS key rotation.

5. Missing Logging and Audit Trails

# What's missing — no CloudTrail, no VPC flow logs
# If you don't have these resources, you're flying blind

resource "aws_cloudtrail" "main" {
  name                          = "main-trail"
  s3_bucket_name                = aws_s3_bucket.trail.id
  include_global_service_events = true
  is_multi_region_trail         = true
  enable_log_file_validation    = true
}

resource "aws_flow_log" "vpc" {
  vpc_id          = aws_vpc.main.id
  traffic_type    = "ALL"
  log_destination = aws_cloudwatch_log_group.flow.arn
}

CloudTrail is non-negotiable. Without it, you have no audit trail of who did what in your AWS account. VPC Flow Logs on production VPCs. S3 access logging on buckets with sensitive data.

CloudGuard rule LG-001 catches missing CloudTrail configuration. LG-004 flags VPCs without flow logs. LG-007 detects S3 buckets without access logging.

6. Compliance Mapping

Every CloudGuard finding is tagged with relevant compliance framework sections:

Finding	SOC2	HIPAA	PCI-DSS
Public S3 bucket	CC6.1	164.312(a)(1)	Req 7
Wildcard IAM	CC6.3	164.312(a)(1)	Req 7.1
Open security group	CC6.6	164.312(e)(1)	Req 1.2
Unencrypted RDS	CC6.1	164.312(a)(2)(iv)	Req 3.4
No CloudTrail	CC7.2	164.312(b)	Req 10.1

Run a scan, get a compliance report. No manual mapping required.

Run It On Your Infrastructure

clawhub install cloudguard
cloudguard scan infra/

Example output:

$ cloudguard scan infra/

[CRITICAL] S3-001 Bucket with public-read ACL — storage.tf:15
[CRITICAL] IM-003 IAM policy: Action * on Resource * — iam/admin-role.tf:22
[HIGH]     SG-001 Security group allows 0.0.0.0/0 on port 22 — network/security.tf:34
[HIGH]     EC-005 RDS without encryption at rest — database/main.tf:18

Score: 38/100 (Grade: F)

Most Terraform codebases I've scanned score below 50.

How It Compares to tfsec and checkov

Both are solid tools. CloudGuard differs in:

Scoring — 0-100 grade per scan, not just pass/fail
Compliance mapping — SOC2/HIPAA/PCI in the report
Pre-commit hooks — bad IaC never merges (Pro tier)
Ecosystem — part of 26 tools, same installer, same philosophy

If tfsec or checkov is working for your team, you probably don't need to switch. CloudGuard is for teams that want scoring + compliance mapping + the broader ecosystem.

Free to scan. Pro ($19/mo) adds pre-commit hooks + compliance reports. 100% local — your infrastructure code is literally a map of your cloud. It should never leave your machine.

CloudGuard | GitHub

Every Input Is an Attack Vector: A Developer's Guide to Input Validation

suhteevah — Fri, 20 Feb 2026 17:10:28 +0000

Every form field, query parameter, URL slug, file upload, and HTTP header your application accepts is an attack surface. If you're not validating and sanitizing all of them, you have vulnerabilities. This isn't a question of "if" — it's a question of how many.

We have linters for code style, type checkers for safety, test frameworks for correctness. But input validation? Most teams rely on frameworks to handle it, and frameworks only cover the happy path.

I built InputShield to scan for input validation failures that standard linting tools miss. Here are the 6 most dangerous patterns it catches.

1. SQL Injection — Still Alive in 2026

ORMs handle most queries. But there's always that one raw query for a complex join or a search feature.

// The pattern — string concatenation in SQL
app.get('/search', (req, res) => {
  const query = \`SELECT * FROM products WHERE name LIKE '%${req.query.q}%'\`;
  db.query(query); // SQL injection
});

// The fix — parameterized queries, always
app.get('/search', (req, res) => {
  db.query('SELECT * FROM products WHERE name LIKE $1', [\`%${req.query.q}%\`]);
});

InputShield rule SQ-001 catches string concatenation in SQL queries. SQ-004 flags template literals in raw SQL calls. SQ-007 finds ORM raw queries with unparameterized input.

2. Cross-Site Scripting (XSS) — More Vectors Than You Think

It's not just innerHTML. There's dangerouslySetInnerHTML in React, v-html in Vue, [innerHTML] in Angular, document.write, and href attributes with javascript:\ protocol.

// A comment component that renders "processed" markdown
function Comment({ content }) {
  const html = markdownToHtml(content); // Does this sanitize? Usually no.
  return <div dangerouslySetInnerHTML={{ __html: html }} />;
}

// The fix — sanitize before rendering
import DOMPurify from 'dompurify';
function Comment({ content }) {
  const html = DOMPurify.sanitize(markdownToHtml(content));
  return <div dangerouslySetInnerHTML={{ __html: html }} />;
}

InputShield rule XS-001 flags innerHTML from untrusted sources. XS-003 catches dangerouslySetInnerHTML with unsanitized data. XS-007 detects href attributes with user-controlled values.

3. Command Injection — The exec() Problem

File conversion, image processing, PDF generation — anything that shells out to a system command is a risk if user input reaches it.

// A file conversion endpoint
app.post('/convert', (req, res) => {
  const { filename } = req.body;
  exec(\`convert ${filename} output.pdf\`); // Command injection
});

// The fix — use execFile with explicit arguments
const { execFile } = require('child_process');
app.post('/convert', (req, res) => {
  const safeName = path.basename(filename); // Strip path traversal
  execFile('convert', [safeName, 'output.pdf']); // No shell interpolation
});

InputShield rule CI-001 catches user input in exec() calls. CI-004 flags unsanitized strings in child_process.spawn. CI-008 detects commands built from request parameters.

4. Path Traversal — When Users Control File Paths

// A file download endpoint
app.get('/download', (req, res) => {
  const file = req.query.file;
  res.sendFile(path.join('/uploads', file));
  // GET /download?file=../../etc/passwd — game over
});

// The fix — resolve and verify
app.get('/download', (req, res) => {
  const file = path.basename(req.query.file); // Strip directory traversal
  const fullPath = path.resolve('/uploads', file);
  if (!fullPath.startsWith('/uploads/')) {
    return res.status(403).send('Forbidden');
  }
  res.sendFile(fullPath);
});

InputShield rule PT-001 catches user input in fs.readFile paths. PT-004 flags path.join with user-controlled segments. PT-007 detects directory traversal sequences in file operations.

5. Server-Side Request Forgery (SSRF)

// A URL preview feature
app.post('/preview', async (req, res) => {
  const { url } = req.body;
  const response = await fetch(url); // SSRF — user controls the URL
  const html = await response.text();
  res.json({ preview: extractMeta(html) });
});

An attacker sends url=http://169.254.169.254/latest/meta-data/\ and reads your AWS instance metadata, including IAM credentials.

The fix: validate the URL against an allowlist of domains, block internal IP ranges, and use a DNS resolver that prevents rebinding attacks.

InputShield rule SS-001 catches user-controlled URLs in server-side fetch calls. SS-004 flags missing URL validation before HTTP requests.

6. ReDoS — Regular Expressions as Attack Vectors

// A search endpoint that builds regex from user input
app.get('/search', (req, res) => {
  const pattern = new RegExp(req.query.q); // ReDoS risk
  const results = items.filter(item => pattern.test(item.name));
  res.json(results);
});

A crafted input like (a+)+$\ causes catastrophic backtracking. Your server hangs on a single regex evaluation.

The fix: never build regex from user input. Use string methods (includes, indexOf) or a safe regex library with timeouts.

InputShield rule RE-001 catches regex constructed from user input. RE-004 flags patterns with potential catastrophic backtracking applied to user data.

Run It On Your Codebase

InputShield scans for all 6 of these categories (90 patterns total) in one pass:

clawhub install inputshield
inputshield scan .

Example output:

$ inputshield scan src/

[CRITICAL] CI-002 Unsanitized exec() with user input — api/convert.js:31
[CRITICAL] SQ-001 SQL query with string concatenation — db/users.js:55
[HIGH]     XS-001 innerHTML from untrusted source — components/comment.tsx:18
[HIGH]     PT-004 path.join with user-controlled segment — api/files.js:42

Score: 38/100 (Grade: F)

The average web application I've scanned scores 38/100. Run it on your codebase and see where you land.

Free to scan. Pro ($19/mo) adds pre-commit hooks so injection vectors can't merge. Runs 100% locally — your source code stays on your machine.

InputShield | GitHub

I Automated OWASP Top 10 Checks With a Pre-Commit Hook

suhteevah — Fri, 20 Feb 2026 17:02:52 +0000

Broken Access Control has been OWASP #1 since 2021. Not because developers don't understand authentication — but because auth is a consistency problem.

Your auth can be perfect on 99 endpoints. Endpoint 100 ships without middleware because someone forgot, copied a route template that didn't include it, or added an "admin-only" page during a hackathon and never locked it down.

Most auth tooling is runtime: pentest frameworks, DAST scanners, bug bounties. By the time they find something, the code is deployed and the vulnerability is live. I wanted a pre-commit hook that catches the common stuff before it leaves the developer's machine. So I built one.

How AuthAudit Maps to OWASP

AuthAudit scans for 90 authentication and authorization anti-patterns across 6 categories. Every finding maps to an OWASP Top 10 2021 entry:

OWASP Category	AuthAudit Coverage
A01:2021 Broken Access Control	Missing auth middleware, IDOR patterns, frontend-only role checks
A02:2021 Cryptographic Failures	Weak hashing, missing encryption, token mismanagement
A04:2021 Insecure Design	Missing rate limiting, authorization logic flaws
A07:2021 Identification & Auth Failures	Session management, password handling, CSRF gaps

Pattern 1: Unprotected Routes

This is the most common finding. A route definition with no authentication middleware between the path and the handler.

// Express — no auth middleware
app.get('/admin/users', (req, res) => {
  const users = await User.findAll();
  res.json(users);
});

// What it should look like
app.get('/admin/users', requireAuth, requireRole('admin'), (req, res) => {
  const users = await User.findAll();
  res.json(users);
});

Why it happens: route templates without auth, copy-paste from tutorials, "I'll add auth later" that never happens.

AuthAudit rule AC-001 catches route definitions with no auth middleware. AC-003 specifically flags admin paths without elevated auth checks.

Pattern 2: JWT Stored in localStorage

// After successful login
const response = await fetch('/api/login', { method: 'POST', body: credentials });
const { token } = await response.json();
localStorage.setItem('token', token); // XSS = full account takeover

Any XSS vulnerability gives the attacker the full JWT. Game over. Full account takeover.

The alternative is HttpOnly cookies — they're not accessible to JavaScript. An XSS attack can still make requests (CSRF), but it can't steal the session token and use it from another machine.

AuthAudit rule TK-003 flags JWT/token storage in localStorage. TK-005 catches sensitive tokens accessible to client-side JavaScript.

Pattern 3: Missing CSRF Protection

State-changing endpoints (POST, PUT, DELETE) without CSRF token validation.

// No CSRF middleware on a state-changing route
app.post('/api/transfer', requireAuth, (req, res) => {
  const { to, amount } = req.body;
  transferFunds(req.user.id, to, amount);
  res.json({ success: true });
});

SPA frameworks handle CSRF differently than server-rendered apps. Developers assume "the frontend handles it" — often nobody handles it.

AuthAudit rule CS-004 catches state-changing endpoints without CSRF protection. CS-006 flags missing SameSite cookie attribute.

Pattern 4: Session Mismanagement

// Express session config — missing security flags
app.use(session({
  secret: 'keyboard cat',
  cookie: {
    // Missing: httpOnly, secure, sameSite
    // Missing: maxAge (no session expiry)
  }
}));

Three things that should always be set on session cookies: HttpOnly (not accessible to JS), Secure (HTTPS only), and SameSite (prevents cross-origin requests from sending the cookie). Plus: rotate the session ID after login to prevent session fixation.

AuthAudit rules CS-001 (missing HttpOnly), CS-002 (missing Secure), CS-007 (no session rotation after authentication).

Pattern 5: Insecure Password Handling

// Plaintext comparison — never do this
if (password === user.password) {
  return { authenticated: true };
}

// MD5/SHA1 — not designed for passwords
const hash = crypto.createHash('md5').update(password).digest('hex');

// What it should look like
const match = await bcrypt.compare(password, user.passwordHash);

Plaintext comparison means passwords are stored in plaintext. MD5 and SHA1 are fast hashes — designed for checksums, not passwords. Use bcrypt, scrypt, or argon2.

AuthAudit rule PW-001 (plaintext password comparison), PW-003 (weak hashing algorithm), PW-006 (login endpoint without rate limiting).

Pattern 6: Frontend-Only Role Checks

// React component — frontend-only authorization
function Dashboard() {
  const { user } = useAuth();
  return (
    <div>
      {user.role === 'admin' && <AdminPanel />}
      {user.role === 'user' && <UserPanel />}
    </div>
  );
}

// But the API endpoint serves admin data to ANY authenticated user
app.get('/api/admin/dashboard', requireAuth, (req, res) => {
  // Missing: requireRole('admin')
  const data = await getAdminDashboard();
  res.json(data);
});

Frontend checks are UX, not security. Anyone can call your API directly. The backend must enforce authorization independently.

AuthAudit rule AC-008 (role check in frontend only, no backend enforcement), AC-011 (API endpoint missing role-based authorization).

Setting Up the Pre-Commit Hook

Install AuthAudit and run an initial scan:

clawhub install authaudit
authaudit scan .

You'll get a scored report (0-100) with findings mapped to OWASP categories:

$ authaudit scan src/

[CRITICAL] AC-001 Unprotected admin route — routes/admin.js:5
[CRITICAL] TK-003 JWT stored in localStorage — auth/client.js:22
[HIGH]     CS-002 Session cookie missing HttpOnly — config/session.js:8
[HIGH]     AC-008 Role check in frontend only — components/admin.tsx:45

Score: 41/100 (Grade: F)

For the pre-commit hook (Pro tier), configure lefthook:

# .lefthook.yml
pre-commit:
  commands:
    authaudit:
      run: authaudit scan --staged --min-score 60

This blocks any commit that would drop the auth security score below 60. Start with a low threshold and raise it as you fix existing issues.

What This Doesn't Replace

AuthAudit finds known anti-patterns. It won't find a novel auth bypass in your custom OAuth implementation. For that, you still need manual security review or a dedicated pentest.

This tool catches the stuff that shouldn't survive code review but consistently does — the missing middleware, the insecure cookie config, the localStorage JWT that someone copied from a tutorial.

clawhub install authaudit
authaudit scan .

Free to scan. Pro ($19/mo) adds the pre-commit hook + OWASP compliance reports. 100% local — your auth code never leaves your machine.

AuthAudit | GitHub

Your Logs Are a Security Risk — 6 Patterns That Leak PII

suhteevah — Fri, 20 Feb 2026 16:55:42 +0000

Most teams treat logging as an afterthought. You add console.log during debugging, maybe upgrade to a structured logger eventually, and call it done. But here's the problem: logs are the largest unaudited data stream in most applications.

I spent months scanning codebases for logging anti-patterns. Here are the 6 most dangerous ones I keep finding.

1. Console.log With Full User Objects

The pattern:

app.post('/login', async (req, res) => {
  const user = await db.findUser(req.body.email);
  console.log('Login attempt:', user);
  // user object contains: email, hashedPassword, phone, address, tokens...
});

Why it's dangerous: User objects contain emails, hashed passwords, tokens, phone numbers, addresses. All of it ends up in your log aggregator where every developer and ops engineer can see it.

The fix: Log only what you need — user ID, action, timestamp. Never log the full object.

2. Stack Traces With Sensitive Data

The pattern:

try {
  await processPayment(cardNumber, amount);
} catch(e) {
  logger.error(e.stack);
  // stack trace can contain function arguments including card details
}

Why it's dangerous: Stack traces can contain function arguments, local variable values, database connection strings, and API keys from environment variable interpolation.

The fix: Sanitize stack traces before logging. Strip arguments, redact known sensitive patterns.

3. Missing Log Levels (Everything Is console.log)

When your entire codebase uses console.log for everything — errors, debug info, user actions, system events — you can't filter by severity, can't set up alerts on error-level events, and can't strip debug logs from production.

The fix: Pick a structured logger (winston, pino, bunyan). Use appropriate levels. Strip debug in production builds.

4. No Correlation IDs Across Services

When a request touches 5 microservices and something breaks, you have no way to trace the path if your logs don't share a correlation ID. Debugging production issues goes from minutes to hours.

The fix: Generate a correlation ID at the entry point, pass it through context, include it in every log line.

5. Mixed Logging Formats

Half the codebase uses winston with JSON output, the other half uses console.log with string interpolation. Your log aggregator can't parse inconsistent formats. Search and filtering break.

The fix: Pick one logger. Enforce it project-wide.

6. Silent Error Paths (Catch and Swallow)

try {
  const data = await db.query(sql);
} catch(e) {
  // TODO: handle this
  return [];
}

The error happened but you'll never know. The function returns an empty array, something downstream breaks in a confusing way, and you have zero trail to follow.

The fix: Every catch block should log at minimum the error message, the function name, and relevant context.

Automate This

Logging is infrastructure. It deserves the same automated standards we apply to code style and test coverage. None of these patterns are hard to fix individually — the problem is that nobody checks.

I built LogSentry to scan for all 6 of these patterns (and 84 more) in one command:

clawhub install logsentry
logsentry scan .

Free to scan. Pro ($19/mo) adds pre-commit hooks so these patterns can't merge. Runs 100% locally — your log analysis never leaves your machine.

What logging anti-patterns have you run into? I'd love to hear what I'm missing.

Best Snyk Alternatives in 2026: Open-Source Dependency Security Tools

suhteevah — Sun, 15 Feb 2026 07:37:32 +0000

Snyk is the default answer for dependency security, but it comes with trade-offs: cloud dependency, pricing complexity, and your code being analyzed on external servers. If you're looking for alternatives — especially ones that run locally — here's what's available in 2026.

The Landscape

Tool	Local?	Price	Languages	SBOM	License Audit
Snyk	No	$25+/dev/mo	Many	✓	✓
Socket	No	$20+/dev/mo	JS, Python	✓	✓
DepGuard	Yes	Free / $19/dev/mo	10 pkg managers	✓	✓
npm audit	Yes	Free	JS only	✗	✗
pip-audit	Yes	Free	Python only	✗	✗
cargo audit	Yes	Free	Rust only	✗	✗
Trivy	Yes	Free	Containers	✓	✓

Why Local Matters

Cloud-based tools like Snyk require your dependency manifests (and sometimes source code) to be sent to external servers. For many teams — especially in regulated industries — this is a non-starter.

Tools that run locally analyze your code on your machine and never phone home.

DepGuard: The All-in-One Local Option

DepGuard is interesting because it wraps native audit tools (npm audit, pip-audit, cargo audit, govulncheck) into a single interface and adds license compliance on top.

What it does:

Vulnerability scanning using the audit tools your package managers already trust
License detection categorizing every dependency as permissive, copyleft, or unknown
Git hook enforcement blocking commits that introduce vulnerable dependencies
SBOM generation in CycloneDX format
Policy enforcement blocking specific licenses (e.g., GPL in proprietary projects)

Free tier covers vulnerability scanning and license detection. Pro ($19/user/mo) adds git hooks and auto-fix. Team ($39/user/mo) adds SBOM and compliance reports.

clawhub install depguard
depguard scan

The DIY Approach

You can also build your own pipeline with individual tools:

# JavaScript
npm audit --json

# Python
pip-audit

# Rust
cargo audit

# Go
govulncheck ./...

The downside: you need to maintain scripts for each language, there's no unified reporting, and you're on your own for license compliance.

Recommendation

Snyk if you need the deepest vulnerability database and don't mind cloud
DepGuard if you want local-only, multi-language scanning with license compliance
Individual audit tools if you only use one language and don't need license checks

DepGuard — dependency audit & license compliance. Install: clawhub install depguard

Why Your Documentation Is Always Stale (And How to Fix It With Git Hooks)

suhteevah — Sun, 15 Feb 2026 07:34:07 +0000

Every dev team has the same problem: documentation that was accurate three months ago but hasn't been updated since. It's not because developers are lazy — it's because there's no feedback loop.

The Root Cause

Code has CI/CD. Tests run on every commit. Linting catches style issues automatically. But documentation? It's a manual process that depends on someone remembering to update it.

That's the fundamental problem: docs are disconnected from the code they describe.

What If Docs Had Their Own CI?

Imagine if every commit was checked for documentation drift — the same way ESLint checks for code style or Jest checks for regressions.

That's exactly what DocSync does.

How It Works

DocSync uses tree-sitter to parse your code's AST and extract symbols: functions, classes, types, interfaces. Then it compares those symbols against your existing documentation.

On every commit, a pre-commit hook runs:

$ git commit -m "add payment handler"

━━━ DocSync: Documentation Drift Detected ━━━

✗ processPayment (function in src/payments.ts)
✗ PaymentResult (type in src/payments.ts)
⚠ validateCard (docs older than source)

Run docsync auto-fix to generate missing docs

The commit is blocked until the docs are updated. One command regenerates everything:

$ docsync auto-fix
✓ Regenerated docs/api/payments.md (3 symbols)
✓ All documentation is now in sync.

The Key Insight: Make It Automatic

The reason documentation rots isn't that devs don't care — it's that there's no enforcement mechanism. DocSync turns documentation into a commit-level concern, just like tests and linting.

Getting Started

# Free — no account needed
clawhub install docsync
docsync generate .

The free tier generates docs for any file or directory. DocSync Pro adds git hooks, drift detection, and auto-fix.

40+ Languages Supported

TypeScript, JavaScript, Python, Rust, Go, Java, C/C++, Ruby, PHP, C#, Swift, Kotlin — and any language with a tree-sitter grammar.

Everything runs locally. No code leaves your machine.

DocSync is an OpenClaw skill. Install free: clawhub install docsync